延迟测试是怎么测的？interval、tolerance、lazy 到底该设多少

节点列表上那个毫秒数是怎么来的？为什么它和 ping 出来的值差一大截？为什么自动选择老是切来切去？

这篇把测速这件事说清楚。

测的不是 ping，是一次完整的 HTTP 请求

Clash 的延迟测试流程：

这和 ping 有本质区别：

所以 Clash 显示 180ms 而 ping 只有 60ms 是完全正常的——多出来的部分是握手开销加上节点到目标站点的那一段。

unified-delay：让不同协议可比

不同协议的握手开销差别很大。Trojan（TLS）比 Shadowsocks（无 TLS）天生多一次往返，Hysteria2 基于 QUIC 又是另一套。

直接比总耗时对某些协议不公平。开启：

unified-delay: true

内核会做两次握手测量，扣掉协议固有的握手成本，只保留可比的部分。

三个关键参数

- name: "♻️ 自动选择"
  type: url-test
  proxies: [...]
  url: "http://www.gstatic.com/generate_204"
  interval: 300
  tolerance: 50
  lazy: true
  timeout: 5000
  max-failed-times: 5

interval：多久测一次

tolerance：最重要也最常被忽略

容差，单位毫秒。含义是：新节点必须比当前节点快这么多，才值得切换。

推荐值：

• 节点延迟普遍在 100ms 以下 → tolerance: 30
• 普遍 100~300ms → tolerance: 50
• 波动很大 → tolerance: 100

lazy：空闲时不测

lazy: true

开启后，如果这个策略组当前没有流量经过，就跳过测速。

好处：省电、省流量、减少无谓的连接。笔记本和手机上尤其明显。

代价：切回这个组时，第一次可能用的是过期数据，需要等一轮测速才准。

日常建议开启。

timeout 与 max-failed-times

timeout: 5000            # 单次测速超时（毫秒）
max-failed-times: 5      # 连续失败多少次判定为不可用

timeout 设太短会误判慢节点为不可用；设太长会让一轮测速拖很久。5000ms 是合理值。

测速 URL 选什么

默认的 http://www.gstatic.com/generate_204 有两个特点：返回 204 空响应（几乎不传数据），且部署在全球 CDN 上。

可选的替代：

延迟低 ≠ 速度快

这是最需要澄清的一点。

url-test 只测延迟。判断一个节点能不能扛住大流量，只能实际下载点东西试试。

如果你的主要需求是看视频、下大文件，不要完全依赖自动选择——手动挑几个节点实测速度，然后用 select 组固定下来。

一个实用组合：分层测速

proxy-groups:
  # 主力组：低容差、频繁测，追求响应速度
  - name: "⚡ 快速响应"
    type: url-test
    include-all: true
    filter: "(?i)香港|HK|日本|JP"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 30
    lazy: true

  # 大流量组：高容差、少切换，避免下载中断
  - name: "📦 大流量"
    type: fallback
    include-all: true
    filter: "(?i)IPLC|专线|高速"
    interval: 600

  # 保险组：只要能用就行
  - name: "🛡 兜底"
    type: fallback
    include-all: true
    interval: 900

为什么大流量用 fallback 而不是 url-test：下载或看视频时最怕中途切节点，连接一断进度就没了。fallback 只在当前节点真的挂掉时才换，稳定性远好于 url-test。

手动测速的正确方法

界面上点闪电图标是对当前组做一轮测速。但要注意：

通过 API 触发测速

写脚本自动化时有用：

# 测试单个节点
curl "http://127.0.0.1:9090/proxies/HK-01/delay?timeout=5000&url=http%3A%2F%2Fwww.gstatic.com%2Fgenerate_204" \
  -H "Authorization: Bearer 你的secret"

# 测试整个策略组
curl "http://127.0.0.1:9090/group/%E2%99%BB%EF%B8%8F%20%E8%87%AA%E5%8A%A8%E9%80%89%E6%8B%A9/delay?timeout=5000&url=..." \
  -H "Authorization: Bearer 你的secret"

策略组名含中文和 emoji 时需要 URL 编码。

小结

• 测的是「经过节点访问目标站点」的完整往返，和 ping 不是一回事
• tolerance 一定要设，50 是个好起点，不设会来回横跳
• interval 用 300，太短会触发服务商风控
• lazy 开着，省电省流量
• 开 unified-delay，让不同协议的节点可比
• 延迟不代表带宽，大流量场景用 fallback 而不是 url-test

相关：策略组类型详解、节点命名与自动分组。

相关文档

配置基础 Clash 配置文件 YAML 结构详解：八个顶层字段各管什么

把一份 Clash / Mihomo 配置从头到尾拆开讲：端口、模式、DNS、proxies、proxy-groups、rules、rule-providers 的作用与写法，附一份可直接使用的最小配置。

2026-08-021769 字约 4 分钟

配置基础 proxy-groups 五种类型详解：select、url-test、fallback、load-balance、relay

每种策略组的实际行为、适用场景和关键参数，附带一套可直接抄的分组结构，以及 Mihomo 特有的 include-all 与 filter 用法。

2026-07-291938 字约 5 分钟

配置基础 用 Merge 扩展订阅配置，改了也不会被更新覆盖

直接编辑订阅文件会在下次更新时前功尽弃。这篇讲 Clash Verge 的扩展配置机制：prepend/append/override 的写法、合并顺序，以及几个实用的扩展片段。

2026-07-091688 字约 4 分钟