Clash 延迟测试原理:URL Test 数值为何不等于真实上网体验

URL Test 测的是小请求耗时，不是下载速度

先给结论：Clash 客户端里的延迟数字，通常表示内核经指定代理访问测试 URL 所得到的请求耗时。它不是单纯的 ICMP Ping，也不是节点带宽，更不能直接换算成视频清晰度。判断节点是否适合当前任务，需要同时观察延迟波动、持续传输、目标网站可用性和实际命中的规则。

客户端负责发起测试、展示结果；内核负责建立代理连接并访问目标。界面中的“延迟测试”“连接测试”可能调用不同接口，是否采用统一延迟、是否取第二次请求的结果，也取决于内核与客户端设置。比较两个结果前，应先确认测试地址和测试方式一致。

URL Test：关注一次小型 HTTP 请求是否成功，以及完成测试所需的时间，通常以毫秒显示。
下载测试：关注一段时间内传输了多少数据，通常以 MB/s 或 Mbps 显示，会实际消耗流量。
真实使用：还包含 DNS、连接复用、页面资源并发、服务端处理和应用自身的等待时间。

一次延迟测试经过哪些环节

可以把测试路径简化为“本机 → 代理入口 → 代理出口 → 测试站点”。实际部署可能包含中转和多级代理，入口与出口也不一定位于同一地区。一次请求会受到这些环节的共同影响，但具体哪些步骤计入显示值，要看内核实现、缓存状态及是否复用连接。

解析连接所需的域名。代理服务器域名需要解析；测试目标的解析位置则与代理协议、DNS 配置和内核行为有关，不能一概认为全部由本地完成。
建立到代理的连接。根据协议，可能涉及 TCP、TLS 或基于 UDP 的传输握手。首次连接通常比复用已有连接更慢。
由代理访问测试目标。代理出口到测试站点还要经过路由、拥塞队列和目标站点的处理。
接收 HTTP 响应。若使用 HTTPS，还涉及到测试站点的 TLS 会话。响应状态、重定向及超时处理也会影响测试结果。

为什么第二次测试可能明显更快

DNS 缓存、连接复用和 TLS 会话恢复都可能缩短后续请求耗时。mihomo 的 unified-delay 选项用于减少不同代理协议握手开销对延迟比较的影响；启用后的数字不宜与另一套测试口径直接混排。排查时应保持这个开关不变，不要把切换设置前后的差值当成线路改善。

批量测试还会同时产生多条连接。在性能有限的路由器、移动网络或节点并发受限时，测量行为本身可能引入竞争。连续点击几次“全部测试”，不一定能得到更可靠的排序。

测试 URL 如何改变节点排序

测试地址不是无关紧要的参数。不同域名可能接入不同 CDN，同一个域名也可能因代理出口和解析结果而连接到不同机房。某节点到测试站点路径短，不代表它到视频平台、代码托管服务或工作站点的路径同样短。

选择地址的三个条件

响应体小：优先使用稳定的小响应端点，例如返回 HTTP 204 的连通性检查地址，减少正文传输的干扰。
访问条件稳定：避免需要登录、验证码、地区授权或频繁跳转的页面。
测试口径一致：比较同一组节点时使用相同 URL、超时和网络环境，不把不同站点的结果混在一起。

https://www.gstatic.com/generate_204 是常见示例，HTTPS 默认使用 443 端口。它适合作为小请求探测目标，但不是全部互联网服务的代表。若本地网络或某个出口无法正常访问该地址，测试失败也不能直接推导为节点完全不可用。

测试现象	可以初步判断	还需验证
小请求延迟低	当前探测路径响应较快	持续吞吐与目标业务表现
一个 URL 全部超时	探测目标或公共路径可能异常	换一个可靠目标后是否仍失败
只有一个节点超时	该节点的当前路径值得排查	入口连通性、协议配置与出口状态
数字频繁大幅变化	链路或测量条件不稳定	本地 Wi-Fi、并发连接与高峰拥塞

更换测试地址后，建议重新测试整组节点，并记录切换时间。不要只重测某一个节点，再拿新结果与其他节点的旧缓存值比较。

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

小请求快，持续传输未必快

一个很小的响应可能在拥塞明显之前就已返回。下载大文件或播放高码率视频则需要持续传输，容易暴露带宽限制、丢包重传、晚高峰拥堵和连接被重置等问题。延迟是响应时间维度，吞吐是传输能力维度，两者相关，但不是同一个指标。

以单位换算为例：20 Mbps 的理论传输速率约为 2.5 MB/s，实际应用还要扣除协议开销。这只是换算示例，不是节点实测数据。一个 60 ms 的节点完全可能比 150 ms 的节点下载更慢。

业务流量可能根本没走被测节点

单节点测试通常是明确指定该代理进行探测，并不证明浏览器请求会经由相同的规则和策略组。应用可能命中 DIRECT，也可能进入另一个策略组。手动选择了某个节点，还需要检查目标域名最终匹配的规则和完整代理链。

在客户端的“连接”或“连接日志”页面找到目标域名，检查规则、策略组和出站代理。
确认当前使用规则模式，而不是误切到直连模式；全局模式则应检查 GLOBAL 的选择。
若应用不遵循系统代理，检查是否需要 TUN 接管，以及该应用是否被路由排除。

HTTP 探测不能覆盖 UDP 与服务权限

常见 HTTPS 探测主要验证相应的 HTTP 请求路径。游戏、语音和部分 QUIC 流量使用 UDP，节点协议支持、服务端设置及本地路由都可能不同。测试成功不代表 UDP 一定可用；TUN 开启也不代表所有域名解析和 UDP 转发问题都会自动解决。

此外，目标服务可能限制出口 IP、账号地区或请求频率。页面返回地区限制、403 或验证码时，应检查业务响应，而不是只根据延迟数字反复切换。

url-test 策略组：interval 与 tolerance 怎么设

url-test 是自动比较探测结果的策略组，不是下载测速工具。下面示例用于支持这些字段的 mihomo 内核。节点-A 与 节点-B 必须是现有 proxies 中定义的名称，使用前改成实际名称；不要把这段局部配置直接覆盖整份订阅。

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

  - name: 出站选择
    type: select
    proxies:
      - 自动延迟
      - 节点-A
      - 节点-B

rules:
  - MATCH,出站选择

这里的 MATCH 仅展示流量如何进入策略组。已有配置应保留原来的局域网、直连和业务分流规则，再把兜底或指定业务指向相应组。若配置已经存在 proxy-groups 或 rules，应合并条目，不要添加重复的顶层键。完整字段结构可查阅YAML 手册。

字段	示例值	含义与取舍
`interval`	300 秒	周期测试间隔；不是单次请求的超时，也不是到点强制切换节点。
`tolerance`	50 毫秒	切换容差，用于避免因小幅延迟差异频繁更换当前节点。
`lazy`	`true`	未使用该组时可跳过周期测试，降低探测开销。
`url`	HTTPS 小响应地址	决定探测目标；改变它就改变了比较依据。

先用 300 秒与 50 毫秒，再根据波动调整

对普通浏览场景，可以把 interval: 300、tolerance: 50 作为起点，而不是通用最优值。如果节点很多，或设备使用移动数据，可考虑将间隔延长到 600 秒；若网络切换频繁，需要更及时的结果，可在确认负载后尝试 120 秒。组未使用、设备休眠等情况会影响实际探测时机。

容差是稳定性取舍。假设当前节点为 120 ms，另一个为 100 ms，仅快 20 ms；设置 50 ms 容差，通常会倾向于保留当前可用节点。若另一个为 60 ms，改善达到 60 ms，才更可能触发切换。以上为参数解释示例，具体还受可用状态、历史探测结果及内核实现影响。

若订阅更新会覆盖手动修改，应使用客户端支持的覆写或合并机制。不同客户端的入口名称并不统一，保存后要检查内核实际加载的运行配置，而不只是编辑器里显示的文本。

用一套可重复步骤判断真实体验

排查“Clash 测速很快但网页很慢”，应把探测与业务测试分开记录。一次只改变一个条件，才能判断改善来自节点、规则还是本地网络。

固定测试条件。保持同一 Wi-Fi 或有线网络、相同测试 URL 和同一延迟设置，暂停占满上行或下行的任务。
记录连续结果。选 2～3 个候选节点，每个测试 5 次，间隔约 10 秒。记录中间水平、最大值和失败次数，不只保留最好的一次。
手动固定候选节点。在 select 组中选定一个节点，避免业务验证期间自动组更换出站。
重开业务连接。重新打开目标页面或重新发起传输，在连接页面确认域名、命中规则和代理链一致。
检查持续表现。用同一个合法可访问的文件或相同视频片段观察 60～120 秒，分别记录加载等待、缓冲次数和稳定速率。
回看本地因素。若所有节点都波动，先比较有线与 Wi-Fi、检查后台上传和 DNS，再考虑逐个修改代理参数。

记录表可以只包含“时间、节点、测试 URL、5 次延迟、失败次数、目标服务表现”七项。若只有高峰时段出现问题，应在相近时间复测；凌晨与晚高峰的单次数字没有直接可比性。

最终选择应服从任务：网页交互看响应与稳定性，文件传输看持续吞吐，游戏和语音看对应 UDP 路径及抖动。url-test 适合按统一的小请求指标自动筛选，不负责替代业务验证。保留一个手动选择入口，通常比不断压低测试间隔更便于定位问题。