外观
Clash 延迟测试全红怎么办？理解 URL-Test、超时与节点可用性的排查指南
很多人在 Clash 的代理页面看到一排红色延迟，或者点击测试后出现 Timeout、Error，第一反应往往是“订阅失效了”或“节点全坏了”。但延迟测试的结果，只能说明 Clash 在当前网络、当前测试地址、当前时间内，没有按预期完成一次请求；它并不能直接等同于节点是否完全不可用。
尤其是自动选择、故障转移等代理组依赖延迟测试结果时，理解它的机制会很有帮助。本文不讨论具体服务商，只讲一套可迁移到 Clash Verge、Clash Meta、FlClash 等客户端的通用排查思路。
先分清：延迟测试测的到底是什么？
Clash 的延迟测试通常不是简单地对节点服务器执行传统 ping。多数情况下，客户端会让流量经过某个代理节点，再请求一个指定的网址，并统计从发起请求到收到响应所花的时间。
可以把过程理解为：
- Clash 选择一个节点；
- 建立到该节点的代理连接；
- 通过这个节点访问测试 URL；
- 测试站点返回 HTTP 响应；
- 客户端记录耗时，并显示为毫秒数。
因此，测试失败可能出现在任何一个环节：本地网络不能联网、节点握手失败、DNS 解析失败、测试网址不可访问、返回内容不符合要求，甚至客户端本身的网络权限异常。
这也解释了一个常见现象：节点延迟显示超时，但手动选中节点后，某个网站仍然能打开。 这通常意味着测试 URL 或测试规则有问题，不必急着删除整份订阅。
先确认故障范围：是“测试失败”，还是“代理不能用”
排查前，不要只盯着红色数字。建议先做一个简单的交叉判断。
情况一：只有延迟测试失败，实际网页可以打开
如果你手动选择某个节点，并且能正常打开原本需要代理的网站，说明节点的基本链路大概率仍然可用。优先检查测试 URL、自动选择组以及客户端设置。
此时不建议频繁更新订阅、反复切换内核，或一次性修改 DNS、TUN、系统代理等大量选项。一次只改一个变量，才容易找到真正原因。
情况二：所有节点测试失败，网页也全部无法访问
这种情况需要从更基础的环节检查：设备是否联网、系统时间是否正确、当前网络是否限制代理连接、客户端是否获得了必要权限，以及订阅中的节点信息是否仍有效。
情况三：只有少数节点红，其余节点正常
这往往是最容易判断的一类。少数节点可能出现临时拥堵、线路波动、落地网络异常，或者不适合当前测试地址。先切换到可用节点即可，不要因为个别节点超时就判定整个客户端出了问题。
情况四：自动选择组不可用，手动节点却正常
这通常与 url-test、fallback 等代理组的探测机制有关。自动组依赖固定测试地址和测试间隔；手动组则不需要先通过探测才可被选中。重点应放在代理组配置和测试地址，而不是节点本身。
第一步：检查基础网络和系统时间
在开始复杂操作前，先断开 Clash 的系统代理或关闭 TUN 模式，直接确认本地网络是否能访问正常的网站。若本地网络本来就不稳定，Clash 的测试结果自然没有参考价值。
接着检查以下项目：
- Wi-Fi 或有线网络是否频繁断开；
- 手机是否在 Wi-Fi 与蜂窝网络之间反复切换；
- 电脑是否启用了其他 VPN、加速器或浏览器代理扩展；
- 系统日期、时区和时间是否自动同步；
- 学校、公司、酒店等网络是否需要先完成网页认证。
系统时间尤其容易被忽略。许多代理协议依赖 TLS 加密连接，若设备时间偏差过大，证书有效期校验可能失败，客户端就会表现为连接超时、握手失败或无法建立安全连接。
公共网络还常有“认证页”机制：设备先连接 Wi-Fi，但必须打开浏览器同意条款或登录账号后才能真正联网。在认证完成前开启全局代理或 TUN，认证页面可能无法正常跳出。此时先关闭代理相关功能，完成认证，再重新启用 Clash。
第二步：更换一个稳定且简单的测试 URL
延迟测试全红时，最值得优先检查的就是测试地址。一个合适的测试 URL 应当满足几个条件：响应速度快、页面内容稳定、无需登录、不频繁跳转，并且能返回预期的 HTTP 状态。
许多 Clash 配置会使用返回 204 状态的轻量地址作为测试目标。它的优点是响应内容很小，适合频繁探测。不过，任何固定网址都可能因为网络环境、DNS、区域访问策略或站点自身调整而不适合你当前使用。
如果客户端允许设置测试 URL，可以尝试换成另一个公开、稳定、无需复杂跳转的地址，然后重新测试。修改后要留意两点：
- 不要把需要登录、带人机验证或经常重定向的网页作为测试地址。 这类页面即使能打开，也可能让 Clash 判断为探测失败。
- 确保配置中的
expected-status与测试地址匹配。 例如，一个地址实际返回200，但代理组被要求必须得到204，那么节点可能全部显示失败。
如果你使用的是订阅自动生成的代理组，图形界面未必能直接改测试 URL。此时可以查看覆写配置、覆写脚本或配置文件中与 url-test、fallback、health-check 相关的部分。修改前务必备份原有内容，避免订阅更新后难以恢复。
第三步：理解 URL-Test、Fallback 与 Load-Balance 的差别
不少“节点全红”的问题，实际是对代理组行为理解不足。
url-test 的目标是从一组节点里选出测试结果较好的节点。它会定期访问测试 URL，并依据结果自动切换。若测试 URL 不通，整个组的判断都会失去基础。
fallback 更偏向故障转移：它会按顺序或健康状态选择可响应的节点。当当前节点探测失败时，再尝试备用节点。它并不承诺选择延迟最低的节点。
load-balance 则会将新连接分配给多个节点，以不同策略平衡负载。它同样可能包含健康检查，但“显示延迟”与“实际分配连接”不是一回事。
因此，如果你只是想临时恢复使用，最直接的办法通常是进入代理组，手动选择一个已知可用的节点。等基本访问恢复后，再回头处理自动选择组的测试地址、间隔和策略。
还应注意测试间隔不要设置得过短。过于频繁的健康检查会额外消耗流量、电量和连接资源，也可能给网络带来短时间内大量重复请求。普通个人设备没有必要把探测间隔压得很低。
第四步：查看日志，区分 DNS、连接和 TLS 问题
当界面只显示 Timeout 时，日志才是更有价值的线索。不同客户端的入口名称略有差异，通常可以在“日志”“连接”“内核日志”或“运行日志”中找到。
重点不是逐行看懂所有英文，而是搜索一些高频关键词，并判断它们出现在哪一步：
DNS、resolve、no such host：通常指域名解析异常；connect timeout：连接阶段超时，可能是节点地址不可达、网络阻断或线路拥堵；TLS handshake failed、certificate：可能和系统时间、证书校验或中间网络干扰有关；connection refused：目标端口没有接受连接，节点端信息可能已变更；authentication failed：认证信息不匹配，例如订阅内容更新后本地仍使用旧配置；context deadline exceeded：在限定时间内未完成请求，需要结合前后日志判断卡在哪一环。
不要把完整订阅链接、节点名称、服务器地址、UUID、密码或日志截图直接发到公开群组。这些内容可能暴露你的订阅凭据和网络使用信息。需要求助时，应先打码敏感字段，并只保留报错类型、时间、客户端版本和必要的上下文。
第五步：排除 DNS 配置互相打架
DNS 问题不一定表现为“网站域名解析不出来”，也可能表现为延迟测试一直超时。因为测试 URL 本身需要解析，节点域名有时也需要解析；若 DNS 请求被不同组件分别接管，就容易产生结果不一致。
常见的冲突来源包括：
- Clash 内置 DNS 已启用，但系统、浏览器又各自强制使用安全 DNS；
- 路由器下发了特殊 DNS，设备又启用了私有 DNS 或加密 DNS；
- TUN 模式接管 DNS 后，其他网络软件再次改写 DNS；
- IPv6 DNS 可用性不稳定，设备却优先使用了 IPv6 解析结果。
排查原则是“减少变量”。短时间内保留一种清晰的 DNS 方案，不要同时打开多个客户端、浏览器和系统层面的强制 DNS 代理。修改一项后重新测试，并观察日志是否从 resolve 类错误变为正常连接。
如果关闭 IPv6 后问题消失，也不代表 IPv6 天生有问题，更可能是当前网络的 IPv6 路由、DNS 或节点对 IPv6 的支持不一致。是否长期关闭，应根据自己的网络环境和实际需求决定。
第六步：检查协议与客户端内核兼容性
订阅中的节点并不一定都能被每个 Clash 客户端完整支持。某些较新的传输方式、TLS 扩展、UDP 设置或特定参数，可能依赖较新的 Meta 内核；而旧内核或长期未更新的客户端，可能导入成功却在连接或测速时失败。
遇到“同一订阅在一台设备正常，另一台设备全红”时，可以按下面顺序检查：
- 对比两端客户端和内核版本；
- 查看异常设备是否缺少该协议所需的支持；
- 检查配置是否被覆写规则意外删改；
- 尝试使用手动节点组，而不是自动测试组；
- 在不暴露敏感信息的前提下，对比同一节点的关键参数是否一致。
不要为了“兼容”而随意删除 TLS、SNI、ALPN、跳过证书验证等安全相关参数。这样做可能暂时改变报错形式，却会降低连接安全性，也会让后续排查更混乱。
一个推荐的最小化排查顺序
当你再次遇到 Clash 延迟全红，可以按下面的顺序执行，通常比反复重装更有效：
- 关闭 Clash 后确认基础网络正常；
- 检查系统时间、网络认证和其他 VPN/代理是否冲突；
- 手动选择一个节点，实际打开一个目标网站；
- 更换测试 URL，或检查其预期状态码；
- 查看日志，判断是 DNS、连接、TLS 还是认证问题；
- 检查自动选择组的类型、测试间隔和覆写配置；
- 对比客户端内核兼容性；
- 最后才考虑重新导入订阅或恢复客户端配置。
结语：红色延迟不是最终结论
Clash 的延迟数字适合用来辅助选择节点，但它并不是网络质量的完整评分，更不是判断节点生死的唯一标准。一次探测结果会受测试地址、DNS、目标站点、网络时段和客户端设置影响。
更可靠的判断方法是：先确认实际访问是否正常，再用日志定位失败环节，最后有针对性地调整测试地址、DNS 或代理组。把“延迟测试失败”和“代理完全不可用”分开处理，很多看似棘手的问题都会变得清晰许多。