Clash 策略組 url-test 與 fallback：自動測速與故障轉移怎麼配

1. 訂閱匯入後，為什麼還要懂策略組

在 Clash／mihomo（Clash Meta）類核心裡，proxies 列出你可用的節點；proxy-groups 則決定「當規則把流量交給某個策略組名稱時，實際要連哪一條線」。若你只使用訂閱預設產生的 select 類型，等於把選擇權交給手動點選；而 url-test 與 fallback 則把「選線邏輯」寫進設定檔，讓核心依延遲測試結果或健康檢查自動決策。

這與「AI 分流」「TUN 模式」等主題不同：後者多半處理哪些流量要進代理；而本篇聚焦在代理流量進來之後，要在多個節點之間如何挑選或切換。兩層都對，體驗才會同時「分得對」又「連得快、斷得少」。若你尚未完成訂閱匯入，可先依本站 訂閱匯入教學 建立可更新的節點清單，再回到本篇調整策略組。

2. url-test 與 fallback：一句話與適用情境

先用直覺對照：url-test 偏向「在清單裡找目前延遲最低（在容忍範圍內）的那一個」；fallback 偏向「由上而下找第一個通過健康檢查的節點，不通就換下一個」。因此：

• 你希望日常自動選最快、節點品質隨時間波動——優先評估 url-test。
• 你希望明確主備關係：主節點掛了再換備援，而不是永遠跟著延遲跑——優先評估 fallback。

兩者都會用到 HTTP 請求做探測（由 url 指定），但決策規則不同：url-test 會在測試結果之間做「最佳化選擇」；fallback 則維持你在 proxies 陣列中排列的優先順序。實務上也有人把「常用落地組」做成 url-test，把「專線／高價節點＋平價備援」做成 fallback，視你的訂閱結構而定。

3. url-test：延遲測試、參數與「自動切換節點」

url-test 會依 interval 週期對清單內節點發起探測，取得延遲後挑選合適節點。常見參數如下（實際可用欄位以你所用的核心版本為準；mihomo 與多數圖形用戶端會與下列一致或向下相容）：

• url：探測目標，例如常見的輕量 HTTP 204／狀態檢查網址。重點是可被多數節點穩定存取，且回應足夠輕量。
• interval：測試間隔（秒）。間隔太短會增加後台請求與節點負擔；太長則切換節點的反應變慢。
• tolerance：容忍值（毫秒）。當「目前使用中節點」與「測到更低延遲節點」差距在容忍範圍內時，可維持不頻繁跳動，避免體感上一直換線。
• lazy：若為 true，常見行為是「策略組未被實際選中使用前不主動大量測試」，有助降低閒置時的探測量（實作細節依核心版本而定）。

若你發現「明明延遲很低卻常常換節點」，第一件事通常是調整 tolerance 或檢查探測 URL 是否對所有節點都公平（例如被部分出口阻擋）。若你發現「切換太慢」，則檢查 interval 與網路環境，而不是一味把間隔拉到極端。

4. fallback：固定順序與故障轉移

fallback 的核心精神是你寫好的順序就是主備關係：由上而下，找到第一個通過檢查的節點就使用；當目前節點在後續檢查中失敗，才會往下一個移動。它不一定會選「延遲最低」的那條，而是選「符合順序且可用」的那一條。這很適合專線／高穩節點＋平價備援、或固定出口 IP 需求（只要你把最符合 IP 需求的節點放在最前面並確保健康檢查能反映真實可用性）。

同樣會用到 url、interval 等探測欄位；部分環境可設定 expected-status 之類欄位協助判定 HTTP 回應是否算成功（依核心與訂閱產生器是否帶出為準）。若你把探測網址設得太嚴苛，可能出現「節點其實能上網，但探測失敗而誤判故障」的情況，這點在 url-test 與 fallback 都一樣需要留意。

5. 可複製的 proxy-groups 範例

下列片段示範命名與結構；請把 proxies 清單中的名稱換成你訂閱裡實際存在的節點名稱，或改成引用 proxy-providers 產生的策略組／節點。若你使用圖形介面編輯，重點也是對應到相同的類型與欄位。

proxy-groups:
  # Auto: pick lowest latency among listed nodes
  - name: "AUTO-BEST"
    type: url-test
    proxies:
      - "節點-A"
      - "節點-B"
      - "節點-C"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

  # Failover: try primary first, then backups
  - name: "PROXY-PRIMARY-FALLBACK"
    type: fallback
    proxies:
      - "主用-專線"
      - "備援-1"
      - "備援-2"
    url: "http://www.gstatic.com/generate_204"
    interval: 300

若你的訂閱已內建類似 ♻️ 自動選擇、🔯 故障轉移 等策略組，亦可直接在圖形介面對照：它們多半就是 url-test 與 fallback 的視覺化包裝。你要做的是確認最後規則指向的策略組名稱是否與你預期一致，而不是只在主畫面手選了節點、卻讓規則仍指向另一個群組。

6. 與規則鏈、MATCH 的銜接

策略組再漂亮，若規則沒有把流量導過去，仍不會生效。典型寫法是在 rules 尾端保留 MATCH，把「其餘全部」交給你的預設策略組（例如名為 PROXY 或自訂的 AUTO-BEST）。更細緻的做法則依域名、進程名、IP CIDR 分段把不同服務導到不同策略組；這與本站 規則分流指南 的思維一致：先決定「誰走哪個組」，再在該組內由 url-test／fallback 決定實際節點。

實務上常見錯誤是：使用者以為自己用了自動測速組，但規則其實把流量送到一個純 select 的舊群組；或訂閱更新後節點改名，導致策略組引用名稱失效而被核心忽略。遇到「設定看起來對、行為卻不對」時，建議從日誌與目前生效設定確認策略組是否被命中，而不是只重啟一次就假設成功。

7. 常見誤區與排查

第一，把 fallback 當成「自動選最快」。若你的主節點延遲較高但仍通過探測，fallback 可能長期停留在主節點，這是預期行為；要「跟著延遲跑」請用 url-test。第二，探測網址與實際上網目標不一致：探測顯示正常，不代表特定網站或 UDP 服務也通，這屬於規則與協定層面的另一道題。第三，頻繁跳節點：優先調整 tolerance 與 interval，並避免在訂閱中塞入過多極慢或極不穩的候選，否則任何演算法都難以「體感穩定」。

若你從舊版 Clash for Windows 遷移到新用戶端，策略組名稱與訂閱結構可能一起改變；可搭配 遷移指南 檢查「訂閱 → 節點 → 策略組 → 規則」是否仍然閉環。這比單純複製一段 YAML 更能避免遷移後看似能連、其實命中錯誤群組的隱性問題。