Clash 延迟测试原理：界面数值为什么不等于实际访问体验

Clash 客户端中的延迟数字通常被当作节点质量排名，但这个数字只描述一次特定探测。它对应指定测试地址、当前网络、当前 DNS 状态和当时的线路负载，并不等于网页完整加载时间，也不能直接代表下载速度、视频稳定性或长连接质量。理解测试过程后，延迟值仍然有用，只是需要放在正确的范围内解释。

延迟测试测量什么

Clash、Clash Meta（mihomo）及其图形客户端一般通过 HTTP 或 HTTPS 地址进行健康检查。客户端把测试请求交给指定代理节点，等待目标地址返回符合条件的响应，再将过程耗时显示为毫秒数。具体测试 URL、超时时间和实现细节由客户端或配置决定，因此不同客户端对同一节点测出的数字可能不同。

这类结果不是传统意义上的 ICMP Ping。系统的 ping 命令通常发送 ICMP Echo 数据包，而代理延迟测试会建立 TCP 连接，HTTPS 测试还会进行 TLS 协商。若节点使用 WebSocket、gRPC、QUIC 或其他传输方式，接入链路本身也可能增加握手步骤。两种测试面对的协议、端口、路由和服务器处理过程不同，不能直接横向比较。

一次 HTTPS 探测可能包含的阶段

1. 解析测试域名，或者读取已有的 DNS 缓存。
2. 从本机连接代理节点，完成节点协议所需的握手。
3. 由代理侧连接测试目标的 IP 地址。
4. 完成目标站点的 TCP 与 TLS 协商。
5. 发送 HTTP 请求并等待响应头或规定内容。
6. 由核心记录耗时，再由控制接口交给客户端显示。

并非每次探测都会完整执行全部阶段。DNS 缓存、TLS 会话恢复、连接池和客户端实现都可能缩短后续测试。首次结果较高、第二次明显下降，常见原因就是缓存与连接预热，而不一定是节点线路突然改善。

测试目标决定了观察路径

若测试地址部署在距离节点出口较近的数据中心，结果主要反映本机到节点及节点到该数据中心的路径。实际访问的目标可能位于另一个国家、运营商或内容分发网络区域，后半段路由完全不同。因此，一个节点对测试地址响应很快，对特定网站仍可能较慢。

同一节点为什么会出现不同数值

网络延迟不是固定属性。它是某个时间点上多段链路状态的合计。家庭网络、接入运营商、跨网互联、节点入口、节点出口与测试服务器中的任意一段发生排队，都会改变结果。只比较一次点击得到的最低值，会放大偶然波动。

本地无线网络与接入链路

Wi-Fi 信号弱、同频干扰、后台上传和路由器负载都可能增加等待时间。尤其是上行带宽接近占满时，路由器缓冲区会积压数据包，轻量测试也可能从几十毫秒升到数百毫秒。此时切换代理节点通常不能解决问题，因为拥塞发生在流量进入代理之前。

可以先在暂停下载、云盘同步和视频上传后重复测试。如果所有节点同时下降，再恢复后台任务后又一起升高，优先检查本地网络。条件允许时，用有线连接进行一次对照，也能排除部分无线干扰。

DNS 缓存与解析路径

测试域名首次解析需要额外时间。使用 fake-ip 模式时，核心会维护域名与虚拟地址映射，再根据连接还原目标域名；使用 redir-host 或直接返回真实地址的模式时，解析链路又有所不同。上游 DNS 的响应速度、缓存命中情况和是否经过代理，都会影响首轮探测。

需要注意，界面显示的耗时是否包含 DNS 阶段取决于核心版本、测试接口与客户端调用方式。无法确认实现时，应把 DNS 视为潜在变量，而不是根据单个数值反推某一阶段的精确耗时。

连接复用与预热效应

连续点击测试时，底层可能复用已经建立的连接，或者利用系统缓存、TLS 会话票据和已解析地址。后一次测试省去了部分准备工作，因此结果更低。反过来，客户端若强制建立新连接，数值会更接近新建访问的启动成本，但仍不能覆盖网页中的多域名资源与并发请求。

线路拥塞与抖动

节点在晚间高峰、跨网结算点拥塞或出口负载升高时，延迟会周期性变化。假设五次结果依次为 65、68、210、72、190 毫秒，只看最低值会认为线路很快，只看平均值又可能掩盖尖峰频率。更有效的观察方法是同时记录中位数、最大值和超时次数。

低延迟为什么不等于访问更快

网页体验由多个阶段共同决定。延迟测试通常只访问一个轻量地址，而现代网页会加载主文档、脚本、样式、图片、接口和第三方资源。这些资源可能分布在多个域名上，并被不同规则交给不同策略。单个测试请求成功，无法覆盖整个页面的连接图。

带宽与延迟是两个指标

延迟描述请求往返需要多久，带宽描述单位时间能够传输多少数据。一个 40 毫秒但出口带宽较小的节点，打开轻量页面可能很快，下载大文件却慢；一个 90 毫秒但带宽充足且稳定的节点，首次响应略晚，却可能更适合高清视频和大型下载。

下载速度还受 TCP 拥塞控制、接收窗口、丢包重传和目标服务器限速影响。高带宽线路一旦存在持续丢包，也可能因反复重传而无法达到预期吞吐。界面的延迟值通常不直接显示这些信息。

抖动比单次最低值更影响实时业务

语音、远程桌面和交互式连接更关注延迟稳定性。如果测试结果在 50 至 300 毫秒之间来回变化，即使最低值很好，输入响应和音频播放仍会出现不连续。相比之下，稳定在 90 毫秒附近的线路往往更容易形成可预测的体验。

普通延迟测试也不等同于严格的丢包测试。请求超时可以提示严重问题，但少量丢包可能只表现为某次结果突然变高。要分析实时业务，应增加连续观测，并结合系统网络工具、应用日志和实际会话，而不是只看客户端卡片上的一个数字。

规则分流会改变实际出口

Clash 按规则从上到下匹配请求。测试某个策略组时使用的是该组当前节点，但实际网站可能命中另一个策略组、直连规则或兜底规则。例如主站域名走代理，静态资源域名却走直连，页面体验就由多条路径共同决定。

排查时应打开连接列表或核心日志，确认目标域名命中了哪条规则、选择了哪个策略组以及最终使用了哪个节点。仅在策略组页面反复测速，不能验证规则是否把实际流量交给了同一出口。

TUN 模式不会自动降低线路延迟

TUN 模式用于接管更多系统流量，并将 IP 数据包交给核心处理。它能够覆盖不遵循系统代理设置的应用，但不会让物理链路变短。启用 TUN 后，DNS 劫持、路由规则、MTU 和系统防火墙配置会参与数据路径；配置不合适时，反而可能出现部分网站慢、连接建立失败或大包传输异常。

比较系统代理与 TUN 模式时，应保持节点、规则、测试目标和网络环境一致。若只有 TUN 模式异常，可检查 DNS 接管、路由排除范围、IPv6 行为与 MTU，而不是直接认定节点质量变化。

url-test、fallback 与手动策略组怎样使用延迟

Clash 配置中的策略组类型决定了健康检查结果如何参与选择。手动 select 组只提供候选项，不会因为另一个节点延迟更低就自动切换。url-test 组会根据指定地址定期测试，并倾向选择延迟较低的可用节点。fallback 组更关注候选节点是否可用，通常按照配置顺序选择首个通过检查的节点，而不是单纯追逐最低毫秒数。

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - NODE-A
      - NODE-B
      - NODE-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: BACKUP
    type: fallback
    proxies:
      - NODE-A
      - NODE-B
    url: https://www.gstatic.com/generate_204
    interval: 300

interval 控制周期检查间隔。间隔过短会增加节点和测试目标的请求量，也容易让策略频繁受短时波动影响；间隔过长则可能无法及时识别线路变化。日常网络可从数分钟级别开始，再根据节点稳定性调整。

tolerance 用于减少 url-test 在延迟相近节点之间频繁切换。不同核心版本对细节的实现可能存在差异，但配置目的相同：当候选节点差距不大时，保留当前选择，避免每次微小抖动都触发出口变化。长连接、登录会话和下载任务通常更需要这种稳定性。

lazy 启用后，核心可在策略组未被实际使用时减少主动检查。它适合降低空闲测试开销，但也意味着长时间未使用的组在重新启用时可能需要等待新一轮结果。客户端界面中的立即测试按钮通常会主动发起检查，不应与后台周期检查混为一谈。

建立可复现的节点测试方法

可靠比较需要控制变量。测试过程中同时更换节点、DNS 模式、TUN 设置和测试 URL，最终很难判断差异来自哪里。更合适的方法是固定环境，分阶段记录。

1. 固定本地连接。在同一设备、同一 Wi-Fi 或有线网络下测试，暂停大流量上传、下载与系统更新。
2. 确认订阅已更新。检查节点名称、协议参数和策略组引用，避免测试已经失效或被订阅删除的条目。
3. 固定测试目标。先用客户端默认地址完成一轮，再用与实际业务区域相关的稳定地址做对照。
4. 重复而非连点。每个节点测试多次，并在测试之间保留合理间隔，记录中位数、波动范围和超时次数。
5. 检查实际规则。访问目标网站后查看连接列表，确认域名、规则、策略组和最终节点符合预期。
6. 加入真实任务。分别观察网页首开、视频缓冲、大文件下载或远程连接，避免用一种测试代替全部场景。
7. 分时段复测。在常用时段和晚间高峰各记录一轮，判断节点是否存在周期性拥塞。

记录结果时，无需追求实验室级精度。一个简单表格就足够：节点名称、测试时间、三至五次延迟、超时次数、目标网站首开感受和持续下载速度。持续几天后，通常可以区分稳定节点、只在空闲时段表现良好的节点，以及对特定目标路径更合适的节点。

为什么优先看中位数

平均值容易被单次极高结果拉升，最低值又过于乐观。将五次结果排序后取中间值，可以降低偶发尖峰的影响。例如 62、64、66、70、420 毫秒的中位数是 66 毫秒，它更接近多数请求的状态；但 420 毫秒仍应作为抖动风险保留，不能直接删除。

如果多个节点的中位数只差十几毫秒，应优先比较稳定性、超时次数和实际目标表现。对普通网页而言，这种差距经常小于 DNS、页面脚本执行和服务器响应造成的波动。

延迟异常与全部超时的排查顺序

当界面显示超时、失败或异常高延迟时，先区分是单节点问题、全部节点问题，还是只有某个测试地址异常。范围判断比立即修改配置更重要。

只有一个节点异常

• 检查订阅是否刚更新，节点协议、端口、传输路径和服务器名称是否完整。
• 查看核心日志中的握手失败、连接拒绝、超时或证书相关信息。
• 确认该节点没有被策略组名称重复、同名覆盖或提供者过滤规则排除。
• 切换到同订阅的其他节点，判断是单入口故障还是整个服务端区域异常。

所有节点同时异常

• 先确认设备能够正常联网，并检查系统时间是否准确。
• 暂停占用上行带宽的任务，排除本地缓冲膨胀。
• 检查测试 URL 能否通过直连访问，是否发生重定向、限流或区域阻断。
• 确认 DNS 上游可用，尤其关注 TUN 模式下的 DNS 接管和防火墙权限。
• 重启核心后再测试，避免仅刷新界面而核心状态未恢复。

测速正常但目标网站异常

此时应从目标连接入手。查看它命中的规则和出口，检查目标域名是否解析到异常地址，必要时对比系统代理与 TUN 模式。若网页只有图片或接口缓慢，还要检查这些资源使用的独立域名。测速地址正常只能说明该探测路径可用，不能证明所有目标路径都正常。

按使用场景选择节点

节点选择没有统一的最低数字标准。浏览资讯和处理文档时，稳定性与规则命中正确通常比几十毫秒差距更重要；实时语音、云游戏和远程桌面更关注低抖动与低丢包；视频和大型下载则需要持续吞吐与较少重传。

网页浏览

关注首轮连接、DNS 稳定性和目标站点路径。可在延迟接近的候选中选择超时更少的节点。

实时交互

关注连续延迟、抖动和丢包。稳定的次低延迟通常优于偶尔取得最低值的线路。

视频与下载

关注持续带宽、晚间拥塞与连接中断。轻量健康检查只能作为可达性参考。

多策略分流

分别验证业务对应的策略组与规则，不要用一个自动选择组的结果代表全部出口。

日常配置可以保留一个手动策略组和一个自动测试策略组。自动组负责在可用节点中提供基础选择，手动组用于固定重要会话或处理目标路径差异。若自动组频繁切换，可适当增加容差或延长检查间隔；若节点故障后恢复过慢，再缩短间隔进行平衡。

最终应把延迟数字理解为诊断信号，而不是质量结论。先确认测试对象和测试路径，再观察连续结果，最后用真实业务验证。这样既能利用 Clash 与 mihomo 的健康检查能力，也能避免因单次最低值频繁切换节点，造成长连接中断、登录状态变化或体验反复。