延迟数字的含义：一次小请求的完成时间
Clash 节点列表中的毫秒数通常来自经指定代理发出的 HTTP 或 HTTPS 探测，而不是对节点服务器执行 ICMP ping。url-test 策略组利用这类探测判断候选节点的可达性与响应速度，再按内核的选择逻辑、容差等条件决定使用哪个节点。手动点击“测试延迟”和策略组后台检测可能共用相关能力，但测试地址、超时及触发范围未必相同。
延迟衡量的是响应时间，下载速度衡量的是单位时间内传输了多少数据。一个只返回少量内容的探测请求，很适合发现连接失败、明显绕路或响应迟缓，却不足以推算持续下载的吞吐量。因此，80 ms 的节点下载只有 2 MB/s，而 180 ms 的节点达到 15 MB/s，在技术上完全可能。
url-test 请求经过哪些环节
以 HTTPS 测试地址为例，内核通常会通过待测代理出站访问目标 URL，建立必要连接并等待 HTTP 响应。它测量的是特定探测实现中的耗时，而不是某一段网络线路的纯传播时延。
- 准备出站：读取节点参数，必要时解析代理服务器域名；解析是否命中缓存会影响本次工作量。
- 建立代理连接：连接节点入口，并完成相应协议所需的传输、安全或代理握手。不同协议可能使用 TCP、UDP 及不同复用机制。
- 访问测试目标：由代理链路连向测试站点；目标域名的解析位置与所用协议、DNS 配置有关，不能一概认定都由本地解析。
- 获取响应并计时：HTTPS 访问还涉及目标站点的 TLS 交互，然后内核依据实现记录结果并交给客户端显示。
上述步骤是理解链路的模型，并不表示每次测试都从零执行全部步骤，也不代表每种内核都把全部准备时间计入显示值。DNS 缓存、已建立的隧道、会话恢复和连接复用，都可能让后一次探测比第一次更快。比较不同客户端的数字前，应先确认测试 URL 与计时方式是否一致。
为什么系统 ping 低，Clash 延迟却高
在终端执行 ping 到节点入口，只能观察本机到该入口的 ICMP 往返情况；ICMP 还可能被限速或丢弃。Clash 的 URL 探测包含访问测试站点的过程，节点到目标站点的出口路径同样会影响结果。两者测量对象不同，不能通过相减直接得出“协议额外开销”。
延迟、带宽与拥塞：分别看哪些指标
| 指标 | 主要反映 | 不能直接推断 |
|---|---|---|
| URL 延迟，单位 ms | 小请求在当前路径上的响应耗时 | 持续下载带宽、所有网站的速度 |
| 吞吐量，单位 MB/s | 一段时间内的实际数据传输能力 | 交互是否及时、其他时段是否稳定 |
| 多次探测的波动 | 响应耗时是否稳定 | 仅凭少量样本确定丢包位置 |
| 超时或失败次数 | 指定探测条件下的可用性 | 节点对所有目标都不可用 |
例如，节点 A 的五次响应为 70、74、71、520、76 ms，节点 B 为 145、149、146、152、148 ms。这是一组说明用数据，不是本站实测。A 的多数结果更低，但有一次明显尖峰；如果用途是远程终端，B 可能提供更连贯的操作体验。只看最小值会把这种差别隐藏起来。
持续下载还受服务端限速、节点共享带宽、跨网拥塞、传输协议拥塞控制及本机网络影响。100 Mbps 的接入带宽在不计开销时约为 12.5 MB/s，但单条连接不保证跑满。即使一次 204 小响应很快完成，大文件传输也可能在几秒后因队列积压或共享出口争用而降速。
晚高峰为什么会出现“延迟正常、视频卡顿”
小请求传输的数据量很少，链路即使只能提供有限吞吐量，也可能快速完成探测；视频则需要持续取回分片。如果可用带宽低于当前画质所需码率，缓冲会逐渐耗尽。此时应查看播放器缓冲状态、实际分片下载速度以及连接日志，而不是反复点击延迟测试。
测试地址决定了结果的适用范围
常见测试地址会返回 HTTP 204，即没有正文的成功响应。例如 https://www.gstatic.com/generate_204 可用于这类探测。地址应长期可访问、响应体小、行为稳定；避免使用大型下载文件、需要登录的页面，或者频繁触发验证码的接口。
- 协议不同：HTTP 与 HTTPS 的连接过程不同，不能把两个地址的耗时直接混排。HTTPS 还可覆盖目标 TLS 连接是否正常这一环节。
- 目标位置不同：同一个域名可能由 CDN 调度到不同地区。节点出口地改变后，实际访问的服务端也可能改变。
- 站点策略不同：测试站点可能限制某些出口，或临时出现故障。一次失败只能说明这条探测链路没有按预期完成。
- 应用目的不同：公共测试站点可达，不等于视频平台、代码仓库或游戏服务具有相同路径和访问权限。
建议保留一个稳定的基础探测地址，用于日常自动选择；另用实际业务验证结果。若经常访问代码仓库，应比较仓库页面与实际拉取表现；若主要观看视频，应查看目标平台的播放统计。不要把大型文件 URL 填进自动探测，再将它误认为完整带宽测试。
url-test 配置：周期、容差与按需检测
以下是面向支持相关字段的 mihomo 内核的策略组片段，需要合并进已有配置。示例使用内置 DIRECT 作为可解析的成员，目的是展示字段结构；直接使用时只会测试直连，并不会自动获得代理节点。实际配置应把成员替换为当前配置中已经存在的节点名称，或按内核文档使用代理提供者。
proxy-groups:
- name: 自动延迟选择
type: url-test
proxies:
- DIRECT
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: trueinterval: 300表示自动检测间隔为 300 秒，即 5 分钟；它不是请求超时，也不意味着每 300 毫秒测一次。tolerance: 50是毫秒级切换容差，用于减少小幅延迟差异导致的频繁切换，不是强制把节点延迟压到 50 ms 以下。lazy: true允许按使用情况减少未使用策略组的检测；后台没有持续出现新数值，不一定代表检测失效。proxies是已有节点或受支持策略成员的引用列表。只有一个成员时，策略组没有可比较的其他候选。
假设当前成员约为 120 ms，另一个成员约为 105 ms，设置 50 ms 容差的目的就是避免因这类小差异反复换线。实际选择还受成员可用性、检测批次及内核实现影响，不应把容差理解为精确的切换承诺。策略组换了成员，也不等于已有 TCP 连接会无缝迁移；新连接通常才会按新的选择建立。
超时、失败与“0 ms”如何排查
超时表示请求在规定时间内没有按预期完成，不是延迟恰好等于该上限。假设一次测试的超时为 5000 ms，显示超时只说明这次探测未在 5 秒内成功返回；原因可能包括节点连接失败、目标站点不可达、DNS 异常或握手停滞。
客户端手动测速、内核控制接口、策略组自动检测及代理提供者的健康检查，可能有各自的超时设置。不要把某个 API 的 timeout 参数直接粘贴进所有 YAML 层级。应查阅当前内核对应字段，并在日志中确认检测是否真的使用了修改后的参数。
- 先看错误类型：连接拒绝、域名解析失败、TLS 错误和请求超时指向不同环节。记录完整错误及发生时间，比只记“红色”更有效。
- 再做对照测试：同一节点换一个稳定测试地址；同一地址换另一个节点。只改变一个变量，判断故障更接近节点还是目标。
- 检查流量是否走对成员：测试某个节点，不代表浏览器正在使用它。查看“连接”页面中的实际命中规则、策略组和出站成员。
- 核对本地接管：浏览器可能遵循系统代理，终端可能没有设置代理，TUN 则有另一套接管范围。测速成功与所有应用已被接管是两回事。
遇到 0 ms、空白或异常低值时，也不要立即判定为“最快节点”。这些显示可能与尚未测试、缓存结果、取整或客户端展示有关，应结合日志和重新测试确认含义。结果异常时先保存证据，再修改设置，避免同时重置 DNS、换节点和改模式而失去定位线索。
一套可复现的节点比较流程
比较节点时，关键是让测试条件一致。可以用下面的顺序建立记录，无需频繁改动整份配置。
- 固定环境：记录客户端版本、内核版本、测试 URL、超时和网络类型。暂停大文件同步，尽量不要在 Wi-Fi 与移动热点之间切换。
- 记录冷启动：单独保存首次测试结果，因为它更容易受到解析及首次握手影响，不要与后续热态数据混在一起解释。
- 重复取样：每个节点测试 5 至 10 次，间隔约 10 秒，记录中位数、最大值和失败次数。多个节点使用相同节奏，避免大量并发探测干扰本地网络。
- 验证业务：对实际目标执行一次页面访问，再进行约 30 秒的下载或播放观察；下载测试会消耗流量，应控制文件大小与测试次数。
- 复测时段：在日常使用的晚间时段再测一次，区分偶发拥塞与长期表现，而不是只保留空闲时段的最好成绩。
记录可以写成：“节点 A，HTTPS 204 探测，中位数 92 ms，10 次中失败 1 次；目标下载平均 3.2 MB/s。”这些数字仅为记录格式示例。延迟、失败率与业务吞吐量放在一起，才比单独一个绿色毫秒数更有参考价值。
按用途选择，而不是只按最小值排序
- 网页与远程终端：优先关注稳定响应、较少尖峰及较低失败率。
- 视频与大文件：在可达的前提下，重点看持续吞吐量、缓冲与高峰时段表现。
- 游戏与语音：重点看实际 UDP 路径、丢包和抖动。HTTP 探测不能替代游戏服务器或语音链路测试。
url-test 适合从候选成员中筛选响应较快、可用的路径，不是带宽排行榜。保留稳定的探测条件，结合实际业务与连接日志判断，就能解释“毫秒数低却不快”，也能减少没有依据的反复切换。