节点延迟显示超时，实际却能正常上网？测的不是同一件事
那个数字测的是一次到特定地址的往返，不是这条节点能不能用。两者经常不一致，而多数人只看前者。
一个很常见的困惑：客户端里所有节点都显示超时或「-1」，网页却能正常打开。
这不矛盾，因为这两件事测的根本不是同一样东西：
| 延迟测试 | 实际使用 | |
|---|---|---|
| 测什么 | 向一个固定地址发请求并计时 | 转发你真正要访问的各种流量 |
| 失败意味着 | 到那个地址的这次请求没成功 | 这条节点不能用 |
| 受什么影响 | 测试地址本身的状态 | 整条链路的转发能力 |
测试地址被屏蔽、被限速或返回了非预期内容，结果就是超时，而这和节点能不能转发流量没有必然关系。
客户端是怎么测这个数字的
理解机制才能判断什么时候该信它。
客户端的做法通常是：通过这个节点，向一个预设的地址发一个很轻量的请求，记录从发出到收到响应的耗时。判定成功的条件一般有两条——在超时时间内返回，并且返回的内容符合预期。
两条里任何一条不满足，就记为失败。这就带来一个关键推论：
返回得很快但内容不对，同样算失败。 比如测试请求被中途拦截并返回了一个提示页，速度可能极快，但因为内容不是预期的那个，客户端仍然显示超时。这是「网络明明很快却全部超时」最常见的解释。
延迟这个指标本身的含义与合理范围，见节点延迟多少算正常。
五种测试失败但不影响使用的情况
| 情况 | 典型特征 | 怎么确认 |
|---|---|---|
| 测试地址在你的环境里被处理过 | 所有节点一起超时 | 换测试地址后全部恢复 |
| 测试地址本身临时故障 | 所有节点一起超时，过几小时自愈 | 等一会儿再测 |
| 超时阈值设得太短 | 远距离节点超时，近距离正常 | 调大阈值后恢复 |
| 并发测试太多被限速 | 一次性全测时失败多，单个测正常 | 逐个点测试 |
| 节点对测试流量有特殊处理 | 只有某一家的节点这样 | 换机场对比 |
第一行是最高频的一种，识别特征很明确：所有节点整整齐齐一起超时。 如果是节点本身的问题，不可能这么一致——真的节点故障通常是部分超时、部分正常。
第四行容易被误判成节点不稳。 很多客户端支持一键测试全部节点，几十个请求同时发出，中途的某一环可能对这种突发流量限速，结果是一片超时。逐个点一次通常就正常了。
反过来的情况：延迟很好看但实际不通
这一类比前面那类更危险，因为数字会给你错误的安全感。
测试通过只说明到那一个地址的这一次请求成功了，它不保证：
- 这条节点能访问别的网站（不同目标走的路径可能不同）。
- 这条节点的带宽够用（测试只发很小的数据，测不出吞吐）。
- 这条节点能维持长连接（测试是一次性的短请求）。
所以会出现：延迟显示三十几毫秒很漂亮，打开网页却卡；或者网页正常，但一传大文件就断。
判断依据应该回到你的实际用途上：
- 日常浏览 → 看延迟数字大致够用。
- 看视频、下大文件 → 要看实际吞吐，延迟不说明问题。
- 长时间的流式连接 → 要看波动范围而不是最低值，波动大意味着中途容易断。
速度慢和延迟高的分段定位方法见延迟高、网速慢怎么分段定位。
该不该改测试地址
如果确认是测试地址的问题，改是合理的，但要改对。
该改的情况：所有节点一起超时，而实际使用正常，并且这个现象持续存在。
改成什么：换一个同样在境外、且没有被特殊处理的轻量地址。多数客户端内置了几个可选项，先试内置的。
不该改成什么：不要换成境内地址。那样测出来的数字会失去意义——请求很可能根本不经过节点，或者走了一条和实际使用完全不同的路径，结果是数字好看但完全不反映真实情况。
改完之后要知道你改变了什么：这个数字从此衡量的是「到新地址的往返」。换了不同的测试地址之后，新旧数字不能直接比较，之前记录的基线全部作废。
各客户端里测试地址与超时阈值的设置位置见 Clash Verge 使用教程。
测试不准最现实的危害：自动选择会选错
这是唯一需要真正处理的副作用。
自动选择功能依赖延迟数字排序，通常挑最低的那个。测试不准时会出现两种糟糕的结果：
- 全部超时 → 排序失去依据，可能随机选或者停在一个不合适的节点上。
- 数字不准但有高低 → 它挑出的是「到测试地址最快」的节点，而不是「最适合你用途」的节点。
低延迟常常意味着这是个热门方向（比如香港），而热门方向也往往最拥挤，峰值时段掉速最明显。自动选择会持续把你往这类节点上推。
实际建议：
- 对延迟敏感的用途（网页浏览、交互式操作）可以交给自动选择。
- 对稳定性敏感的用途（长连接、大文件、AI 工具的长回答）手动固定到你自己测过的节点上，并把这些域名从自动选择组里摘出来。
什么时候这个超时是真问题
前面讲的都是误报。下面这几种情况，超时反映的是真实故障：
- 部分节点超时、部分正常，而且分布和地区相关。这更像是真的节点不可达，按节点超时的原因分析和逐步排查处理。
- 超时的同时实际也上不了网。 这时候延迟数字只是伴随现象，真正要查的是链路本身。
- 同一个节点从能用变成超时且持续，而其他节点正常。可能是这个落地确实出了问题，换节点即可。
- 换了测试地址仍然全部超时，并且换机场后正常。这时候要怀疑的是原机场的节点对测试流量做了处理，或者链路确实有问题。
一句话的判断标准：先看能不能正常上网。能用就是测试的问题，不能用才是节点的问题。 更多按症状分类的入口见网络诊断栏目。