Clash 节点延迟测试原理:测速数值与实际网速为何对不上

延迟数值测量的是一次请求，不是下载带宽

Clash 客户端节点列表中的“测速”，通常指通过指定代理访问一个测试 URL，并显示内核报告的耗时。结果以毫秒（ms）表示。它不是持续下载测试，也不是向代理服务器发送一次 ICMP Ping。客户端界面即使写着“延迟”，背后的测量对象仍需结合内核与测试设置判断。

这能解释一种常见现象：某节点显示 80 ms，但下载文件只有 500 KB/s；另一节点显示 180 ms，却能稳定下载到 10 MB/s。前者完成小请求较快，后者具有更高的持续吞吐能力。两项指标描述不同阶段，不存在必然的高低对应关系。

单位也容易造成误读。网络带宽常用 Mbps，下载工具常用 MB/s；按十进制换算，100 Mbps 的理论上限约为 12.5 MB/s，实际传输还要扣除协议开销。延迟中的 100 ms 与带宽中的 100 Mbps 没有换算关系。

URL Test 的连接与握手过程

以 HTTPS 测试地址为例，可以把访问路径拆成几个环节。它们用于理解故障位置，不代表所有内核版本都会分别计时、分别显示，也不能把界面数值视为这些阶段固定相加的精确结果。

1. 准备节点地址。如果代理服务器使用域名，建立连接前需要获得对应地址。结果可能来自缓存，也可能触发新的解析请求。
2. 连接代理服务器。客户端按照节点协议建立传输连接。TCP、基于 UDP 的传输以及不同加密协议的准备过程并不相同。
3. 建立到测试目标的通道。代理出口需要能够到达目标站点。目标域名由哪一侧解析，取决于协议与相关配置。
4. 完成目标 HTTPS 交互。通常涉及目标站点的 TLS 握手与 HTTP 请求，并在达到内核定义的响应条件后结束计时。

实际计时边界、连接复用、重试策略和 HTTP 请求方法可能随内核版本变化。不要把一个客户端显示的“连接延迟”，直接当成另一个客户端采用同一公式得到的结果。横向比较时，应统一客户端、内核、测试 URL 和网络环境。

为什么系统 Ping 很低，Clash 延迟仍然很高

对节点服务器执行 Ping，只观察本机到该服务器的 ICMP 往返。URL Test 还受代理协议处理、出口到目标站点的路径和目标响应影响。服务器也可能限制 ICMP，导致 Ping 丢包而代理请求正常。两种测试应分别记录，不能互相替代。

测试地址决定测到哪一段网络

常见测试 URL 使用返回 HTTP 204 的小响应端点，例如 https://www.gstatic.com/generate_204。204 表示没有响应正文，传输负担小，适合频繁检查连通性，但也意味着它几乎不能反映大文件传输能力。

同一出口访问不同域名，可能进入不同 CDN、不同地区的接入点。某节点到测试端点的路径较短，不代表它到视频、代码仓库或办公服务的路径也短。把测试目标换成另一个站点后，节点排名改变属于正常现象。

选择测试 URL 的三个条件

• 响应小且稳定。优先使用明确用于连通性检查的端点，避免首页图片、登录跳转和持续变化的内容。
• 协议保持一致。比较节点时固定使用同一个 HTTPS URL。HTTP 与 HTTPS 的交互过程不同，不应混成一组排名。
• 另做业务验证。用统一端点筛选节点，再在实际应用中验证。不要频繁请求带有登录凭据或敏感查询参数的链接。

还需要区分三类入口：节点旁的手动测试、url-test 策略组的自动测试，以及 proxy-providers 的健康检查。它们可能分别设置 URL、间隔与超时。只修改其中一处，其他界面的测试条件未必同步改变。

mihomo 的 url-test 配置与自动选点

url-test 策略组会根据测试结果自动选择成员。下面展示组级配置；其中“香港-01”和“日本-01”是示例中已存在的节点名称。应用到实际配置时，成员名称必须与自己的 proxies 定义一致，否则无法正确引用。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 香港-01
      - 日本-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300：自动检查间隔为 300 秒，而不是 300 毫秒。
• tolerance: 50：以毫秒表示切换容差，用于减少小幅延迟差异引起的频繁换点；它不是超时时间。
• lazy: true：未使用该组时可跳过周期测试，减少后台请求。因此，长时间未使用的组不一定保有刚更新的延迟。

配置项应以当前内核支持范围为准。经典 Clash 与 mihomo 并非每个字段都一致。客户端还可能通过配置覆写或订阅转换改变最终内容，检查时应查看实际运行配置，而不只看订阅原文。有关配置与安装步骤，可查阅全平台指南。

低延迟但下载慢的常见原因

出口限速与共享拥塞

一个很小的 HTTP 响应只需传输少量数据，即使线路限制到 5 Mbps，也可能很快返回。下载 1 GB 文件则需要持续占用带宽，出口限速、共享链路拥塞和服务端限速都会暴露出来。晚高峰出现“延迟变化不大、下载明显变慢”，应重点比较持续吞吐，而非反复点击延迟测试。

丢包与重传影响长连接

偶发丢包可能恰好没有影响一次短测试，却在长时间传输中触发重传和拥塞控制。表现通常是速率锯齿波动、首段正常而随后下降。需要结合多轮请求成功率和下载过程判断，单次最低延迟不能代表稳定性。

业务流量没有经过被测节点

手动测试某节点，不等于浏览器已经选中它。规则可能把目标域名交给另一个策略组，甚至交给 DIRECT。系统代理只影响遵循该设置的应用；TUN 模式的覆盖范围也取决于路由、排除项和客户端配置。应在客户端连接列表中确认目标域名、命中规则、策略组和最终节点。

下载源与本机条件成为瓶颈

远端站点可能按连接、账户或地区限制速度；本机的 Wi-Fi 干扰、后台同步、磁盘写入也会影响观察结果。用两个不同来源重复测试，通常比对同一下载任务不断切换节点更有诊断价值。

timeout 的含义与排查顺序

timeout 表示测试没有在规定期限内完成，不等于已经确认订阅失效。DNS 解析失败、服务器不可达、协议参数错误、目标站点受限，以及当前网络过慢，都可能使一次测试失败。部分客户端会把多类错误统一显示为超时，具体原因应查看日志。

1. 固定网络条件。暂停大流量下载，在同一 Wi-Fi 或有线网络下重测，记录失败发生时间。
2. 区分单节点与全体失败。只有一个节点失败时，优先检查节点信息；所有节点同时失败时，先检查本地网络、DNS 与公共测试目标。
3. 更换一次测试地址。使用另一个稳定的小响应端点。如果只有原地址失败，不能据此判定节点整体不可用。
4. 查看日志错误类型。解析错误、连接被拒绝、TLS 错误与等待超时，对应不同处理方向。TLS 异常还应检查系统日期与时间。
5. 核对超时设置的位置。手动测试入口、策略组与提供者健康检查可能采用不同期限。增大某一处的数值，不保证其他入口随之变化。

例如，测试期限为 5 秒时，耗时 6 秒才完成的请求会被判失败。放宽到 10 秒可能让它显示成功，但不能改善线路本身。超时期限用于界定等待多久，不是加速参数。持续出现数秒级响应时，应继续检查网络路径，而不是只追求界面显示成功。

用同条件对照判断节点质量

下面是一套可重复执行的筛选流程。数字用于说明记录方法，不代表本站对某个节点的实测结果。比较时保持设备、测试 URL、下载来源和时间窗口一致，每次只更换节点。

1. 先测短请求。每个节点执行 5 轮 URL Test，间隔约 10 秒，记录全部数值与失败次数，不只保留最好的一次。
2. 再测持续传输。选择允许测速的固定下载源，持续观察 30～60 秒，分别记录刚开始和进入稳定阶段后的速率。留意流量消耗。
3. 确认实际出口。在连接列表中检查该任务使用的节点。切换策略后重新建立任务，旧连接未必立即迁移。
4. 复测业务应用。视频观察启动、拖动进度和缓冲；网页观察首屏与连续访问；远程会话观察输入响应和断连。
5. 跨时段复查。至少对比一个日间和一个晚间窗口，避免把某一分钟的结果当成长期质量。

这组示例中，节点 A 的短请求更快，节点 B 的大文件传输更合适。如果 5 轮里有 2 轮超时，应另外写明“成功 3/5”，不要只把剩余 3 次的均值当成完整结果。对交互应用，较小且稳定的延迟更重要；对大文件和高码率视频，持续吞吐与成功率同样关键。

最终选择应回到实际任务：先用 URL Test 排除明显不可达的节点，再用真实应用确认路径与表现。延迟是筛选依据之一，不是网速评分，也不是所有站点的可用性证明。