Clash 节点延迟测试怎么看：测速数值与实际网速不一致的原因

先区分延迟、吞吐量与稳定性

先用延迟筛掉明显不可用的节点，再用实际业务判断速度。Clash 列表里的 80 ms 通常表示一次探测所用的时间，不表示下载带宽，也不保证视频能持续播放。节点甲测出 80 ms、节点乙测出 160 ms，不能据此推断甲的下载速度是乙的两倍。

把“快”拆成三个指标，排查会更直接。打开网页关注建立连接和收到首字节的速度；下载文件关注持续吞吐量；视频会议和游戏还要关注丢包、抖动，以及实际使用的 UDP 路径。一次 HTTP 探测只能覆盖其中一小部分。

例如，持续下载 10 MiB/s 约等于 83.9 Mbit/s；这里的 MiB 按 1024² 字节计算。运营商常用 Mbit/s 标注接入带宽，下载工具可能使用 MB/s 或 MiB/s。先看单位，再比较数字，避免把相差约八倍的单位当成线路故障。

看懂 Clash 延迟测试的请求路径

先确认客户端做的是哪种测试。许多 Clash 客户端调用内核的 URL 延迟测试：通过指定节点访问一个测试地址，记录请求完成所需的时间。它不是简单地对节点服务器执行 ICMP ping，也不是持续下载大文件。

一次 URL 测试包含哪些环节

1. 内核准备节点连接，必要时解析节点服务器域名。
2. 连接代理服务器，并完成对应代理协议的握手。
3. 经代理访问测试站点；使用 HTTPS 时还涉及 TLS 握手。
4. 取得测试响应，再由内核或客户端展示结果。

具体计时边界、连接复用方式和结果展示取决于内核及客户端版本。不要把所有客户端显示的毫秒数都解释为完整网页加载时间。测试时使用的缓存、已有连接，以及测试目标是否需要额外解析，也会影响结果。

操作时先打开客户端的连接记录，再刷新目标网页。核对目标域名、命中规则和策略链，确认出口后再比较延迟。开启 TUN 只改变流量接管方式，不会自动增加节点带宽，也不能把 HTTP 测试变成 UDP 性能测试。

统一测试地址与超时条件

比较节点前，先统一测试 URL、网络环境和测试时间。常见测试地址 https://www.gstatic.com/generate_204 返回很小的 HTTP 204 响应，适合检查短请求连通性。响应体很小，正是它不能代表大文件传输能力的原因。

测试地址并非中立的“全网速度标尺”。目标服务的部署位置、CDN 调度、出口网络互联和访问限制，都会改变结果。某条线路访问这个地址只需 90 ms，访问实际业务站点却需要 300 ms，两者并不矛盾。

按同一条件完成一轮比较

• 固定同一条 Wi-Fi 或有线网络，暂停系统更新和云盘同步。
• 选两个候选节点，使用同一个 HTTPS 测试地址。
• 每个节点分散测 10 次，间隔约 5 秒，记录成功次数与延迟中位数。
• 将手动测试超时统一为 5000 ms；若客户端不能修改，记录其实际默认值。
• 再用实际网站验证，不把更换测试地址后的结果直接混进原始记录。

超时是等待上限，不是速度目标。若结果显示 timeout，只能说明本次请求没有在时限内完成，或测试流程遇到了连接、解析、TLS 等错误。把 3000 ms 改成 10000 ms 后出现数值，只能证明等待更久后可能成功，不能证明线路已经变快。

遇到“所有节点都超时，但网页能打开”，先看日志中的具体错误，再检查测试地址和客户端是否实际使用了预期内核。遇到“测试正常，但某个网站打不开”，则应检查该网站的规则、DNS、出口限制与认证状态，而不是立即提高测试超时。

排查延迟低但下载慢的原因

检查带宽限制与共享拥塞

小响应只传输少量数据，即使节点被限制为 5 Mbit/s，也可能显示不错的延迟。但 5 Mbit/s 的理论上限只有约 0.625 MB/s，扣除协议开销后还会更低。此时继续挑选低十几毫秒的节点，通常不能解决大文件下载缓慢的问题。

晚高峰也会出现类似现象。共享出口尚能快速处理一次小请求，却无法持续提供足够带宽。分别在 09:00 和 21:00 下载同一个文件，若只有晚间持续速度明显下降，而本地直连测试正常，就应优先怀疑代理路径或出口拥塞。

检查丢包与重传

少量丢包可能没有出现在某次延迟结果里，却会让长连接反复重传、缩小发送窗口。连续十次短请求全部成功，也不足以证明长时间传输稳定。可以同时观察下载曲线是否反复归零、连接是否重建，以及系统网络工具中的 TCP 重传变化。

中间路由器对 ICMP 响应限速，也可能让链路探测看起来存在丢包。因此不要只凭某一跳的 ping 丢包判定故障；应结合最终目标、业务连接失败和持续传输表现。尤其不能把 HTTP 探测失败比例直接写成链路真实丢包率。

检查目标站点、设备与本地网络

• 换另一个允许下载的大文件来源，排除单站限速与 CDN 缓存差异。
• 使用有线网络复测，或靠近路由器，排除 Wi-Fi 干扰。
• 观察任务管理器或活动监视器，检查 CPU 是否持续接近满载。
• 暂停其他设备的上传。上传占满后，确认包与交互请求也可能排队。

视频起播慢还可能涉及清单请求、分片服务器、账号区域和解码过程。客户端显示的一个延迟数值，既无法覆盖完整播放链路，也不能证明这些环节都正常。

用固定流程记录实际速度

先手动固定一个节点，再打开实际业务。测试期间不要让自动选择组切换出口，也不要同时进行全节点并发测速。若修改了节点或规则，关闭旧页面并新建连接；已经建立的连接不一定立即改走新出口。

用 curl 分开观察请求耗时

下面的命令通过本机 127.0.0.1:7890 的 HTTP 或 mixed 代理端口访问示例站点。先在客户端确认实际端口；若不是 7890，按本机配置修改。Windows 使用 curl.exe 可避免部分 PowerShell 环境中同名命令的差异。

curl --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output response.html --silent --show-error --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

time_connect 在这里主要反映连接本地代理的耗时，不能当作远端节点延迟。time_appconnect 与 time_starttransfer 是从请求开始累计的阶段时间；它们不是可以直接相加的独立耗时。该命令适合比较同一 URL 的请求阶段，不适合测带宽。

再测持续下载，而不是只看起步峰值

1. 选择有权限访问、大小足够的固定文件，保证测试能持续约 30 秒。
2. 固定单连接或多连接方式；比较两个节点时不能混用。
3. 跳过开始几秒的波动，记录稳定阶段的速度与停顿次数。
4. 每个节点重复三轮，留出间隔，避免把瞬时缓存结果当长期表现。

下面是示意记录，用于说明判断方式，不是本站实测，也不代表具体节点质量。两者都完成 10 次探测，下载方式与文件保持一致。

在这组条件下，大文件下载应优先考虑节点乙。若主要使用短请求交互，还需要比较实际站点的首字节时间和失败情况。没有一个毫秒阈值能够同时决定所有业务的体验。

理解 url-test 自动选择的边界

使用 mihomo 的 url-test 策略组时，自动选择依据仍是指定 URL 的探测结果，不是带宽排名。下面是配置片段，需要合并进已有配置；节点甲 和 节点乙 必须对应配置中已经存在的真实节点名称。

proxy-groups:
  - name: 自动延迟
    type: url-test
    proxies:
      - 节点甲
      - 节点乙
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300 表示按 300 秒的周期检查，不是测试超时。
• tolerance: 50 设置切换容差，减少因几十毫秒波动而频繁换节点；它不限制下载速度。
• lazy: true 使未使用的组可以跳过周期检查，不保证空闲时始终保留最新结果。

这段配置适用于支持相应字段的 mihomo 环境。客户端可能通过覆写、订阅合并或界面设置改变最终配置；以实际加载配置和日志为准。修改前保留可用副本，避免下一次订阅更新覆盖本地调整。

如果下载任务需要稳定出口，可以使用手动选择组固定节点。降低切换频率有助于保持行为可预测，但不能保证所有长连接都不断开；节点本身的可用性、客户端连接处理和目标站点状态仍然重要。

按症状完成最后一轮检查

延迟低，网页仍然卡顿

先核对浏览器连接的策略链，再查看开发者工具的网络面板。区分 DNS、连接、等待响应和内容下载阶段。若只有一个资源域名耗时异常，检查它是否被另一条规则送到不同出口；不要用首页域名的测试结果代替所有子资源。

延迟高，下载却很快

先确认测试目标是否绕路，再观察持续吞吐量。长距离线路可能具有较高的往返时间，但只要可用带宽充足、丢包较少，持续下载仍然可以很快。对大文件任务，这类节点不必仅因毫秒数较大而淘汰。

延迟忽高忽低，偶尔出现超时

先在相同时间比较有线网络与 Wi-Fi，再暂停上传任务，重复 10 次探测。若本地网络稳定但所有候选节点同时波动，检查接入线路；若只有一个节点波动，再检查对应代理路径。使用实际站点复核，避免将测试服务自身的异常误判为全部节点故障。

保留三项结论即可：实际走哪个出口、短请求是否稳定、持续传输能达到多少。先把这三项测清楚，再决定换节点、调规则或检查本地网络。延迟数字用于缩小范围，最终选择由实际业务表现决定。