Clash 节点延迟高怎么办？按三层快速定位
简答：Clash 节点延迟高时，先固定同一个测速地址连续测试，再比较同地区节点，最后切换网络复测。若只有一个节点高，多半是节点或线路问题；若整份订阅都高，应继续检查本地网络、DNS、规则模式和 TUN 设置。
定义：Clash 节点延迟是客户端通过指定节点访问测速地址时测得的往返响应时间，不能单独代表下载速度、网页打开速度、丢包率或 UDP 稳定性。
先试这一步：固定测速地址，区分单节点还是整体变慢
如果你看到 Clash 节点延迟高，先不要立即改 DNS、MTU 或 TUN。第一步是在客户端内固定同一个健康检查地址，连续测试同一节点 3 次，再与 3—5 个同地区节点对照。Mihomo 的 URL-Test 文档说明，自动选择会根据测试 URL 的结果选择延迟较低的节点；因此，测试地址不同，结果就不能直接横向比较。
| 观察结果 | 更可能的问题层 | 下一步 |
|---|---|---|
| 只有一个节点高或超时 | 单节点、节点端口、线路或远端拥堵 | 固定该节点查看日志，再换同地区节点 |
| 同地区节点全部偏高 | 本地运营商、Wi-Fi、区域线路或高峰拥堵 | 切换手机热点或另一条宽带复测 |
| 所有地区节点都高 | 本地网络、代理模式、DNS 或客户端配置 | 先关闭 TUN 与自定义 DNS 做对照 |
| 测速低但网页仍慢 | 测速地址、规则命中、丢包、带宽或长连接问题 | 用实际业务页面和持续下载再次验证 |
建议记录节点名称、地区、协议、测试时间、3 次延迟、是否超时、网页打开结果和下载表现。不要只保留一次最低值，因为瞬时低延迟不等于长期稳定。
最短可复制步骤：按“节点—网络—配置”顺序排查
- 固定节点：在 Clash 的代理组中手动选择一个节点，不要先使用自动选择。等待连接建立后，分别访问一个你平时使用的网页和一个稳定的健康检查地址。
- 连续测速：在客户端的节点或代理组页面重复测试 3 次。记录延迟是否接近、是否出现 timeout、是否只有某一个节点失败。Mihomo 的代理组配置支持
url、interval、timeout和expected-status等健康检查字段，但具体入口名称要以当前客户端界面为准，详见 代理组配置文档。 - 换同地区节点：先换同一地区、相近协议的节点，再换另一地区。若只换节点就恢复，优先把问题归到单节点或线路，不要继续修改本机 DNS。
- 换网络：Windows、macOS 和 Android 可暂时切换手机热点；iOS 可关闭当前 Wi-Fi 后用蜂窝网络测试。若热点明显恢复，问题更可能在原 Wi-Fi、路由器、运营商链路或局域网干扰。
- 检查代理模式：只需要代理浏览器或遵守系统代理的应用时，先使用系统代理；需要接管不遵守系统代理的程序时，再考虑 TUN。Clash Verge Rev 的说明区分了系统代理与 TUN：系统代理依赖应用主动读取系统代理设置，TUN 则通过虚拟网卡接管系统流量，相关说明见其 代理模式文档。
- 最后处理 DNS：如果日志出现 DNS error、域名解析慢或节点域名无法解析，再检查 DNS。Mihomo 的 DNS 配置包含
nameserver、fallback、proxy-server-nameserver等不同用途，不能把所有 DNS 地址混在一个字段里，先备份配置，再做最小修改，参考 Mihomo DNS 文档。
预期结果：完成前四步后，你应能判断是单节点故障、同地区线路问题、当前网络问题，还是全部节点都受客户端配置影响。若没有得到清晰差异，不要继续叠加 DNS、TUN、MTU 和规则修改。
按错误信息分流：不要把 timeout 和延迟高混为一谈
| 日志或现象 | 含义倾向 | 处理动作 |
|---|---|---|
timeout | 在限定时间内没有完成连接或健康检查 | 先换同订阅节点，再换网络；不要仅凭一次超时判断整份订阅失效 |
connect failed | 连接目标失败，可能涉及地址、端口、协议或本地网络 | 固定节点查看日志，并与其他节点对照 |
TLS handshake timeout | TLS 握手阶段超时，可能是链路质量、时间、证书或协议兼容问题 | 检查系统时间、节点域名和客户端日志；不要直接关闭证书校验 |
DNS error | 域名解析阶段出错或响应过慢 | 先确认普通网络能否解析域名，再检查 DNS 分流和节点域名解析设置 |
| 延迟低但网页卡顿 | 测速响应快，但可能存在丢包、抖动、带宽不足或规则命中错误 | 测试网页加载、持续下载和长连接，不要只看延迟数字 |
Windows 可以用 ping -n 20 目标域名 观察连续响应，也可以用 tracert /d 目标域名 查看路径。微软文档指出，tracert用于查看到目标的路径，而 pathping还可用于观察路径中的延迟和丢包；中间某一跳显示星号并不必然代表最终目标不可用，因为部分路由器不会返回超时信息，具体说明见 Microsoft Learn 的 tracert 文档。
macOS 可在“终端”使用 ping -c 20 目标域名 和 traceroute 目标域名；Android 与 iOS 优先使用客户端日志、节点测试和 Wi-Fi/蜂窝网络对照。不要把手机系统的普通 ping 结果直接当作代理链路延迟，它测到的可能是直连路径。
自动选择怎么用：URL-Test 适合选优，Fallback 适合故障切换
如果手动选择稳定节点后，想减少频繁切换，可以使用客户端已有的自动选择策略。Mihomo 的 url-test 会根据健康检查结果选择延迟较低的节点；fallback 则按代理顺序选择当前可用节点，官方文档分别说明了两种策略的行为：URL-Test 与 Fallback。
使用时注意三点：第一，健康检查 URL 要稳定，不能把某个业务网站的偶发响应当成普遍线路质量；第二，自动选择的结果只代表该测试地址和测试时刻；第三，若你关心视频、长连接或 UDP，必须在自动选优后做实际业务复测。Mihomo 的 API 文档也显示，代理与策略组可以记录测试 URL、当前节点和延迟历史，因此出现“数字看起来很好但实际不好用”时，应对照测试地址与真实访问目标，而不是盲目追求最低毫秒数，详见 Mihomo API 文档。
不要同时修改自动选择、DNS、TUN、MTU 和规则。每次只改一个变量，测试完成后保留有效改动，失败就恢复备份。订阅链接、token、节点密码和完整配置文件都属于敏感信息，不要粘贴到公开 AI、在线解析器、群聊或截图中。
复测与回滚：确认问题真的解决
- 回到同一个测速地址，连续测试原节点和替代节点各 3 次。
- 用同一网络分别测试系统代理与 TUN；如果只有 TUN 异常，优先检查虚拟网卡、服务权限、防火墙和 DNS 劫持设置。
- 打开一个实际网页，再进行短时间持续下载或长连接测试，记录是否出现断流。
- 在 Windows 上使用
pathping 目标域名辅助观察路径质量；其他系统则保留客户端日志和时间点。 - 若修改 DNS 或配置后问题扩大，关闭新增设置并恢复备份。不要为了追求更低延迟长期保留无法解释的配置项。
复测通过的标准不是某一次延迟最低，而是同一测试地址下结果没有频繁超时，实际网页能够稳定打开，且切换节点或网络后能解释差异。
常见问题
Clash 节点延迟多少算高？
没有脱离测试地址、网络位置和使用场景的统一阈值。应比较同一时间、同一地址、同一客户端下的多个节点，并结合丢包、抖动、网页打开和长连接表现判断。
延迟高是不是一定要换订阅？
不一定。先固定节点、换同地区节点、换网络，再检查代理模式和 DNS。只有当整份订阅在多个网络下都持续超时或无法连接，才需要进一步核对订阅内容和服务端状态；具体服务状态需以对应提供方当前资料为准。
为什么自动选择的节点延迟最低，实际使用却很慢？
自动选择通常只测指定 URL 的响应时间，不能代表下载速度、视频持续传输、长连接或 UDP。应在自动选出的节点上做实际业务复测，必要时改为手动选择稳定节点。
修改 DNS 能降低节点延迟吗？
DNS 主要影响域名解析阶段，通常不能直接降低已经建立连接后的传输延迟。只有当节点域名解析慢、解析错误或分流不正确时，DNS 调整才可能改善连接建立过程。
Clash Verge Rev 里应该先开 TUN 还是系统代理？
只需要代理遵守系统代理的应用时，先用系统代理；需要接管不读取系统代理的程序时，再考虑 TUN。TUN 涉及虚拟网卡、路由和权限，开启前应先备份并确认当前版本的服务或管理员权限要求。
常见问题
Clash 节点延迟多少算高？
没有脱离测试地址和网络位置的统一阈值。应在同一地址、同一网络下比较多个节点，并结合丢包、抖动和实际访问表现判断。
延迟高是不是一定要换订阅？
不一定。先固定节点、换同地区节点、换网络，再检查代理模式和 DNS。整份订阅在多个网络下都持续超时，才需要继续核对订阅内容和服务状态。
为什么自动选择延迟最低，实际使用却很慢？
自动选择通常只测试一个 URL，不能代表下载、视频、长连接或 UDP。自动选出节点后，还要用实际业务复测。
修改 DNS 能直接降低节点延迟吗？
DNS 主要影响域名解析，不能直接降低已建立连接的传输延迟。只有解析慢、解析错误或分流不正确时，DNS 调整才可能改善连接建立。