Clash 延迟测试数字怎么看:为什么 80ms 的节点反而更卡

Clash 延迟测试实际测量了什么

Clash 界面中显示的 80 ms、150 ms 或 500 ms，通常不是传统意义上的 ICMP Ping。以 Clash Premium、Clash for Windows 0.20.39 以及使用 mihomo 内核的 Clash Verge Rev 2.3.x 为例，客户端一般会让内核通过指定代理节点访问一个测试 URL，再记录请求完成所需的时间。常见地址包括 https://www.gstatic.com/generate_204 和 https://cp.cloudflare.com/generate_204。服务器返回 HTTP 204，正文为空，因此适合用于连通性检查。

这次请求会经过本机 Clash 内核、节点入口、代理传输链路、节点出口和测试站点。测得的数字可能包含 TCP 建连、TLS 握手、代理协议握手以及等待 HTTP 响应的时间，具体范围取决于内核版本、连接是否复用、测试 URL 和客户端实现。因此，数字更接近“一次很小的网页请求耗时”，不能直接等同于本机到节点服务器的物理往返时延。

测试 URL 会改变结果

测试目标并非中立标尺。假设节点出口位于东京，访问位于亚洲且互联良好的测试站可能得到 75 ms；将地址换成路由较远、连接策略不同的站点，同一节点可能变成 160 ms。若测试站对某个出口 IP 限速、拒绝连接或触发 TLS 异常，Clash 还可能显示超时，但这不一定代表所有网站均不可用。

为什么 80ms 节点反而比 150ms 更卡

80 ms 只说明某一次小请求较快。网页浏览、视频播放、代码拉取和云盘下载会建立多条连接并持续传输数据，体验还受丢包、抖动、带宽、拥塞和出口质量影响。低延迟节点若每隔数秒出现重传，使用感受通常会差于延迟稍高但稳定的节点。

丢包会触发重传与拥塞控制

TCP 需要保证数据按顺序到达。某个数据段丢失后，即使后续数据已经抵达，也可能需要等待重传。一次 URL Test 只传输少量数据，刚好没有撞上丢包时便会显示 80 ms；打开包含几十个资源的网页后，连接数量和数据量增加，暴露丢包的概率随之上升。

可以连续观察 100 次请求，而不是只看单次结果。例如节点 A 的中位数为 82 ms，但第 95 百分位达到 780 ms，并有 3% 请求失败；节点 B 的中位数为 148 ms，第 95 百分位为 190 ms，失败率为 0%。对于网页和会议连接，节点 B 往往更稳定。单次最低值不能代表整段使用期间的质量。

延迟低不代表可用带宽高

URL Test 的响应正文通常为空，几乎不测试持续吞吐能力。一个限速为 5 Mbps 的节点可以在 70 ms 内返回 204，但下载 500 MB 文件时理论上仅传输数据就需要约 800 秒；另一个 160 ms、可稳定提供 80 Mbps 的节点完成同样数据量会快得多。视频进入高码率阶段后，带宽不足还会表现为频繁降清晰度和缓冲。

晚高峰拥塞与队列延迟

家庭宽带上行、运营商跨境链路和节点入口都可能发生排队。空闲时测得 80 ms，开始下载后延迟升到 600 ms，属于典型的负载延迟上升。此时页面点击响应会变慢，即便测速软件仍能显示较高吞吐量。判断节点时应分别在空闲状态与传输状态下观察延迟，不能只记录凌晨的一组数字。

• 空闲延迟：没有明显上传或下载任务时测量，反映基础路径。
• 负载延迟：持续下载或上传期间测量，反映队列管理与拥塞状态。
• 抖动：多次结果之间的波动，例如 80、83、79 ms 较稳定，80、420、95 ms 则不稳定。
• 失败率：超时次数除以测试总次数，连续使用时比单次最低值更重要。

URL Test、健康检查与自动选择的区别

手动点击“延迟测试”通常只更新界面中的当前结果；配置文件里的 url-test 代理组则会周期性测试成员，并按照结果自动选择。代理提供者的 health-check 负责检查节点是否可用。这三个功能可以使用相似的请求方式，但触发时机和用途不同。

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

proxy-providers:
  provider-main:
    type: http
    url: https://example.invalid/profile.yaml
    path: ./providers/provider-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

这段示例中，interval: 300 表示自动选择组按设定周期进行测试，tolerance: 80 用于减少延迟相近节点之间的频繁切换。若当前节点仍处在容差范围内，内核不必因为几毫秒差距立刻迁移连接。lazy: true 表示代理组未被实际使用时可以减少不必要的主动测试。不同 Clash 分支支持的字段存在差异，使用前应以当前 mihomo 或客户端内核文档为准。

自动选择不会迁移所有既有连接

代理组从节点 A 切换到节点 B 后，新连接通常使用新的选择；已经建立的 TCP 连接或长连接未必立即迁移。正在播放的视频、SSH 会话或下载任务可能继续占用旧连接，直到应用重连。测试数字已经变小而当前页面仍然卡顿时，可新开无痕窗口或完全结束对应连接再复测。

用四组指标判断节点质量

可靠的判断至少需要延迟分布、丢包与失败率、持续吞吐量、出口与目标站位置四组信息。测试时应固定本机网络，暂停系统更新和云盘同步，并避免同时切换 Wi-Fi 与有线网络。每个候选节点观察 5 至 10 分钟，比连续点击十次按钮后选择最低数字更有效。

第一组：记录中位数与高位延迟

平均值容易被少数极端结果拉高或拉低。可以记录 20 至 100 次结果，重点看中位数、最大值和第 95 百分位。若没有统计工具，至少检查结果是否集中。以下两组数据的平均值接近，但稳定性完全不同：

第二组：检查代理请求失败率

系统的 ping 命令可能被节点入口防火墙禁用，也可能只测到服务器入口，而实际代理流量还要经过出口。因此，ICMP 丢包只能作为补充。更贴近 Clash 使用方式的办法，是通过本机代理端口重复请求同一个测试地址。

curl -x http://127.0.0.1:7890 \
  -o /dev/null -s \
  -w "connect=%{time_connect} total=%{time_total} code=%{http_code}\n" \
  https://www.gstatic.com/generate_204

示例假设 Clash 的 HTTP 或 Mixed 端口为 7890。如果客户端配置为 7897 或其他端口，应使用「设置」→「参数设置」中显示的实际端口。连续执行时关注 total 的波动、HTTP 状态码以及是否发生超时。测试同一节点 50 次出现 2 次超时，失败率就是 4%，这种节点不适合作为需要持续稳定连接的默认选择。

第三组：分时段测试持续吞吐量

选择来源可信、容量足够的固定文件，持续下载 30 至 60 秒，记录稳定阶段而非刚启动时的瞬时峰值。分别在工作日上午、20:00 至 23:00 晚高峰测试。若节点从白天 70 Mbps 降到晚间 8 Mbps，而另一节点始终保持 35 Mbps，后者更适合作为长期默认节点。

测速会实际消耗订阅流量，也会增加节点负载，不需要频繁下载数 GB 文件。验证网页和 1080p 视频时，100 至 300 MB 的样本通常足以发现明显限速；4K 高码率、系统镜像或大型仓库拉取则需要更长的稳定传输观察。

第四组：核对入口、出口与目标位置

节点名称中的“香港”“日本”不一定同时代表入口服务器、实际出口和完整路由。中转节点可能先连接境内入口，再经专线到境外出口；公网直连节点则可能由本机直接连接境外服务器。两者的 URL Test 数字相似，晚高峰稳定性和带宽上限仍可能不同。

目标网站的位置也会影响选择。访问东京服务时，日本出口通常路径更短；访问欧洲自建服务器时，欧洲出口可能减少出口到目标站的二次跨洲传输。只按“离本地最近”排序，忽略出口到目标网站的后半程，容易得到低测试延迟但实际业务较慢的结果。

TUN 模式下数字正常但应用仍卡的排查顺序

Clash 延迟测试由内核主动发起，只能证明内核能够通过节点访问测试地址。应用流量是否真正经过同一代理组，还取决于系统代理、TUN 接管、DNS、规则命中和应用自身的代理行为。测试显示 80 ms，而浏览器仍然直连或命中了另一个代理组，两组现象并不矛盾。

1. 确认当前模式。检查客户端处于规则模式、全局模式还是直连模式。规则模式下查看连接列表，确认目标域名命中了预期规则和代理组。
2. 核对系统代理。在 Clash Verge Rev 2.3.x 一类界面中，检查「设置」→「系统设置」或首页的“系统代理”开关。只开启内核但未启用系统代理时，遵循系统代理设置的应用不会自动进入 Clash。
3. 检查 TUN 状态。需要接管不遵循系统代理的应用时再启用 TUN。若状态启动后立即停止，应检查服务安装、管理员权限和虚拟网卡冲突，而不是重复测试节点延迟。
4. 核对 DNS。域名解析失败、Fake-IP 映射异常或局域网 DNS 被劫持，会表现为网页长时间等待。直接访问已知 IP 并不能完整排除 DNS 问题，因为 HTTPS 仍依赖正确域名与证书。
5. 查看连接详情。连接列表应显示目标主机、规则、代理链、上传和下载字节数。若测试节点与实际连接使用的节点不同，先修正规则或代理组选择。
6. 重新建立连接。关闭浏览器标签页、暂停下载并重新打开。HTTP/2、HTTP/3 和 WebSocket 长连接可能继续沿用切换前的路径。

不同使用场景应该优先看什么

对于日常网页，80 ms 与 110 ms 的差距通常没有 0% 与 3% 失败率的差距重要；对于高清视频，150 ms 且稳定提供 60 Mbps 的节点通常优于 70 ms 但只能维持 6 Mbps 的节点；对于远程桌面，平均 90 ms 但频繁跳到 500 ms，会比稳定在 140 ms 更难操作。

更合理的节点选择方法，是先排除超时与高失败率节点，再按使用场景比较稳定性和吞吐量，最后才用延迟细分排序。url-test 适合从一组质量接近的节点中自动选择，不适合替代完整的链路质量评估。看到 80 ms 时，应将它理解为一次测试样本，而不是节点性能的总分。