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

面板里的毫秒数测量了什么

Clash、Clash Meta（现常用名称为 mihomo）以及调用其控制接口的图形客户端，通常把节点测试结果显示为一个毫秒数。这个数字经常被称为“延迟”或“测速”，但它既不是传统命令行工具对服务器执行的 ICMP Ping，也不是对节点可用带宽的完整测试。它更接近一次经由指定代理节点完成的 HTTP 请求耗时。

测试开始后，客户端或内核会使用选中的代理节点访问测试 URL。过程中可能包含代理服务器连接、协议握手、到目标网站的出口连接、TLS 握手、HTTP 请求发送以及响应头返回。不同内核版本、测试地址协议和连接复用状态会改变计时边界，因此两个客户端即使测试同一个节点，也不保证显示完全相同的结果。

一次常见延迟测试的请求路径

1. 客户端向 mihomo 控制接口发起节点延迟测试请求。
2. 内核从本机连接节点服务器，例如服务器的 TCP 或 UDP 监听端口。
3. 内核完成 Shadowsocks、Trojan、VLESS、Hysteria2 或其他代理协议所需的握手。
4. 节点服务器从出口网络连接测试 URL 对应的目标服务器。
5. 如果 URL 使用 HTTPS，还要完成 TLS 握手并验证证书。
6. 目标服务器返回 HTTP 响应，内核停止计时并向客户端报告毫秒数。

因此，面板上的 80 ms 不能直接解释为“本机到节点的物理往返延迟是 80 ms”。它还可能包含节点到测试站点的路径和应用层握手。反过来，显示 220 ms 也不一定代表下载速度低；只要线路带宽充足、丢包较少、拥塞控制稳定，单连接下载仍可能达到较高吞吐量。

它与系统 Ping 的差别

ping 通常发送 ICMP Echo 数据包，观察目标主机回应所需的往返时间。很多代理服务器会限制或完全不回应 ICMP，但代理端口仍能正常接受 TCP 或 UDP 流量。也有服务器对 ICMP 路径进行了不同的路由或优先级处理，所以命令行 Ping 为 45 ms、Clash 面板显示 110 ms 并不矛盾。

HTTP 延迟测试更接近日常网页请求，但仍只是一个很小的样本。测试响应常见为空内容或极短内容，几乎不会持续占用链路。它能够揭示“建立连接需要多久”，却无法说明连接建立后每秒能传输多少数据。

测试 URL 如何改变结果

测试 URL 不是装饰字段。节点延迟值会同时受目标站点的位置、DNS 解析、HTTP 或 HTTPS 协议、目标服务器负载、CDN 调度和运营商路由影响。同一个节点访问位于东京的测试站点与访问位于法兰克福的测试站点，出口段路径明显不同，结果可能相差数十到数百毫秒。

204 地址为什么常用于连通性测试

常见地址包括 http://www.gstatic.com/generate_204、https://www.gstatic.com/generate_204 和 https://cp.cloudflare.com/generate_204。这类接口正常时返回 HTTP 204，响应不携带正文，传输量很小，适合频繁执行连通性与延迟检查。

HTTP 地址省去了 TLS 握手，数值通常更偏向连接与首个 HTTP 响应的耗时。HTTPS 地址会增加证书协商和加密握手，更贴近日常 HTTPS 网站，但首次连接数值可能更高。如果客户端复用了已有连接，后续测试还可能比首次结果低。比较节点时应固定 URL、超时值、客户端版本与网络环境。

配置中的 URL 与超时值

在 mihomo 配置中，url-test 类型代理组可指定测试地址、检查间隔和容差。以下配置每 300 秒检查一次候选节点；当新节点只比当前节点快很少时，tolerance 可减少频繁切换。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 东京-01
      - 新加坡-01
      - 洛杉矶-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

interval: 300 表示周期检查间隔为 300 秒，不代表每个用户请求都重新测速。tolerance: 80 的单位是毫秒，用于给节点切换保留差值空间。lazy: true 表示代理组未被使用时可减少主动检查。具体支持情况应以当前 mihomo 内核版本和客户端生成的配置为准。

控制接口也可以执行单节点测试。典型请求形式为 GET /proxies/节点名/delay，并携带 timeout 与 url 查询参数。图形客户端的“测试延迟”按钮通常在内部完成这一步。若控制器监听在 127.0.0.1:9090，请求只应由本机受信任程序访问；启用局域网控制时还需要设置访问密钥并限制防火墙来源。

低延迟节点为什么仍然卡顿

延迟低只说明短请求在测试时刻返回较快。网页打开、视频播放、云盘下载和在线会议还依赖吞吐量、抖动、丢包、并发连接、DNS 结果和目标网站出口。任一环节出现瓶颈，都可能形成“面板 60 ms，实际加载缓慢”的情况。

带宽限制与共享拥塞

节点可能快速完成一个几十字节的 204 响应，但可用带宽只有 5 Mbps。按理想换算，5 Mbps 约为 0.625 MB/s；下载 500 MB 文件至少需要约 800 秒，还未计算协议开销和速度波动。若节点的入口或出口由大量用户共享，凌晨测试可达 80 Mbps，晚间同一路线可能只剩 8 Mbps，短延迟测试未必立即反映这种差异。

带宽也可能受单连接限制影响。有些线路多连接下载看起来较快，单连接视频却无法稳定；另一些线路总带宽足够，但短时间突发后被限速。评估时应记录持续 30 至 60 秒的速度曲线，而不是只看下载刚开始的峰值。

丢包、抖动与 TCP 重传

平均延迟无法描述每次请求的波动。连续五次结果为 62、65、61、64、180 ms，平均值仍不算高，但第五次的突增会影响游戏、语音和远程桌面。若链路存在 2% 丢包，TCP 会重传数据并调整拥塞窗口；大文件下载的吞吐量可能明显下降，而一次成功返回的 204 测试仍会显示绿色数字。

UDP 类业务更容易暴露抖动。游戏和实时语音通常不等待丢失的数据包重传，连续 20 至 40 ms 的延迟变化就可能表现为瞬移、声音断续或输入反馈不稳定。此类用途应关注一段时间内的最大延迟、抖动范围与丢包比例，而不是只选择最低的单次结果。

节点到目标网站的出口不同

测试 URL 响应快，不代表所有网站都走同一出口。节点到 Cloudflare、Google、GitHub、流媒体 CDN 和企业办公服务可能采用不同路由。某个新加坡节点访问当地 CDN 只有 45 ms，但访问位于美国东部的业务服务器仍可能超过 230 ms。视频站还可能根据节点出口 IP 分配不同 CDN 边缘节点，使真实路径与延迟测试路径完全不同。

判断特定网站问题时，应直接通过该节点访问目标业务，而不是只反复点击全局延迟测试。浏览器开发者工具的“网络”面板可以查看 DNS、连接、TLS、等待首字节和内容下载阶段。若等待首字节很短但内容下载很慢，问题更接近吞吐量；若连接阶段已经耗时很长，则应检查握手、路由或丢包。

本机处理、DNS 与 TUN 模式

TUN 模式会接管更多系统流量，并依据配置执行 DNS 劫持、路由判断和协议栈处理。性能正常的设备上，这些开销通常不是主要瓶颈；但旧设备、高 CPU 占用、第三方安全软件过滤或多个虚拟网卡叠加时，实际体验可能下降。此时面板延迟测试由内核直接执行，未必经过与浏览器、游戏完全相同的系统路径。

DNS 配置也会造成“节点延迟正常但网站慢”。例如域名被解析到距离节点出口很远的 CDN 地址，连接仍能成功，却绕行了不合适的区域。使用 fake-ip 模式时，还应确认需要真实 IP 的局域网设备、企业域名或特殊应用已加入过滤规则。修改 DNS 配置后应重新载入配置，并清理操作系统或浏览器的 DNS 缓存再复测。

更可靠的节点评估方法

节点选择应拆成连通性、响应、稳定性、吞吐量和目标业务五个维度。先用面板延迟排除不可用或明显绕路的节点，再进行持续测试。这样比单纯按毫秒数从小到大排序更接近真实使用需求。

第一步：固定条件重复测量

1. 暂停正在进行的下载、云盘同步和系统更新。
2. 固定有线网络或同一 WiFi 频段，不在测试中切换移动网络。
3. 为所有候选节点使用同一个 HTTPS 204 地址。
4. 连续测试 5 次，每次间隔 3 至 5 秒，记录最小值、最大值和失败次数。
5. 分别在常用时段和晚间高峰测试，至少保留两组结果。

例如，节点 A 的五次结果为 78、81、79、83、80 ms；节点 B 为 55、210、62、超时、58 ms。节点 B 的最低值更小，但波动和失败更明显。网页偶尔打开很快并不能抵消超时风险，持续使用时节点 A 往往更稳定。

第二步：执行受控下载测试

选择来源稳定、允许测试的 HTTPS 文件，持续下载 30 至 60 秒。每个节点使用相同文件、同一下载工具和相近时间段，避免把测试站点自身限速误判为节点限速。记录稳定阶段速度，不采用最初 1 至 2 秒的缓存峰值。

速度单位也要统一。客户端显示 40 Mbps 时，理论上约等于 5 MB/s，因为 1 字节等于 8 比特。考虑 TCP、TLS 与代理协议开销，实际文件写入速度通常略低。若系统监视器显示的是 MB/s，而测速页面显示 Mbps，直接比较数字会产生八倍误差。

第三步：按用途测试目标业务

• 网页与开发：测试常用搜索、代码仓库、软件包源和文档站，观察首屏与小文件请求。
• 视频：连续播放 10 分钟，检查清晰度切换、缓冲次数和高峰时段稳定性。
• 远程办公：测试会议、远程桌面和公司服务，重点记录抖动与短暂断流。
• 游戏：优先测试对应服务器区域，确认 UDP 可用性、丢包和局内延迟，而非只测通用 204 地址。
• 大文件：观察至少 60 秒的单连接与多连接速度，并检查是否周期性降到零。

第四步：建立简单评分表

可把平均延迟、最大延迟、失败次数、持续下载速度和目标业务表现分别记录。对于网页用途，延迟与稳定性权重可以更高；对于大文件下载，吞吐量权重更高；对于游戏和通话，丢包、抖动与最大延迟通常比平均下载速度更重要。

延迟异常时的排查顺序

当全部节点突然变成超时，先排查本机与订阅状态；当只有一个地区或一个节点异常，再考虑服务器和线路。如果一开始就反复更换 DNS、TUN 协议栈和规则集，会让问题边界变得更模糊。

全部节点显示超时

1. 确认当前配置已成功载入，代理列表中存在可选节点。
2. 检查测试 URL 能否通过当前网络解析，尝试更换为另一个可靠的 HTTPS 204 地址。
3. 确认系统时间准确。时间偏差可能导致 TLS 证书验证失败。
4. 查看客户端日志，重点寻找 timeout、connection refused、TLS handshake 和 DNS 错误。
5. 暂时关闭并重新开启系统代理或 TUN 模式，确认旧进程与虚拟网卡状态已释放。
6. 更新订阅并检查节点地址、端口和认证信息是否发生变化。

很多图形客户端提供“设置”→“日志”或“内核”→“日志”入口，具体菜单名称随客户端版本变化。mihomo 日志级别设为 info 通常足以确认连接阶段；只在需要定位握手细节时短暂使用 debug，完成排查后恢复，避免日志持续快速增长。

只有某个节点超时

先在代理组中切换到同地区其他节点。如果其他节点正常，问题通常集中在该节点的服务器、端口、协议参数或入口线路。若同一服务器承载多个端口，可以分别测试，但不要同时改动协议、SNI、传输层和测试 URL，否则无法确定是哪一项恢复了连接。

Trojan 与使用 TLS 的节点需要正确的服务器名称和证书匹配；WebSocket 节点还依赖 Host 与路径；Hysteria2、TUIC 等 UDP 方案可能受到本地网络或防火墙的 UDP 限制。此类参数应以订阅提供的配置为准，不应仅为降低延迟数字而随意删除。

延迟正常但浏览器仍然慢

1. 确认浏览器流量实际命中了预期代理组，可在客户端连接列表中查看目标域名、规则与出站节点。
2. 检查规则模式下是否有目标域名被错误分到 DIRECT 或另一个代理组。
3. 清理浏览器 DNS 缓存，关闭可能使用独立代理设置的扩展，再重新测试。
4. 对比系统代理与 TUN 模式。如果只有某一种模式异常，检查端口冲突、虚拟网卡和路由表。
5. 测试目标网站而非通用延迟地址，观察连接阶段与内容下载阶段分别耗时多久。

常见本地端口包括 HTTP 代理 7890、SOCKS5 代理 7891、混合端口 7890 和外部控制器 9090，但订阅与客户端可能采用不同值。浏览器手动代理、系统代理和第三方网络工具必须引用当前实际端口。若两个程序同时监听同一端口，内核可能启动失败，日志通常会出现地址已被占用的信息。

从延迟数字得到可执行结论

Clash 面板延迟是一项短请求指标。它把本机到节点、代理协议处理、节点出口到测试站点，以及可能存在的 TLS 与 HTTP 交互压缩成一个数字。这个数字对连通性检查和同条件比较很有用，但无法覆盖带宽、晚高峰拥塞、丢包、抖动、目标网站路由和本机网络栈。

实际选节点时，保留测试条件一致，比追求某一次最低值更重要。连续五次稳定在 90 ms 的节点，通常比在 50 ms 到 300 ms 之间跳动并偶尔超时的节点更适合长期使用。下载用途再加入 30 至 60 秒吞吐量测试，游戏与会议再加入丢包和抖动观察，才能得到与用途匹配的结论。

如果客户端支持 URL-Test 自动选择，可将相近地区的节点放入同一组，设置固定测试 URL、合理的 300 秒检查间隔与一定容差。对必须稳定保持会话的业务，则可选择手动节点或带健康检查的故障转移策略，避免轻微延迟变化触发频繁切换。