Clash 节点延迟测试原理:测速数值与实际网速为何对不上

节点延迟：先判断可用，再比较网速

延迟低不等于下载快，显示超时也不等于节点彻底失效。Clash 客户端里的“测速”通常是一次小型 HTTP 请求测试，不是持续下载测试。它适合排除当前无法完成请求的节点，也适合为自动选择策略组提供依据；判断视频、下载或会议体验，还要看持续吞吐、稳定性和实际目标网站。

例如，一个节点显示 80 ms，另一个显示 180 ms，前者未必更适合下载大文件。前者可能响应快但带宽受限，后者可能建立连接稍慢，却能稳定传输较大的数据量。这里的数字只是说明场景，不是本站实测结果。

单位也容易看错。100 Mbps 的理论换算值是 12.5 MB/s，实际下载还受协议开销、服务器限速和链路状态影响。不能把节点列表中的 100 ms 当成某个下载速度等级。

url-test 原理：计时的是一次代理 HTTP 探测

url-test 是策略组类型。内核通过候选代理访问指定测试 URL，记录耗时，再据此选择节点。客户端里的手动延迟按钮也常通过内核控制接口发起类似测试，但按钮与策略组可能使用不同地址、不同超时，因此两处数字不一定一致。

一次测试经过哪些环节

1. 读取测试地址，确定要测试的代理或策略组。
2. 建立到代理服务的连接，完成该代理协议要求的连接过程。
3. 通过代理访问目标；使用 HTTPS 时还涉及目标 TLS 协商。
4. 发送 HTTP 探测请求，在内核规定的计时边界内取得响应。

不同内核版本的连接复用、计时起点和请求实现可能存在差异。测试不应被精确等同于 ICMP ping，也不是严格的单次网络往返时延。更准确的说法是：它反映当时通过该代理完成小型 HTTP 探测的耗时，其中包含连接、握手及响应等待等成本。

为什么不能测出带宽

常用的 generate_204 地址返回很小的响应，204 表示没有响应内容。请求没有持续传输足够的数据，无法观察链路在数十秒负载下的吞吐表现。一次响应快，只说明这条测试路径当时完成得快，不代表大文件传输不会限速。

测试通常也不等同于按业务规则访问网站。它是对指定代理的探测，不足以证明浏览器请求确实命中了同一个节点。要确认实际路径，需查看客户端的连接记录、匹配规则和最终代理链。

测试地址：换 URL 会改变排名

测试结果同时受“本地到代理入口”和“代理出口到测试站点”影响。测试站点位于哪里、是否采用 CDN、目标域名如何解析，都可能改变结果。某节点访问测试站点很快，却访问你的业务服务器很慢，完全可能。

HTTP 与 HTTPS 不宜混着比较

HTTP 测试通常少了目标 TLS 协商，数字可能更低，但只能说明 HTTP 探测结果。HTTPS 更接近日常加密网页访问，也可能暴露证书或系统时间问题。比较节点时应保持地址、协议和超时一致，而不是拿一个 HTTP 结果与另一个 HTTPS 结果直接排序。

• 优先选择响应小、长期稳定、无需登录的地址。
• 遇到全部节点超时，先换第二个测试地址交叉验证。
• 不要把大量节点的自动测试指向有严格访问限制的业务接口。
• 修改前记录原地址，避免换地址后误判为网络突然变好或变差。

自动选择配置：interval 与 tolerance 各管一件事

下面是适用于支持 include-all 的 mihomo 内核的策略组片段，不是完整订阅。它从完整配置中的代理节点及代理提供者纳入候选项；必须先有真实的代理配置。传统 Clash 或旧版内核不一定支持该字段，应按对应内核文档使用 proxies 或 use 明确引用已有对象。

proxy-groups:
  - name: 自动选择
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 代理出口
    type: select
    proxies:
      - 自动选择
      - DIRECT

自动选择 和 代理出口 都在片段中定义了，但它们不会自动接管所有流量。完整配置中的规则还需要引用相应策略组。保留订阅原有规则结构，先确认目标请求指向哪个组，再决定是否替换；不要为了测试把整份规则直接改成全局代理。

容差不是“低于 50 ms 才可用”，也不是固定给所有结果加 50 ms。它影响自动选择的切换判断。例如当前节点约 130 ms，另一节点约 110 ms，20 ms 的改善可能不足以触发切换；最终行为还取决于内核实现与节点可用状态。

超时设置：5000 ms 是等待上限，不是网速门槛

超时表示探测没有在规定时间内完成。超时设置为 5000 ms，只是最多等待约 5 秒；把它调到 10000 ms，可能让部分慢请求得到结果，却不会增加节点带宽。也不要直接把 timeout 写进任何策略组：字段是否支持、放在哪里，必须按对应内核的配置说明确认。

用控制接口理解超时参数

支持 Clash 风格控制 API 的内核通常提供代理延迟接口。以下命令仅用于本机诊断，假设控制接口已在 127.0.0.1:9090 启用，且本例接口无需鉴权。测试对象是内置 DIRECT，用于观察直连基线，不是某个订阅节点：

curl --get "http://127.0.0.1:9090/proxies/DIRECT/delay" \
  --data-urlencode "url=https://www.gstatic.com/generate_204" \
  --data-urlencode "timeout=5000"

成功时可返回类似 {"delay":186} 的结果，表示此次测得 186 ms；这只是格式示例。测试具体节点时，需要将路径中的 DIRECT 换为实际代理名称，并对名称进行 URL 路径编码。中文、空格和斜杠不能直接随意拼接。

若接口启用了 secret，请求需要携带对应 Bearer 鉴权头；没有权限时出现的 401 不是节点超时。不要为方便测试把控制接口开放到公网。端口 9090 也不是固定要求，以客户端当前运行配置为准。

全部超时时按这个顺序排查

1. 确认内核正在运行，订阅中的节点已加载，而不是只看到了旧列表。
2. 换第二个测试 URL；若只有一个地址失败，先查目标可达性。
3. 查看日志中的 DNS、连接拒绝、TLS 与超时信息，区分失败环节。
4. 确认系统日期时间正确，排除 HTTPS 证书时间异常。
5. 在相同超时下测试两个不同节点，必要时再比较直连基线。

真实网速：固定节点、固定目标、重复测量

要比较两个节点，先把自动选择改为手动固定候选节点，或者使用已有的手动选择组。测试过程中频繁换出口，会让结果难以归因。浏览器页面复用连接、服务端缓存和后台下载，也会干扰比较。

一套可复现的测试步骤

1. 固定条件：使用同一设备、同一 Wi-Fi 或有线网络，暂停其他大流量任务。
2. 确认路由：在连接记录里核对目标域名、匹配规则和最终节点，避免下载实际走了 DIRECT。
3. 重复小请求：每个节点测试 5 次，记录全部数值，不只记最低值。
4. 观察持续传输：使用获准访问的同一个大文件，持续观察 30～60 秒，区分刚开始的突发速度与稳定速度。
5. 换时间复测：例如 10:00 与 21:00 各测一轮，记录是否出现晚间吞吐下降或超时增多。

假设五次延迟为 82、85、87、91、680 ms，中位数是 87 ms，但最后一次大幅波动值得关注。这组数值是计算示例，不是实测报告。小样本 HTTP 测试中的失败比例也不能直接叫“网络丢包率”；它可能由 DNS、TLS、目标站或连接超时造成。

延迟低、下载慢，优先查这几项

• 代理出口拥塞：小请求仍能快速完成，大流量却在高峰时段竞争带宽。
• 目标服务器限速：不同文件站、不同 CDN 对同一出口可能有不同限制。
• 本地无线网络：信号不稳与重传会拖慢持续传输，改用有线连接可做对照。
• 协议与设备负载：加密处理、CPU 占用及客户端资源限制可能影响吞吐。
• 路径不一致：测速按钮与业务请求用了不同节点，或者应用根本没遵循系统代理。

最后一种情况尤其常见。浏览器可以正常代理，不代表所有应用都走同一条路径。不遵循系统代理的程序可能需要应用内代理或 TUN 接管；TUN 改变的是流量进入内核的方式，不会凭空增加出口带宽。入门设置可参考系统代理步骤，概念区别可查看概念速查。

选节点结论：按使用场景，而不是只按毫秒排序

网页浏览优先看响应稳定与目标可达性；大文件下载优先看持续吞吐；视频重点看缓冲速度和播放中断；语音会议与实时业务还要观察抖动、断流及相应 UDP 路径。HTTP 延迟测试不能证明 UDP 转发可用，也不能替代应用内网络诊断。

• 日常浏览：保留一个稳定节点，或使用带合理容差的自动选择组。
• 大文件任务：比较实际下载速度，开始后尽量保持出口稳定。
• 某个网站异常：先确认命中规则，再比较该网站的实际访问表现。
• 晚间卡顿：按同一条件复测，别只看上午保存的延迟数字。

最实用的记录只有几项：测试时间、测试 URL、超时、最终节点、重复延迟和持续下载速度。信息齐全后，才能分清是探测目标问题、节点路径问题，还是本地配置问题。需要更换客户端时，先看客户端对比，再按平台选择，不必为追求更小的延迟数字反复重装。