节点延迟测试超时怎么排查

先记住一件事再动手：这个测试不是 ping。客户端是通过这个节点向一个测试地址发一次 HTTP 请求，把响应时间当作延迟。测试流量走的和你平时上网是同一条路，所以路上任何一环断了都会变成超时——包括那个测试地址你本来就访问不到。

接下来只有一个问题要回答：是整列一起超时，还是只有零星几个？这两种情况几乎没有交集，方向选反了，就会出现花一个钟头换掉一份其实没毛病的订阅这种事。

全部超时：先怀疑本机，别怀疑节点

1. 把测试地址换成一个你确定在本地能稳定打开的，重测一次。
2. 看一眼系统时间。差出一两分钟以上就同步一下，再测。
3. 把代理关掉，直接在浏览器里打开那个测试地址，确认本机网络和 DNS 是通的。

第一条是里面最常见的，值得说清楚为什么。测试请求和别的请求一样要过你的规则，很多配置会把这个地址判成直连；而它在你的网络里不挂代理本来就打不开，于是所有节点整整齐齐一起超时，看着像是订阅全崩了，实际一个节点都没事。把测试地址换成一个在你这儿稳定有响应的，数字立刻就出来了。

只有几个超时：这才轮到节点

• 节点已经没了。服务商下架机器、换线路是常事，而你客户端里躺的还是上周拉的那份。别对着一个死条目研究，先更新一次订阅。
• 协议在你当前的网络里被干扰。基于 UDP 的传输是常见的受害者，运营商的 QoS 会把它压下去；特征是同一家的其他节点都好，就这几个不行。在同一份订阅里找一个走 TCP 的节点对比一下。
• 落地那头满了。晚上是高峰，一个中午测着正常、十点钟超时的节点，基本都是这个原因，也基本不是你能修的。

第二条经常被误判成节点坏了。换个网络测同一个节点，用手机热点就够。热点上通了，说明节点是好的，是你这条网络在压那种传输；两边都不通，才是节点自己的问题。

有些超时是测出来的，不是真的

点一下，客户端同时测几十上百个节点，这些请求全挤在你一条上行链路上排队，排在后面的直接撞上时限。你看到的超时比例因此虚高。真在意某几个节点，就单独一个一个测，结果和批量跑出来的完全不是一回事。

另一个因素是时限本身。多数客户端都有一项可调的测试超时时间，默认值对晚高峰的跨洋线路可能偏紧——本来两秒出头能回来的节点直接被判死。把它放宽一点，会有一批「假超时」活过来。放宽之后还超时的，那才值得认真看。

超时不是判决

测试只打了一个地址、走了一条路径。你真正要访问的站点在不在同一个方向、经不经过同一段拥塞，是另一回事。所以这两种情况都很常见：测出超时的节点，开网站顺得很；测出漂亮的 80ms 的节点，视频卡到没法看。