Clash 延迟测试数字怎么来的:为什么 60ms 的节点看视频照样卡

延迟数字测到的到底是什么

在 Clash、Clash Meta（mihomo）及其图形客户端里点击一次延迟测试，内核通常会让指定代理节点访问一条测试 URL，并记录请求从发起到得到有效响应所用的时间。常见目标是返回 HTTP 204 的轻量地址，例如 https://www.gstatic.com/generate_204。界面上的 60ms，描述的是这次小请求完成得很快，不是节点每秒能传多少数据。

一次测试可能包含代理连接建立、目标域名解析、到目标服务器的 TCP 建连、TLS 握手、HTTP 请求与响应。具体覆盖哪些阶段，取决于内核版本、协议实现、连接是否复用以及测试入口。某些客户端调用 mihomo 外部控制接口执行单节点测试；配置中的 url-test 组和代理提供者健康检查，则由内核按周期执行。它们都输出毫秒值，但执行时机和连接状态不一定完全相同。

它不是网络往返时间的纯粹等价物

系统里的 ping 常用 ICMP 回显包测试网络层往返，而 Clash 延迟测试走的是代理协议和 HTTP 请求路径。节点可能禁止 ICMP，却能正常代理 HTTPS；也可能 ICMP 很低，但代理服务器负载过高，认证与加密处理很慢。因此，命令行 ping 得到 35ms、客户端显示 68ms，并不构成冲突。

本机到节点：家庭宽带、Wi-Fi、运营商出口会产生第一段耗时。
代理握手：Trojan、VLESS、Shadowsocks、Hysteria2 等协议的传输与握手过程不同。
节点到测试站：出口线路决定第二段路由，绕行会直接抬高数字。
测试站响应：目标服务器位置、负载、限速和 CDN 调度都会进入结果。
瞬时状态：丢包重传、CPU 抢占、无线干扰可能只影响某一次请求。

为什么 60ms 的节点看视频仍然卡

视频播放需要持续吞吐。以常见码率估算，1080p 视频可能需要稳定的 5Mbps 到 10Mbps，4K 内容可能需要 20Mbps 到 40Mbps，峰值还会更高。延迟测试只下载极小响应，几十毫秒就结束，无法观察节点在传输数十兆字节后是否限速、丢包或拥塞。

带宽不足：首包快，后续数据挤不动

某节点可以在 60ms 内完成握手，但共享出口在晚高峰只有 2Mbps 可用带宽。网页打开时只需传几百 KB，看起来反应很快；视频缓冲区持续消耗数据后，下载速度追不上播放速度，就会频繁停顿。这是最典型的“低延迟、低吞吐”。

反过来，180ms 的远距离节点如果能稳定提供 50Mbps，点击播放后的起始响应略慢，却可能在缓冲完成后连续播放。延迟影响交互等待，吞吐决定大文件和视频能否持续灌入，两者是不同指标。

抖动和丢包：平均值掩盖尖峰

连续五次结果是 58ms、61ms、63ms、420ms、超时，客户端有时只展示最近一次或经过筛选的结果。用户看到的仍可能是 61ms，但实际链路存在明显抖动。TCP 遇到丢包会重传并收缩拥塞窗口；基于 UDP 的传输也会因线路质量下降而增加恢复成本。视频分片下载表现出来就是速度忽高忽低。

判断抖动时不要只看最低值。连续测试 10 次，如果大部分位于 55ms 到 70ms，只有一次达到 90ms，通常比“最低 42ms、最高 680ms、两次超时”的节点更可控。游戏、语音和远程桌面对尖峰尤其敏感。

测试站与视频站走的不是同一条出口路径

测试 URL 可能命中离节点很近的 CDN，而实际视频服务被调度到另一地区。节点访问测试站只需经过 6 跳，访问视频 CDN 却可能跨洲绕行。即使两个目标都使用 443 端口，自治系统、对等互联和拥塞点也可能完全不同。

地区解锁还会改变内容节点。一个标注为美国的出口可能快速访问 Google 测试地址，但视频服务把它识别为数据中心网络，分配到负载较高的 CDN；另一个延迟稍高的住宅出口反而能得到更合适的内容边缘节点。只按绿色数字排序，会漏掉这层差异。

本机链路和客户端模式也会介入

2.4GHz Wi-Fi 在拥挤信道上容易出现重传，节点测试偶尔正常，大流量传输时问题放大。
TUN 模式接管系统流量后，MTU 设置不合适可能造成分片、丢包或部分站点加载停滞。
浏览器启用 QUIC，而当前节点或线路对 UDP 支持较差，视频连接可能频繁回退。
规则把测试 URL 交给代理，却把视频域名分到另一个策略组，两个结果没有直接可比性。
本机 CPU 满载、播放器硬件解码失效，也会呈现“视频卡”，但此时代理下载速度未必异常。

测试 URL、缓存与连接复用怎样改变结果

测试地址必须足够小、响应明确、长期可访问。返回 204 的地址不携带正文，可以减少下载量对结果的干扰。不过，“减少干扰”不等于“代表所有网站”。选择不同地区的 URL，同一节点的结果可能相差数十甚至数百毫秒。

用同一测试地址比较，才有横向意义

节点 A 用 Google 204 测得 70ms，节点 B 用另一家国内 CDN 测得 25ms，这两个数字不能直接排序。目标服务器不同，路由终点也不同。批量测试应该让所有候选节点访问同一 URL、使用相同超时，并尽量在同一时间段执行。

如果主要用途是访问海外开发服务，可以保留一个稳定的 HTTPS 204 地址做初筛；如果主要用途是某个视频平台，还要补充真实播放或该平台静态资源的测试。不要把需要登录、返回大页面或经常跳转的 URL 放进健康检查，否则认证、重定向和页面体积会污染数据。

缓存不会凭空增加带宽

DNS 缓存可省掉一次解析，TLS 会话恢复可减少握手开销，HTTP 连接复用则可能跳过重新建连。连续点击测试时，后几次低于第一次并不罕见。这个变化说明短连接准备成本下降，不代表节点出口扩容。

客户端和内核版本对连接池、健康检查及并发测试的处理可能不同。一次批量测试同时压几十个节点，本机线程调度、DNS 查询和路由器 NAT 表也会产生额外波动。需要复核时，间隔 2 到 5 秒单独测目标节点，比反复点击全量测试更有参考价值。

超时不是“无限延迟”

当超时设为 5000ms，结果显示 timeout，只能说明请求没有在 5 秒内完成。原因可能是节点失效、目标 URL 被阻断、DNS 失败、TLS 错误或网络暂时丢包。先换一个已知可访问的测试 URL，再判断节点本身是否离线。

mihomo 中的 url-test 和健康检查怎么读

url-test 策略组会定期检测组内节点，并倾向选择当前延迟较低的可用项。它适合自动选择，但不是实时带宽调度器。一个节点在健康检查时返回 55ms，随后进入晚高峰拥塞，内核不会因为视频速度下降就立即知道它的吞吐变差。

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

proxy-providers:
  airport-main:
    type: http
    path: ./providers/airport-main.yaml
    url: https://example.net/subscription.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000
      lazy: true
      expected-status: 204

这里的 interval: 300 表示每 300 秒检查一次，timeout: 5000 把单次健康检查超时设为 5000ms。tolerance: 50 用来减少延迟接近时的频繁切换：当前节点与候选节点只差几十毫秒时，保持现有连接通常比来回切换更稳。lazy: true 则让内核在策略组未被实际使用时减少不必要的检测。

不要把间隔压到 5 秒。假设提供者里有 80 个节点，每 5 秒全部探测一次，会制造持续的小请求，也可能触发服务端频率限制。桌面日常使用可从 300 秒起步；线路变化很快时可尝试 60 到 120 秒，再观察日志和资源占用。

通过外部控制接口复核单节点

mihomo 常见外部控制监听地址是 127.0.0.1:9090。如果配置了访问密钥，可以对一个明确节点发起延迟测试。节点名和测试 URL需要先进行 URL 编码。

curl -H "Authorization: Bearer local-secret" "http://127.0.0.1:9090/proxies/HK-A-01/delay?timeout=5000&url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204"

不要为了远程查看而把 9090 直接暴露到公网。桌面端保持环回监听即可。需要局域网控制时，应设置访问密钥，并用系统防火墙限制来源地址。代理端口也要分清：常见的 7890 是 mixed-port，9090 是控制接口，两者职责不同。

一套更接近真实体验的节点判断方法

可靠的选择流程不是寻找最低数字，而是分层筛选。先用延迟和可用性排掉明显故障节点，再测持续吞吐、抖动和目标站点，最后结合倍率与地区做决定。整个过程不需要把每个节点跑满，只要让指标覆盖真实用途。

第一步：连续测试，不看单次冠军

固定同一个 HTTPS 测试 URL，超时设为 5000ms。
对候选节点连续测试 5 到 10 次，每次间隔 2 秒以上。
记录中位数、最高值与超时次数，不只记最低值。
淘汰连续超时、波动超过数百毫秒或频繁掉线的节点。

例如节点 A 的结果集中在 75ms 到 88ms；节点 B 的最低值是 48ms，但其余结果在 60ms 到 530ms 之间。网页浏览也许两者都能用，会议和游戏则优先选择 A。中位数稳定、极端值少，通常比偶然刷出的最低值更有意义。

第二步：做 20 到 30 秒持续下载

选择可信的测速站或大文件源，通过当前策略组下载 20 到 30 秒。观察速度能否稳定，而不是只看瞬时峰值。某节点开头冲到 18MB/s，5 秒后掉到 700KB/s，说明突发带宽不错但持续能力不足；另一个节点稳定在 6MB/s，实际看高清视频往往更省心。

测试会消耗订阅流量。倍率为 2.0 的节点下载 500MB，计费可能按 1GB 计算。流量有限时可缩短测试时间或降低文件体积，不必对几十个节点逐一跑完整测速。

第三步：直接测目标业务

视频：播放 1080p 或 4K 内容 5 分钟，观察缓冲速度和是否自动降清晰度。
开发：测试 Git 拉取、软件包索引和容器镜像，确认目标仓库路由正常。
游戏：看实际游戏内延迟、丢包和晚高峰稳定性，不用网页测速替代。
会议：持续通话 10 分钟，关注声音断裂和上行质量；下载快不代表上传稳。
远程桌面：快速拖动窗口并输入文字，交互抖动比峰值带宽更关键。

第四步：核对 Clash 规则是否选中了同一节点

延迟测试针对的是节点或策略组，实际网站流量则先经过规则匹配。若配置里 DOMAIN-SUFFIX,example-video.com,MEDIA 命中 MEDIA 组，而手动测试的是 PROXY 组，数字再漂亮也解释不了视频表现。

rules:
  - DOMAIN-SUFFIX,example-video.com,MEDIA
  - DOMAIN-SUFFIX,example-cdn.net,MEDIA
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

排查时打开客户端连接页面，开始播放后按域名筛选，查看命中的规则、策略组和最终节点。以常见桌面客户端为例，路径通常是「连接」→「搜索域名」→「展开连接详情」；配置修改则从「配置」→「编辑当前配置」进入。不同客户端菜单名称略有差异，但要确认的三项不变：目标域名、命中规则、实际出站。

延迟异常时按什么顺序排查

先把问题拆成设备、本地网络、节点和目标站四层。不要一看到红色数字就立刻重装客户端。以下顺序能快速缩小范围。

检查本地网络：有线连接和 5GHz Wi-Fi 各测一次，排除无线拥堵。
切换测试 URL：原地址全部超时时，用另一条稳定的 204 地址交叉验证。
比较 DIRECT：直连访问测试站也慢，问题可能在本地运营商或目标站。
查看内核日志：搜索 timeout、DNS、TLS、connection reset 等错误。
核对系统时间：时间偏差会导致 TLS 证书校验失败，看起来像节点不可用。
暂时关闭并发下载：网盘、系统更新和云同步会占满上行或下行。
检查 TUN 参数：仅在 TUN 模式异常时，测试系统代理模式并比较结果。

如果所有节点同时从 80ms 上升到 800ms，优先看本地网络和订阅服务入口；如果只有一个地区异常，通常是该地区线路或出口问题；如果延迟正常但特定网站慢，应转向规则、DNS、目标 CDN 和地区解锁排查。

结论：把延迟放回它该在的位置

Clash 延迟测试最适合回答两个问题：节点此刻能否通过代理访问测试 URL，以及短请求完成速度大致处于什么水平。它适合做可用性检查和第一轮排序，不适合单独预测带宽、视频清晰度、游戏丢包或晚高峰稳定性。

看到 60ms 时，可以把它理解为“短请求响应较快”，不要翻译成“节点一定快”。继续看多次测试的波动、20 到 30 秒持续吞吐、目标业务表现和规则实际命中。延迟、带宽、抖动、丢包、地区、倍率与协议共同决定体验，任何一个数字都不能包办结论。

继续检查 Clash 节点

先安装适合当前平台的客户端，再按教程导入订阅、核对规则命中与 DNS 设置。

去下载页看教程