延遲測試是怎麼測的？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 分鐘