Clash 延迟测试数字怎么看?显示延迟不等于真实体验的原因

Clash 显示的延迟到底测了什么

客户端节点列表中的 45 ms、168 ms 或 timeout，通常来自一次很小的 HTTP 或 HTTPS 请求。Clash 或 mihomo 会让测试请求经过指定代理节点，访问客户端预设或配置文件指定的测试地址，再记录从发起请求到获得有效响应所用的时间。这个结果适合判断节点能否建立连接、握手是否迅速，却不是完整的下载速度测试。

一次 HTTPS 延迟测试大致会经过本地应用、Clash 入站端口、代理节点、目标网站四个环节。如果目标域名尚未解析，还会先发生 DNS 查询；新连接通常还包含与代理服务器的 TCP 建连、代理协议握手，以及访问测试网站时的 TCP 和 TLS 握手。客户端是否复用连接、是否命中 DNS 缓存，都会影响最终数字。

1. 客户端把测试请求交给指定节点，而不是交给当前自动选择的其他节点。
2. Clash 根据节点协议建立连接，例如 Shadowsocks、Trojan、VLESS 或其他受内核支持的协议。
3. 代理节点继续连接测试 URL 对应的服务器。
4. 目标服务器返回 HTTP 响应，客户端据此计算耗时。

它不是单纯的网络 Ping

系统命令 ping 使用 ICMP 回显报文，而 Clash 的 URL Test 通常使用真实的 HTTP 或 HTTPS 请求。部分服务器会限制 ICMP，但仍允许代理协议和网页流量；也可能出现 Ping 很低、代理握手却很慢的情况。因此，不能把服务器 Ping 值直接当成 Clash 中应当出现的延迟。

同一节点在两个客户端里显示 70 ms 和 130 ms，也未必是内核异常。需要先核对测试 URL、超时时间、是否使用 HTTPS、连接是否复用，以及测试时本地网络是否相同。手机使用 5G、电脑使用有线宽带时，两组结果本来就不适合直接横向比较。

URL Test 的路径与自动选择逻辑

url-test 是 Clash 代理组类型之一。它会定期测试组内节点，并选择当前结果较低的可用节点。常见配置会使用能够快速返回 204 状态的地址，减少响应正文对测量的干扰。下面是一段可读性较高的示例：

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 节点-A
      - 节点-B
      - 节点-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval: 300 表示测试间隔为 300 秒，也就是 5 分钟。间隔不是越短越好：设置成 10 秒会制造额外连接和日志，也容易因瞬时波动频繁切换节点。日常使用可从 300 至 600 秒开始，移动网络变化较快时再适当缩短。

tolerance: 50 用于控制切换灵敏度。假设当前节点为 120 ms，另一个节点测得 92 ms，两者只相差 28 ms，通常没有必要立即切换；如果新节点降到 60 ms，差距达到 60 ms，切换才更有实际意义。容差可以减少 80 ms、95 ms、110 ms 之间反复跳转造成的连接中断。

测试 URL 会改变结果

测试目标离代理出口越远，结果通常越高。东京出口访问东京附近的测试服务器可能只有 35 ms，访问欧洲目标则可能超过 220 ms。若日常主要使用某项服务，可以选一个稳定、响应体很小且路径具有代表性的 HTTPS 地址，但应确认该地址允许长期正常访问。

• 测试地址稳定性：目标站点限流或故障时，所有节点都可能显示超时。
• HTTP 与 HTTPS：HTTPS 会覆盖 TLS 建连成本，更接近日常网页访问。
• DNS 解析路径：不同的 nameserver、fake-ip 或 redir-host 设置可能带来不同的首次测试耗时。
• 出口位置：同一代理节点访问不同地区的目标，路由长度和拥塞程度不同。
• 缓存状态：第一次测试可能包含 DNS 和握手成本，紧接着的第二次测试可能更低。

为什么几十毫秒的节点看视频仍然卡

视频播放依赖持续吞吐，而延迟测试只传输极少的数据。一个节点可以在 45 ms 内完成小请求，却只能持续提供 2 Mbps 带宽。播放码率约 15 Mbps 的 4K 视频时，缓冲区消耗速度明显高于下载速度，结果就是频繁停顿。反过来，一个 180 ms 但能稳定传输 80 Mbps 的节点，首次打开页面稍慢，却可能更适合大文件和视频。

延迟、带宽、丢包与抖动是四个指标

例如某节点连续五次测试为 48、52、51、49、55 ms，平均值约 51 ms，波动很小；另一个节点结果为 35、280、62、410、44 ms，虽然最低值只有 35 ms，但抖动极大。节点列表如果只展示最近一次的 35 ms，就会掩盖后续请求频繁变慢的问题。

丢包对 TCP 传输尤其明显。TCP 发现数据未到达后会重传，并可能降低拥塞窗口。即使基础往返延迟只有 60 ms，持续出现 2% 至 5% 的丢包也可能让下载曲线呈锯齿状。UDP 语音或游戏流量通常不会等待完整重传，表现则是声音缺段、位置更新延后或画面突然跳动。

服务端负载和线路时段同样重要

代理服务器 CPU、内存、连接数或上游带宽接近上限时，小型探测请求仍可能快速返回，但大流量传输会受到限制。晚间 20:00 至 23:00 的跨网拥塞也很常见：白天测试为 70 ms，晚间可能在 90 ms 至 400 ms 之间跳动。只在上午测一次，不能代表晚间实际体验。

目标服务对不同出口地址的调度也会改变速度。同一个节点访问测试 URL 很快，访问视频服务时却可能被分配到距离较远的 CDN；某些出口还可能遇到目标站点限速。此时问题发生在代理出口到目标服务之间，不一定是用户设备到代理服务器这一段。

用一组可复现步骤判断真实体验

更可靠的判断方式不是寻找一个绝对最低数字，而是在相同设备、相同网络和相同时间段下，比较多轮结果。测试前先暂停云盘同步、系统更新和大文件下载，避免后台流量占满带宽。手机测试时固定使用 Wi-Fi 或蜂窝网络，不要在两者之间自动切换。

第一步：连续测五次延迟

1. 打开客户端的代理或节点页面，找到需要比较的同一个代理组。
2. 保持测试 URL 不变，连续执行五次，每次间隔约 10 秒。
3. 记录最低值、最高值和大致平均值，不只看最后一次结果。
4. 若五次分别为 82、87、79、91、84 ms，可视为较稳定；若为 60、320、75、timeout、180 ms，应优先排查抖动和丢包。

图形客户端菜单名称各不相同，通常可在「代理」→「代理组」→「延迟测试」找到测试入口；部分客户端也会在「设置」→「参数设置」中提供测试 URL 和超时时间。修改前先记下原值，避免因不可访问的地址导致所有节点都显示失败。

第二步：测试持续吞吐

选择两个或三个延迟较稳定的节点，分别进行至少 30 秒的实际下载或视频播放。观察的是稳定速度而非刚开始的一次峰值。例如下载速度先冲到 18 MB/s，5 秒后长期停留在 1.2 MB/s，这个节点的可持续吞吐更接近 1.2 MB/s。进行比较时应使用同一个目标文件、同一时间段，并避免多线程任务互相抢占带宽。

若视频是主要用途，可分别播放固定分辨率内容，并观察 60 秒内缓冲区是否持续增长。1080p 视频所需码率会随编码和内容变化，不能仅凭“能打开”判断；4K 内容对持续吞吐和线路稳定性要求更高。测试期间频繁手动切换节点会中断已有连接，因此每轮应单独完成。

第三步：按业务类型选择

• 浏览网页：优先选择延迟稳定、握手快的节点，带宽达到日常需求即可。
• 视频与下载：优先比较持续吞吐和晚高峰稳定性，不必执着于最低延迟。
• 语音与游戏：重点观察丢包、抖动和 UDP 可用性，平均延迟只是其中一项。
• 远程终端：交互对往返延迟敏感，应选择连续测试波动较小的线路。
• 移动网络：电梯、地铁和基站切换会显著改变结果，应在实际使用位置测试。

TUN 模式、DNS 与本地网络如何影响结果

TUN 模式会接管更多系统流量，但它不会自动提升代理服务器带宽。启用 TUN 后，应用流量可能从原来的系统代理路径改为虚拟网卡路径，DNS 劫持、路由表、MTU 和防火墙规则也会参与处理。因此，开启前后的延迟差异需要结合日志和实际连接路径判断，不能简单归因于内核性能。

先排除本地 Wi-Fi 抖动

如果本地路由器本身就不稳定，所有节点都会受到影响。可以先比较有线连接与 Wi-Fi，或把设备移动到路由器附近再测试。2.4 GHz 频段在拥挤环境中容易受到干扰，5 GHz 通常更适合近距离高吞吐，但隔墙衰减更明显。出现所有节点同时从 80 ms 上升到 500 ms 时，应先检查本地链路，而不是立即更换订阅。

DNS 慢会拖长首次连接

使用域名作为服务器地址或测试地址时，DNS 查询速度会影响首次连接。若解析结果异常、上游 DNS 超时，客户端可能先等待数秒才开始真正的代理握手。Clash 的 fake-ip 模式会为域名分配保留地址并在内部映射真实域名，但最终的上游解析和代理出口连接仍需要正常完成。

排查时可以查看 mihomo 日志中是否反复出现 DNS timeout、connection refused 或 i/o timeout。若仅某个测试域名失败，替换为另一个稳定的小响应地址进行对照；若所有域名都失败，则检查 nameserver、网络权限和系统时间。TLS 证书校验依赖正确时间，系统日期偏差过大可能让 HTTPS 测试直接失败。

MTU 问题可能只在大流量时暴露

小型延迟请求能够成功，不代表较大的数据包一定正常。TUN、VPN 叠加或特殊宽带环境中，MTU 设置不合适可能引起分片或黑洞问题：网页小请求可用，大文件传输却停顿。若启用 TUN 后仅大流量异常，可对比关闭 TUN 的系统代理模式，并检查客户端的 MTU 配置、系统中是否同时运行其他 VPN，以及路由是否形成重复接管。

常见误判与配置建议

误判一：延迟最低的节点一定最快

最低延迟只代表某次短请求完成得更快。选择视频或下载节点时，还需要至少一次持续 30 至 60 秒的吞吐测试。节点延迟相差 20 ms，但稳定速度相差 40 Mbps 时，后者对大流量任务通常更关键。

误判二：一次 timeout 就说明节点失效

一次超时可能来自测试站点故障、DNS 查询失败、本地网络切换或瞬时拥塞。连续测试三至五次，并用另一个测试 URL 对照，才能区分节点故障与探测目标故障。如果只有一个节点持续失败，再检查节点地址、端口、协议参数和订阅更新时间。

误判三：把测试间隔设得越短越准确

过短间隔会增加请求量，也会使自动组对瞬时变化过于敏感。普通家庭网络可使用 300 秒间隔和 30 至 100 ms 的容差作为起点，再根据节点数量和使用场景调整。实时业务需要稳定连接时，应避免自动组频繁切换，因为已有 TCP 会话通常不会无感迁移到新节点。

误判四：开启 TUN 就能修复所有卡顿

TUN 的主要作用是扩大流量接管范围，适合不遵循系统代理的应用，并非线路加速开关。服务器拥塞、出口限速和远端 CDN 路由问题不会因 TUN 自动消失。应先确定是流量没有进入 Clash，还是流量已经代理但传输质量较差，再决定是否调整模式。

一套更接近真实体验的结论

阅读 Clash 延迟数字时，可以把它理解为“当前节点完成一次指定 URL 小请求的耗时”。它能快速筛掉无法连接、握手明显过慢的节点，也能为 url-test 自动选择提供依据，但不能单独回答视频是否流畅、下载能跑多快或游戏是否稳定。

实际选择时先看五次延迟的波动，再看 30 至 60 秒持续吞吐，最后在常用时段验证目标服务。网页和远程终端更重视稳定低延迟，视频和下载更重视持续带宽，游戏与通话还要检查丢包、抖动及 UDP 路径。把这几项分开测，才能解释“显示几十毫秒却仍然卡”的真正原因。

如果所有节点同时变慢，应依次检查本地 Wi-Fi、测试 URL、DNS、系统时间和晚高峰拥塞；如果只有单个节点异常，再检查该节点的服务器负载、出口路由与协议配置。按照这一顺序排查，比反复刷新延迟或盲目切换模式更容易定位问题。