Clash 策略組 url-test、fallback 與 load-balance 的差異與設定方式

三種自動策略組：依延遲、順序或連線分配流量

proxy-groups 定義的是出口選擇邏輯，而非代理伺服器本身。節點通常來自 proxies 或 proxy-providers；規則命中策略組後，才由策略組決定使用哪個出口。若只在設定中加入組名，卻沒有讓規則引用它，實際流量路徑不會改變。

先確認用戶端實際使用的核心與版本。Clash 圖形用戶端是操作介面，Clash 原版核心與後續演進為 mihomo 的 Clash Meta，才負責解析這些欄位。以下完整設定以 mihomo 為目標；舊版核心對擴充欄位和負載平衡演算法的支援可能不同，請以啟動記錄和對應版本文件為準。

url-test：interval 與 tolerance 如何搭配

url-test 會透過候選節點連線至指定的 url，記錄探測結果並據此選擇出口。測得的是連線至該探測網址的耗時，會受到代理路徑和目標回應影響；這不是 ICMP ping，也不是對影片網站或檔案伺服器進行完整效能測試。

先釐清三個參數的單位

• url：健康檢查網址。通常選擇回應資料量小、穩定，且候選節點都能連線的 HTTPS 網址，例如回傳 204 的檢測端點。
• interval: 300：定期檢查的間隔，單位為秒，也就是約每 5 分鐘檢查一次；不是 300 毫秒，也不是連線逾時值。
• tolerance: 50：切換容差，單位為毫秒。用來減少延遲些微波動造成的頻繁切換；它不是封包遺失率，也不是可接受的最高延遲。

例如目前節點最近一次探測為 105 ms，另一個節點為 80 ms，差距只有 25 ms。容差設為 50 ms 時，不應預期用戶端會只因這點差距就立即切換。若目前節點升至 155 ms，而另一個仍為 80 ms，差距達 75 ms，切換條件就較明顯。這只是說明容差作用的計算範例，並非本站實測結果；最後選擇仍取決於核心當次的健康狀態與實作方式。

檢查間隔不等於故障恢復保證

將 interval 從 300 改為 60，會提高探測頻率，但無法保證故障後 60 秒內所有服務都恢復。探測本身需要時間，既有連線也可能等待逾時。候選節點越多，定期請求也越多；一般日常使用可先從 300 秒開始，再依記錄調整。

mihomo 的 lazy 會影響未使用策略組的定期檢查行為。排查時可明確設為 false，避免受到「策略組未使用，因此沒有持續探測」的影響。若節點來自 provider，也應另外檢查 provider 的 health-check 設定，不要把 provider 檢查和策略組層級的探測當成同一個計時器。

fallback：依清單優先順序選擇可用出口

fallback 會從候選清單中選擇排序最前面的可用節點。假設清單依序為「節點-A」、「節點-B」，只要 A 的健康檢查結果正常，即使 A 為 180 ms、B 為 60 ms，仍應預期使用 A。若要優先使用較快的節點，應選擇 url-test，而不是調整探測間隔。

1. 將日常使用的主要線路放在 proxies 清單第一項，備援線路依序排列。
2. 使用所有候選節點都能連線的檢查網址，避免將目標網站的存取限制誤判為節點故障。
3. 重新載入設定，在代理頁面確認組內順序，再手動執行一次檢查。
4. 暫時停用主要節點對應的服務，觀察後續新連線是否改走備援；測試完成後恢復服務。

主要節點重新判定為可用後，優先順序邏輯會再次偏向清單前面的節點。這適合「主線優先、備援接手」的情境，但不代表既有 TCP 連線會遷移。網頁短連線通常會重新建立；下載、SSH、影片串流等長連線可能需要由應用程式重新連線。

load-balance：分配連線，不合併頻寬

load-balance 會依演算法將連線分配到可用的候選出口。mihomo 可透過 strategy 指定演算法；以下範例使用 consistent-hashing。對登入、付款、工作階段綁定等服務來說，出口穩定性通常比平均分配更重要，可先使用一致性雜湊，或直接將這些網域指定到固定節點。

實際採用的雜湊輸入、網域處理方式和額外演算法支援會因核心實作而異，不能將「一致性雜湊」理解為永久固定公用 IP。節點上線或離線、重新載入設定或候選清單變動，都可能改變對應結果。若服務高度依賴固定出口，建議另設規則，指向手動選擇的策略組，較容易掌控。

例如瀏覽器同時建立 10 條連線時，輪詢演算法可能將它們分配到不同節點；一條已建立的 TCP 連線仍只會經過一個出口。HTTP/2 或 HTTP/3 也可能重複使用連線，因此重新整理網頁不一定會觸發新的分配。驗證負載平衡時，請查看連線記錄中的策略鏈和實際節點，不要只是不斷重新整理同一個 IP 查詢頁面。

完整 YAML 範例：三種策略組並列，由外層手動選擇

以下是供 mihomo 驗證結構的完整範例：以 select 策略組作為統一入口，可在內部切換低延遲、主備或均衡模式。兩個節點使用文件專用位址 192.0.2.10 和 192.0.2.11，無法連線至實際代理服務。實際使用前，必須將完整節點設定替換為服務提供者提供的協定、位址、連接埠和認證資料。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: 節點-A
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "example-only-change-before-use"
  - name: 節點-B
    type: ss
    server: 192.0.2.11
    port: 8388
    cipher: aes-128-gcm
    password: "example-only-change-before-use"

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - 自動低延遲
      - 主備切換
      - 連線均衡
      - 節點-A
      - 節點-B
      - DIRECT

  - name: 自動低延遲
    type: url-test
    proxies:
      - 節點-A
      - 節點-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

  - name: 主備切換
    type: fallback
    proxies:
      - 節點-A
      - 節點-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

  - name: 連線均衡
    type: load-balance
    proxies:
      - 節點-A
      - 節點-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,出口選擇

規則會由上而下比對；範例中的 example.com 及其子網域會直連，其餘流量則交由「出口選擇」。這是示範用規則，並非完整的分流方案。mixed-port: 7890 提供 HTTP 和 SOCKS 共用入口；是否設定系統代理，仍由用戶端或系統設定決定。

使用訂閱 provider 時如何調整

如果現有設定已定義名為「訂閱節點」的 proxy-providers，可用以下策略組取代相應的靜態候選設定。use 引用 provider 名稱，proxies 則引用節點或策略組名稱，兩者屬於不同的命名空間。此片段依賴既有 provider 定義，無法單獨作為完整設定執行。

proxy-groups:
  - name: 自動低延遲
    type: url-test
    use:
      - 訂閱節點
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

不要直接修改會被遠端訂閱覆蓋的暫存設定。若用戶端提供覆寫、合併或擴充設定功能，請透過該功能儲存自訂策略組；實際操作位置請依用戶端版本確認。修改後更新一次訂閱，檢查策略組和規則是否仍保留，才能確認保存方式正確。

巢狀組合：區域內測速，區域間主備

更精細的配置方式，是先為每個區域建立獨立的 url-test 策略組，再讓外層 fallback 依區域優先順序引用它們。例如「主要區域測速」只包含主要區域節點，「備用區域測速」只包含備用區域節點，外層清單則固定將主要區域排在前面。如此一來，區域內依延遲選路，區域間則保留服務優先順序。

• 外層策略組只能引用已定義的組名；不要將自身加入候選清單，也不要建立 A 引用 B、B 又引用 A 的循環。
• 外層看到的是內層策略組目前選出的路徑，不要假設它會展開所有節點後重新比較。
• 內外層各自有檢查間隔，恢復過程可能需要經過多輪更新；請先測試單層，再增加第二層。
• 對登入敏感的服務可單獨指定固定節點或 select 策略組，不必與大量下載共用負載平衡策略。

若只需要日常瀏覽網頁時自動選路，範例中的「外層 select + 內層 url-test」通常已足夠。巢狀層數越多，越難排查連線記錄；只有確實存在區域、費用或主備優先順序差異時，才需要增加層級。

常見設定錯誤與驗證步驟

四個步驟確認實際生效狀況

1. 先驗證設定：使用用戶端的設定檢查功能；若直接執行 mihomo，可執行 mihomo -t -f config.yaml。驗證通過只代表設定可解析，不代表節點認證資料正確或網路可用。
2. 接著重新載入：在設定頁啟用修改後的設定，查看記錄是否顯示未知欄位、名稱重複或引用不存在。合併至既有設定時，請勿重複建立相同層級的 proxy-groups 或 rules 欄位。
3. 檢查規則鏈：使用 Rule 模式發出新請求，在連線頁確認命中的規則、外層策略組、內層策略組和最終節點。Global 或 Direct 模式可能會略過這次要驗證的規則入口。
4. 最後測試服務：分別確認網頁瀏覽、目標服務登入和實際下載。記錄測試時間、出口節點與探測延遲，再決定是否調整 300 秒間隔或 50 ms 容差。

選擇策略組時，可先回答三個問題：要自動改用較低延遲的出口，選 url-test；要固定主要線路並保留故障備援，選 fallback；要讓多個出口分攤不同的新連線，選 load-balance。先確認需求再調整參數，比一層層疊加所有策略更容易驗證和維護。