本文目录
延迟显示 Timeout，只能说明探测请求没有按时返回
Clash 的延迟按钮会访问配置指定的测试地址，并在规定时间内等待结果。Timeout 可能来自节点不可达、测试 URL 被拦、DNS 失败或当前网络阻断；这个结果不能说明整台电脑已经断网，也不能直接代表视频、下载和 UDP 的实际表现。
反过来，延迟几十毫秒也不保证长连接稳定。排查节点时要把“健康检查结果”和“真实业务请求”分开记录，否则会被一个漂亮数字带偏。
两种测试回答的问题
| 测试 | 能说明什么 |
|---|---|
| 节点延迟 / health check | 测试 URL 在超时时间内是否有响应 |
| 浏览器打开目标网站 | 网页请求是否按预期规则从所选出口完成 |
| 长下载或流式回复 | 连接持续性、丢包与中途切换 |
| 游戏或语音 | UDP 支持、抖动与实际线路质量 |
关闭自动选择，手动切换节点做一次对照
在主要策略组中选一条具体节点，不使用 url-test、fallback 或 load-balance。模式保持 Rule，打开 Connections，然后重复同一个网页或应用动作。固定出口后，成功和失败才来自同一条路径。
记录目标域名、命中的规则、节点名称和日志错误。连接页没有请求，说明应用未经过 Clash；显示 DIRECT，说明规则没有走该节点；确认请求已经交给节点后仍超时，再检查节点连接。
一次有效复测应保留
- 固定的节点名称与协议类型
- 同一个目标地址或应用动作
- Connections 中的规则和出口
- 日志里的 timeout、reset 或 DNS 错误
一条失败先换节点，全部失败先看订阅状态
- 只有一条节点超时
- 更像单节点下线、拥堵或服务端端口变化；换同地区另一节点对照。
- 同一种协议全部超时
- 检查当前内核是否支持配置字段，以及该协议是否被本地网络限制。
- 同一订阅所有节点超时
- 先看订阅是否过期、流量是否用完、服务是否有公告，再决定要不要继续测速。
- 多个订阅在当前 Wi-Fi 都失败
- 切手机热点做对照，范围已靠近本地网络、DNS 或防火墙。
- 网页能用，游戏或语音失败
- 单独验证 UDP 与 TUN 接管，不能用网页延迟替代。
范围确定后再动设置。例如只有一条节点坏了，调整 DNS 和 TUN 反而会制造新问题；所有订阅都在同一网络失败，继续购买新节点也很难说明原因。
timeout、refused、reset 和 DNS error 不要混着处理
i/o timeout / context deadline exceeded
路径在时限内没有完成，比较节点、网络和目标地址。
TLS handshake timeout / handshake failed
连接到达握手阶段但没有完成，核对节点协议、系统时间、内核兼容和当前网络。
connection refused
目标主机可达但端口拒绝，节点服务或端口配置可能已变。
connection reset by peer
连接建立后被对端或中间设备重置，检查协议兼容和网络稳定性。
no such host / DNS error
域名解析未完成，转去检查 Clash DNS 和系统 DNS 路径。
unsupported / parse error
配置与内核能力不匹配，这不是网络延迟。
日志时间要与刚才的测试动作对应。后台订阅更新、健康检查和浏览器请求可能同时写日志，只截最后一行很容易拿错对象。
换一次热点，判断问题在当前网络还是节点
同一固定节点在家庭 Wi-Fi 和手机热点各请求一次同一目标。热点成功、Wi-Fi 失败，说明节点本身仍能工作，应检查路由器 DNS、防火墙、IPv6 或运营商路径；两边都失败，再换同订阅的另一节点。只有晚高峰明显变慢、白天恢复，则把测试时间和持续速度记录下来，更像线路拥塞而不是配置突然写错。
若同一协议整组失败而其他协议正常，记录协议类型与内核版本，向订阅提供方核对配置。不要把 Reality、XTLS Vision 之类传输或 flow 名称当成独立节点质量指标，真正有用的是同一环境下的对照结果。
最少变量的四次对照
节点 A + Wi-Fi
重复固定目标，留下日志。
节点 A + 手机热点
只更换接入网络。
节点 B + 原 Wi-Fi
只更换节点，尽量保留同一协议。
另一协议节点 + 原 Wi-Fi
只在前面仍无法区分时使用。
频繁断一下又恢复，要看策略组有没有在换出口
url-test 会根据探测结果选择延迟较低的节点，fallback 会在当前节点不可用时按顺序切换。探测间隔过短、tolerance 太小或测试 URL 不稳定，可能让出口频繁变化；登录会话、下载和流式连接就会被打断。
把策略组临时改为 select 并固定一条节点。如果断流消失，问题不一定是节点本身，而可能是健康检查参数或自动切换方式。恢复自动组时，使用稳定的测试 URL，合理拉长 interval，并给 url-test 留出 tolerance。
proxy-groups:
- name: 自动选择
type: url-test
include-all: true
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
lazy: true回到原来的业务，确认超时真的消失
网页问题要完成登录与页面加载，下载问题要观察一段持续传输，语音或游戏则看 UDP 和会话是否稳定。Connections 应持续显示预期规则与固定出口，日志里不再出现同一错误。
如果只能证明某个测试 URL 变绿，而原场景仍超时，这次排查还没有结束。保留节点、网络、时间和错误四项信息交给订阅提供方，他们才有条件定位线路或服务端。