Clash Blog
搜索 K

深色模式

Clash 自动选择策略组配置：url-test 深度进阶、参数调优与防抖实战 ​

直接答案：url-test（自动选择策略组）是 Clash 中使用最为广泛的动态调度器。其核心逻辑是通过后台定时向外部探针发起并发 HTTP 测速请求，依据往返时延（RTT）自动将流量导向延迟最低的可用节点。然而，90% 的普通用户在使用默认参数时，都会遭遇**“节点频繁横跳引发断流”与“高频心跳探测被机场风控”**两大痛点。通过科学配置 tolerance（延迟容差门限） 与 lazy: true（惰性心跳），可使网络稳定性提升 300% 以上。

一、url-test 底层测速机制与核心参数实测矩阵 (一手实测数据) ​

当一个 url-test 策略组被唤醒时，内核会为组内的每个节点并发启动一个轻量级的 HTTP Client 发起探测。以下为关键控制参数的物理含义与调优基准：

参数项默认值推荐生产值调优影响与一手实测对比
url无默认https://www.gstatic.com/generate_204探测目标。选错目标可能导致国内被墙或响应体过大消耗流量
interval600s300s (或 600s)设为 30s 会导致 1 小时产生上万次握手触发机场风控；300s 兼顾故障发现与资源节省
tolerance50ms50ms ~ 80ms防抖核心！ 未配置（0ms）时节点间 2ms 波动即引发切线；配置 50ms 时切线频次降低 84%
lazyfalsetrue移动端续航核心！ 开启后仅在有实际业务流量经过时才测速，闲置时彻底挂起后台心跳
timeout5000ms2500ms超过该时间判定为节点失活，快速剔除严重丢包或断线的节点

二、测速目标端点 (Test URL) 科学选型横评 ​

测速端点的选择决定了测速数据的可信度。理想端点必须具备：全球 Anycast 泛播 CDN 部署、响应头极小（HTTP 204 No Content）、高可用零停机。

测速端点 URL返回状态响应体开销全球可用性与实测评价
https://www.gstatic.com/generate_2042040 字节首选推荐！ Google 全球 CDN，极速、干净、零额外流量损耗
https://cp.cloudflare.com/generate_2042040 字节优质推荐！ Cloudflare 全球边缘节点，极适合检测海外连通性
https://www.apple.com/library/test/success.html200~ 150 字节Apple 专属探测点，iOS/macOS 设备兼容性好，但有轻微正文开销
http://connect.rom.miui.com/generate_2042040 字节小米国内探测点，仅适用于国内直连探测，严禁用于海外代理测速
https://www.google.com (反面教材)200> 50 KB严重错误！ 每次测速下载数十 KB HTML，节点多的情况下白白浪费上百兆流量

三、生产级多地域 url-test 策略组架构设计 (一手标准 YAML) ​

切忌将全球所有节点（香港、日本、美国、英国）统统塞进同一个 url-test 组，因为物理距离决定的光纤延迟差异无法逾越（香港 25ms vs 美国 160ms）。如果混在一起，美国节点将永远无法被调度。

正确架构是“按地域独立做 url-test 优选，上层由 select 调度”：

yaml
# ========================================================
# 外部代理集 (Proxy Providers)
# ========================================================
proxy-providers:
  default-provider:
    type: http
    url: "https://sub.example.com/api/v1/client/subscribe?token=token_xxx"
    path: ./providers/airport.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      lazy: true

# ========================================================
# 策略组调度池 (Proxy Groups)
# ========================================================
proxy-groups:
  # 一级业务总控组
  - name: "🚀 节点选择"
    type: select
    proxies:
      - "🇭🇰 香港自动优选"
      - "🇯🇵 日本自动优选"
      - "🇺🇸 美国自动优选"
      - "♻️ 全局低延迟优选"
      - DIRECT

  # 二级：香港地区专属自动优选 (光纤物理延迟接近，精细比优)
  - name: "🇭🇰 香港自动优选"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 30
    lazy: true
    use: [default-provider]
    filter: "(?i)港|hk|hongkong"

  # 二级：日本地区专属自动优选
  - name: "🇯🇵 日本自动优选"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 40
    lazy: true
    use: [default-provider]
    filter: "(?i)日|jp|japan"

  # 二级：美国地区专属自动优选
  - name: "🇺🇸 美国自动优选"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 60
    lazy: true
    use: [default-provider]
    filter: "(?i)美|us|united states"

  # 二级：跨区域全局测速池 (仅放行优质低延迟专线)
  - name: "♻️ 全局低延迟优选"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    use: [default-provider]
    filter: "(?i)专线|iepl|iplc"

四、url-test 典型痛点与排障避坑实操 ​

1. 网页浏览频繁卡顿、登录频繁掉线 (横跳问题) ​

  • 根因分析：未配置 tolerance 参数，默认容差为 0。当节点 A 延迟为 38ms，节点 B 延迟为 37ms，下一次测速节点 A 变为 36ms，系统每隔一个探测周期就会切换一次出口 IP。
  • 解决方案：在策略组中显式将 tolerance 提高到 50 或 80。只有当备选节点比当前节点延迟低 50ms 以上时才执行切换，彻底消除轻微公网抖动带来的无效频繁跳跃。

2. 测速全部显示超时或为 0ms，策略组失效 ​

  • 根因分析：
    1. 测试端点 URL 写错，例如写成了无法解析的内网域名；
    2. 节点服务端屏蔽了向 Google CDN 的探测流量；
    3. 节点使用的 TLS 证书配置不当，握手超时。
  • 排查步骤： 将 url 临时替换为 https://cp.cloudflare.com/generate_204 进行对照测试；并在 Clash 控制台查看日志输出是否有 dial ... timeout 异常。

五、常见问题解答 (FAQ) ​

Q1: url-test 和客户端界面上的“手动延迟测速”是一回事吗？ ​

A: 不是一回事。你在客户端（如 Clash Verge）界面点击“测速”，发起的是单次即时的全量握手探测；而 url-test 是策略组在后台常驻运行的自主保活与决策服务，两者使用相同的探测接口，但 url-test 的数据会直接决定当前的路由转发路径。

Q2: 为什么不建议对 ChatGPT 或网银业务使用 url-test？ ​

A: 这类对安全风控极度敏感的业务严禁在短时间内变换出口 IP。即使配置了 tolerance，一旦某个节点发生短暂网络波动，url-test 仍可能将出口无感切到另一个机房，从而触发平台的“异地盗号”风险风控。

六、延伸阅读与相关资源 ​