一个可靠的网络故障测试方法:每次只改变一个变量
把网络问题当成实验:固定设备与配置,只改变一个条件,才能找到因果。
不堆参数、不靠猜。按网络、订阅、DNS、规则和客户端逐层排查,把每个问题拆成可以验证的步骤。
共 21 篇
把网络问题当成实验:固定设备与配置,只改变一个条件,才能找到因果。
一张可收藏的快速检查表,从基础网络到日志按顺序缩小问题范围。
局域网资源通常应保持本地访问,TUN 或规则配置不当时可能被错误送往代理。
多个客户端同时运行会争用本地端口、系统代理、DNS 和虚拟网卡。
日志里的 certificate、handshake、TLS alert 都发生在应用数据传输前的安全协商阶段。
WebSocket 先通过 HTTP 握手升级成长连接,路径或代理头错误都会让升级失败。
同机其他应用正常、浏览器异常时,代理核心可能是好的,问题更接近浏览器设置。
应用可能不遵循系统代理,或使用独立代理、UDP、自带 DNS,需要 TUN 才能接管。
游戏对延迟波动和 UDP 丢包很敏感,稳定 70ms 可能比 30-180ms 跳动更好。
睡眠会让网卡、IP 和虚拟网络状态变化,唤醒后旧路由与连接可能没有完全恢复。
文字、头像、图片和视频经常来自不同域名或 CDN,因此只坏资源加载很常见。
视频更依赖持续吞吐和低丢包,峰值再高也可能因为频繁掉速而卡顿。
403 表示服务器收到请求但拒绝访问,排查重点与 Timeout 完全不同。
502 通常表示网关无法正常从上游取得响应,更偏向服务端链路故障。
节点显示 Timeout 并不等于订阅失效,先区分单节点故障与全部节点共同故障。
同一设备同一节点只改变接入网络,结果不同,是定位 DNS、IPv6、路由器和运营商链路的重要线索。
首页能打开、视频却黑屏或一直转圈,通常要重点看媒体链路、DNS、QUIC、丢包和节点质量。
只有部分国内站异常时,问题往往在规则命中、DNS、TUN 或局域网绕过,而不是节点全部失效。
所有节点同时异常时,优先排查它们共同依赖的网络、订阅、DNS、系统时间和客户端。
客户端有实时流量并不能证明 DNS、TLS、规则和目标网站链路全部正常。
订阅更新失败要先分清地址错误、Timeout、403、5xx 和 DNS 解析异常。
换节点、换网络、改 DNS、开 TUN、改规则不要同时进行。记录每一步前后的结果,才能真正定位原因。
每周 10 篇是发布/精选节奏,不是简单换日期制造新鲜。