Clash 节点延迟测试原理:为什么显示的毫秒数不等于实际网速

延迟数字实际测量了什么

Clash 客户端显示的 38 ms、126 ms 或 480 ms，通常不是传统意义上的 ICMP Ping，也不是下载速度。客户端一般要求 Clash 或 mihomo 内核通过指定代理节点访问一个 HTTP 或 HTTPS 测速 URL，再记录从发起请求到收到有效响应所用的时间。不同客户端的按钮名称可能是“延迟测试”“测速”或“健康检查”，但核心目标相近：确认节点能否连接，并估算一次短请求的往返时间。

常见测速地址会返回 HTTP 204。204 响应没有正文，传输量很小，适合重复探测。例如 https://www.gstatic.com/generate_204 和 https://cp.cloudflare.com/generate_204 都属于这类地址。由于响应体接近于零，测试结果主要反映连接建立与请求响应速度，无法反映节点持续传输 100 MB 文件时能达到多少 MB/s。

一次 HTTPS 延迟测试可能包含的步骤

Clash 接收客户端发出的测试指令，并选定一个代理节点。
内核解析节点服务器地址，建立到节点入口的 TCP 或其他传输连接。
完成 Shadowsocks、VMess、VLESS、Trojan 或其他协议需要的握手。
通过节点连接测速站点，并完成到目标站点的 TCP 与 TLS 握手。
发送 HTTP 请求，等待状态码和响应头返回。
客户端把整段耗时换算为毫秒并显示。

具体计时边界取决于客户端和内核版本。有的实现每次创建新连接，有的健康检查可能复用部分资源；有的把 DNS 解析计入时间，有的会命中 DNS 缓存。因此，两个客户端同时测试同一节点，出现 20 至 80 ms 的差异并不罕见。判断节点状态时，应优先比较同一设备、同一客户端、同一测速 URL 下的结果。

为什么低延迟节点仍然很慢

低延迟说明短连接探测较快，但网页加载、软件下载和视频播放还会受到吞吐量、丢包、目标站线路与服务器负载影响。测速请求只有少量响应头，即使节点出口限速为 5 Mbps，也可能在 50 ms 内完成一次 204 请求。真正下载文件时，5 Mbps 的理论上限约为 0.625 MB/s，速度差异才会持续显现。

节点带宽或共享入口拥塞

代理入口通常由多个用户共享。晚上 20:00 至 23:00 的并发流量可能明显高于上午。节点在空闲时延迟为 45 ms，繁忙时仍可能保持在 58 ms，但下载速度从 18 MB/s 降到 2.4 MB/s。原因是小请求仍能迅速排队完成，而大流量会持续争用出口带宽。

丢包与抖动没有直接显示

客户端常常只显示最近一次成功测试，或者显示几次结果中的某个值。假设连续十次结果为 52、54、55、53、410、超时、61、58、390、57 ms，界面如果只保留最后一次 57 ms，就会隐藏明显的抖动和丢包。网页中的大量并发请求会反复遇到重传，表现为图片分批出现、页面偶尔停顿。

测速站与实际目标站线路不同

节点到测速 URL 的路由很短，不代表到代码托管、视频平台或网盘的路由同样理想。节点访问测速站可能走本地互联，延迟只有 35 ms；访问实际目标站时却绕行其他地区，首字节时间达到 900 ms。测速 URL 只能代表它本身，不能替代对目标业务的验证。

本地链路与设备负载

2.4 GHz Wi-Fi 干扰会造成重传，短测试偶尔正常，大文件传输却持续波动。
TUN 模式下，杀毒软件、系统防火墙和其他网络过滤程序可能增加处理时间。
低性能路由器处理加密流量时可能达到 CPU 上限，延迟数字仍低，但吞吐无法提升。
浏览器扩展、并发下载和系统后台更新会占用本地带宽，影响体感。
MTU 设置不合适时，部分连接可能出现分片、重传或特定网站加载停滞。

为什么高延迟节点也能流畅播放视频

视频播放依赖持续吞吐和缓冲区，不要求每个数据片段都在几十毫秒内返回。一个延迟为 180 ms、稳定速度为 25 MB/s 的节点，通常可以比延迟 45 ms、速度只有 2 MB/s 的节点更快填满缓冲区。播放开始后，只要下载速率长期高于视频码率，较高延迟对连续播放的影响就很有限。

以 4K 视频为例，若平均码率为 25 Mbps，换算后约为 3.125 MB/s。节点能稳定提供 12 MB/s，即使延迟达到 220 ms，也有足够余量维持播放。相反，一个延迟 30 ms 但晚高峰速度在 1.5 至 4 MB/s 之间波动的节点，可能频繁耗尽缓冲区。

交互操作与大流量任务看重不同指标

使用场景	更重要的指标	常见表现
打开网页、在线文档	延迟、首字节时间、丢包	低延迟通常让多个小请求更快完成
视频播放	持续吞吐、抖动、可用带宽	延迟较高仍可依靠缓冲保持流畅
大型文件下载	持续速度、出口限速、线路稳定性	开始几秒的峰值不能代表平均速度
远程终端、云桌面	往返延迟、抖动、丢包	80 ms 与 250 ms 的操作反馈差异明显
语音与实时通信	延迟、抖动、UDP 可用性	带宽足够时仍可能因抖动出现断续

测速 URL 会怎样改变结果

测速地址的位置、协议和响应状态都会影响数字。选择 HTTPS 地址时，测试一般包含 TLS 建连；选择 HTTP 地址时则少一层 TLS。测速站距离节点出口较近，结果会偏低；测速站跨洲或响应繁忙，结果会偏高。若测速站被目标网络限制，节点本身正常也可能显示超时。

选择测速 URL 的三个标准

响应稳定：连续访问时状态码一致，避免跳转、验证码和动态页面。
响应很小：使用 204 或小型静态文件，避免健康检查持续消耗流量。
符合实际用途：主要访问某一地区服务时，测速站也应能代表该地区的出口质量。

不要把两个不同 URL 得到的毫秒数直接排序。例如节点 A 访问亚洲测速站为 48 ms，节点 B 访问欧洲测速站为 130 ms，这组数据没有公平比较的基础。批量测试时应确保节点组使用相同 URL、相同超时时间和相近的测试时刻。

url-test 与健康检查如何配置

Clash 和 mihomo 配置中的 url-test 策略组会定期测试候选节点，并选择当前延迟较低的节点。它适合自动选择，但不等于持续测试下载速度。interval 控制检测周期，单位通常为秒；tolerance 用于减少延迟接近时的频繁切换。

proxy-groups:
  - name: 自动选择
    type: url-test
    use:
      - 机场订阅
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

这段配置每 300 秒检查一次。“自动选择”组不会因为新节点只快 10 ms 就立即切换；设置 tolerance: 80 后，差异较小时会优先保持当前节点，从而减少连接中断。对于网页浏览，50 至 100 ms 的容差通常比毫秒级追逐更实用。实时会议期间也不建议把周期设成 10 秒，因为频繁检测和切换会增加不必要的连接变化。

代理提供者还可以单独配置健康检查。下面的片段表示每 600 秒确认一次订阅内节点是否可达：

proxy-providers:
  机场订阅:
    type: http
    path: ./providers/airport.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

lazy: true 表示在相关代理提供者没有被使用时减少主动检查，具体行为以所用内核版本为准。若客户端已经通过图形界面管理配置，直接编辑运行时生成的 YAML 可能在订阅更新后被覆盖。应优先在客户端的覆写或合并配置功能中添加规则。例如 Clash Verge Rev 2.x 常见操作路径为「设置」→「订阅设置」→ 选择配置 →「编辑全局扩展配置」，完成后重新加载订阅并检查运行配置。

更接近真实体验的测试方法

选择节点时，可以把测试拆成“响应速度”“持续吞吐”“稳定性”三组，而不是只点击一次闪电按钮。所有对比都应固定设备、网络、时间段和代理模式。Wi-Fi 与有线网络混测、系统代理与 TUN 模式混测，都会让结论失去可比性。

第一步：重复测延迟并看中位数

在 Clash Verge Rev 2.x 中进入「代理」→ 目标策略组。
点击策略组右上角的测速按钮，等待整组节点完成。
对候选节点重复测试 5 至 10 次，每次间隔约 10 秒。
记录中位数、最高值和超时次数，不只记录最低值。

一组结果为 68、71、69、74、70 ms，中位数是 70 ms，波动很小；另一组为 42、45、310、超时、53 ms，最低值更好但稳定性较差。网页浏览和远程操作通常更适合第一组。

第二步：测持续下载而不是瞬时峰值

选择来源稳定、距离用途接近的 100 MB 至 500 MB 测试文件，连续下载至少 30 秒。忽略刚开始 2 至 3 秒的峰值，记录第 10 秒、第 20 秒和第 30 秒速度。例如节点 A 延迟 46 ms，三次读数为 8.2、7.9、7.8 MB/s；节点 B 延迟 128 ms，读数为 30.5、31.4、30.8 MB/s。下载任务明显应选节点 B。

测速会产生实际流量。移动网络或按量计费线路应缩小文件尺寸，并停止其他下载任务。浏览器开发者工具中的「网络」面板可以查看请求耗时；以 Chromium 系浏览器为例，按 F12 后进入「网络」，选择目标请求，在“计时”中观察“等待服务器响应”和“内容下载”阶段。

第三步：检查目标业务

网页使用场景：连续打开 5 个常用页面，观察首屏是否快速出现。
视频场景：固定为相同清晰度，记录起播时间和 10 分钟内缓冲次数。
下载场景：使用同一个文件源，记录 30 秒平均速度。
远程连接：连续操作 3 至 5 分钟，观察键盘反馈和画面跳变。
TUN 模式：分别测试开启前后结果，确认问题是否来自系统代理覆盖范围。

延迟异常时按环节排查

所有节点同时变高

先检查本地网络。关闭正在运行的云盘同步和系统更新，使用有线连接或 5 GHz Wi-Fi 再测。如果直连网页也明显变慢，问题更可能出在本地宽带、移动网络或路由器。重启 Clash 只能重建代理连接，无法修复运营商链路拥塞。

只有一个地区变高

同地区多个节点同时从约 80 ms 上升到 300 ms，可能是跨境路由调整或区域入口拥塞。可临时选择另一个地区，并分别在白天和晚高峰测试。若凌晨恢复、晚间反复升高，通常比客户端配置错误更符合拥塞特征。

测速超时但网页可打开

更换测速 URL 后复测，并确认 DNS 模式正常。使用 Fake-IP 时，测速域名会先获得保留地址，再由 Clash 在连接阶段恢复域名；若规则把测速域名错误分到直连或拒绝策略，测试可能失败。检查日志中的目标域名、命中规则和出站节点，可以确认请求是否真正经过待测代理。

延迟正常但部分网站很慢

在日志中确认该网站是否命中了预期策略组。Clash 规则自上而下匹配，首条命中后停止。目标网站如果被更靠前的 DOMAIN-SUFFIX、GEOSITE 或 IP-CIDR 规则分到其他节点，策略组里显示的低延迟就与实际连接无关。还应检查浏览器是否启用了独立代理、HTTP/3 或安全 DNS，避免流量路径与预期不同。

节点排序应同时看四个数字

单一毫秒数适合快速排除不可用节点，不适合决定全部使用场景。更稳妥的记录方式包括延迟中位数、最大抖动、超时率和持续下载速度。例如节点甲的数据是 72 ms、抖动 12 ms、超时率 0%、平均 14 MB/s；节点乙是 41 ms、抖动 280 ms、超时率 20%、平均 6 MB/s。虽然节点乙显示的最低延迟更小，节点甲通常更适合作为默认节点。

自动策略组也应保留一定容差。两个节点分别为 64 ms 和 71 ms 时，7 ms 差异通常不足以抵消切换现有连接的成本。只有在延迟差异长期稳定，或吞吐和目标站体验也更好时，切换才有实际意义。把测速结果当作筛选入口，再用真实任务验证，得到的节点选择会比按一次测试结果排序可靠得多。