折腾大半天接口调试，反复弹出网络请求失败什么原因，差点直接怀疑是服务器出了故障。
最开始压根没往自己设备上想，一直盯着后台日志反复刷新，以为是接口参数写错、端口冲突这类代码层面的问题，浪费了快两个小时的时间。当时连着公司办公WiFi，调试所有接口全部报错，弹窗统一都是请求超时、连接失败，换了浏览器、重启了开发软件，结果问题一点没变，越排查越烦躁。
网络请求失败：WiFi环境干扰问题
后面偶然切了手机热点测试，所有请求瞬间全部成功，一下子就定位到了问题根源。办公局域网的防火墙和网络拦截规则，会主动屏蔽部分开发调试的临时接口，这类本地搭建的接口端口不固定，很容易被企业网络的安全策略拦截，不会提示拦截，只会直接判定请求失败。之前一直固化思维，觉得代码问题才会导致请求失败，完全忽略了网络环境的影响，白白踩了大坑。
很多人排查请求报错，第一反应都是改代码、清项目配置，其实大概率是外部网络的限制。尤其是办公网、校园网这类公共网络，自带安全拦截机制，会过滤非常规端口的网络请求，本地开发的接口大多不在白名单内，触发拦截后就会持续请求失败。
网络请求失败：本地缓存与DNS问题
除了网络拦截，本地缓存紊乱也是高频诱因。之前居家调试的时候，也遇到过一模一样的问题，WiFi正常能用、网页能打开，唯独程序接口请求失败。当时瞎折腾一通，反复重启软件、重启电脑，始终没解决，越弄越糟。
后来才反应过来，是电脑本地DNS缓存出错，域名解析错乱，导致程序无法正常对接服务器。这种问题特别隐蔽，普通上网浏览、刷视频完全不受影响，只有针对性的接口请求会报错，很难第一时间联想到是DNS的问题。
最简单的验证方式，就是切换网络、刷新DNS缓存，不用复杂的代码排查。
别只盯着代码找问题。
网络请求失败：设备代理残留问题
还有一个极易被忽略的坑，就是设备残留的代理设置。之前为了测试跨域接口，手动开过系统代理，调试结束后只关了软件内的代理，没关闭电脑系统层面的代理开关，之后很长一段时间，间歇性出现网络请求失败的情况。
系统代理处于开启状态但无有效代理地址时，所有网络请求都会优先走代理通道，通道失效就会直接请求失败。这种问题没有固定规律，时好时坏，最容易让人误以为是服务器不稳定或者代码偶发bug，排查起来特别耗费精力。
那天排查完所有问题，关掉系统代理、刷新完DNS，看着终于成功的请求日志，只是默默关掉了调试窗口，没再纠结之前浪费的时间。