Clash 策略組 url-test、fallback、load-balance 差異與設定教學

先選定切換方式，再設定 proxy-groups

想自動選擇回應較快的節點，使用 url-test；想固定主要線路，僅在故障時切換至備援線路，使用 fallback；想將不同連線分配給多個節點，使用 load-balance。三者都能搭配健康檢查，但「自動」不代表會依相同標準選擇節點。

用戶端負責匯入訂閱、顯示策略組與啟用設定，實際執行選擇邏輯的是核心。Clash 與 Clash Meta（現稱 mihomo）的基本欄位相近，但擴充欄位與支援的策略可能不同。本文範例以 mihomo 為目標；儲存前請先在用戶端的核心資訊或啟動記錄中確認正在執行的核心，再透過設定檢查驗證欄位。

類型	選擇依據	常見用途	主要限制
`url-test`	測試 URL 的回應時間，並依容差決定是否切換	日常瀏覽、自動選擇低延遲線路	測試延遲不等於下載頻寬
`fallback`	依清單順序選擇第一個健康的候選節點	主備線路、維持常用出口地區	故障偵測時間受檢查週期影響
`load-balance`	依分配演算法選擇健康的候選節點	將多個連線分配到不同節點	不會合併單一連線的頻寬

url-test：依延遲選擇，以 tolerance 降低頻繁切換

url-test 會透過候選節點連線至同一個測試網址，並依健康檢查結果選擇回應較快的節點。這個數值包含透過代理連線至測試服務所需的時間，並非對代理伺服器執行 ICMP ping，也不是下載測速檔案的速度。

基本設定與參數單位

proxy-groups:
  - name: 自動低延遲
    type: url-test
    proxies:
      - 香港日常使用
      - 日本備援
      - 新加坡備援
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

url：健康檢查目標，範例網址通常會回傳 HTTP 204。建議選擇檔案小、穩定，且能透過候選節點連線的 HTTPS 網址。
interval: 300：檢查間隔為 300 秒，也就是 5 分鐘，不是 300 毫秒。
tolerance: 50：切換容差為 50 毫秒，可避免因延遲差距極小而頻繁更換出口。
lazy: true：啟用延遲檢查，未使用的策略組可減少定期測試。首次啟用、手動測速與核心排程仍可能觸發檢查。

容差不是固定的延遲上限

假設某次測試中，目前使用的節點延遲為 120 ms，另一個節點為 95 ms，差距只有 25 ms。設定 50 ms 容差後，通常不會只因這點差距而切換。若另一個節點降至 60 ms，差距擴大到 60 ms，就可能符合切換條件。這些是假設數據，用於說明參數，並非本站實測結果；實際選擇也取決於健康狀態與核心實作方式。

不要把 tolerance 理解成「超過 50 ms 就不能用」。它衡量的是切換時的延遲差距，不是替所有節點訂出 50 ms 的合格門檻。若節點頻繁跨地區切換，可先將容差從 20 ms 調高至 50 ms，再觀察結果，不必把檢查間隔縮短到 5 秒。

fallback：依序使用主要線路，故障時才切換至備援

fallback 的重點是順序，不是最低延遲。清單中第一個健康的節點會優先使用；該節點故障後，才會改用後續健康的節點。若主要節點恢復正常，後續選擇通常會再次優先考慮該節點。

proxy-groups:
  - name: 主備切換
    type: fallback
    proxies:
      - 香港日常使用
      - 日本備援
      - 新加坡備援
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: false

在這個範例中，即使「日本備援」的延遲為 70 ms、「香港日常使用」為 150 ms，只要香港節點正常，主備組仍會優先使用香港節點。因此，請將需要固定地區或流量成本較合適的節點排在前面，再將跨地區的備援節點放在後面。

故障切換不代表無中斷轉移

兩次定期檢查之間可能有狀態延遲。間隔 300 秒不代表故障發生後能立即偵測，也不保證恢復所需時間。
策略組切換主要影響之後建立的新連線。既有 TCP 連線無法直接將伺服器端工作階段轉移到另一個出口，因此影片、SSH 或下載工作可能需要重新連線。
此處的 fallback 並非「每次請求失敗，都立即改用其他節點重試相同請求」的應用程式層重試機制。
lazy: false 會讓未使用的策略組也持續定期檢查，使狀態較容易保持更新，但會增加測試請求，也可能喚醒行動裝置。

若服務需要穩定的出口地區，主備候選節點最好位於同一出口地區。測試網址可連線，只代表該檢查請求成功；不保證所有服務網域都能存取，也不保證兩個節點享有相同的內容服務權限。

load-balance：分散不同連線，不會合併單一連線的速度

load-balance 會在健康的候選節點之間分配連線。它不是鏈路聚合，也不會把單一 TCP 下載連線拆成三份，同時經由三個節點傳輸。它的優勢主要在於分散多個獨立連線或多個目標，而非直接將單次下載速度乘以節點數。

proxy-groups:
  - name: 多出口分配
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 香港日常使用
      - 日本備援
      - 新加坡備援
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: true

consistent-hashing 與 round-robin 該怎麼選

策略	運作方式	注意事項
`consistent-hashing`	依目標資訊進行一致性雜湊，讓相同目標傾向使用固定出口	候選節點集合或健康狀態變動時，部分目標可能會重新對應
`round-robin`	以輪詢方式將新連線分配給候選節點	同一服務的不同連線可能使用不同的出口 IP

一般瀏覽可先使用 consistent-hashing。這有助於降低同一目標反覆更換出口的機率，但不等同於帳號層級的工作階段綁定：同一服務可能同時連線至多個網域，候選節點故障時也可能重新分配。登入、付款，以及需要固定來源 IP 的管理後台，建議另外設定規則，指向手動選擇組或穩定的主備組。

輪詢分配的是連線，不是流量位元組數。三個節點各自處理若干連線，但若某條連線持續下載，實際流量仍可能明顯不均。這個基本範例不含權重控制；節點以 0.5 倍、1 倍或 2 倍計費的倍率，也不會被負載平衡自動視為成本權重。

整合範例：保留手動選擇，再將規則指向策略組

以下範例將三種自動策略組加入同一個 select 組。啟用設定後，可在用戶端的代理組面板選擇「代理出口」，再選擇自動低延遲、主備切換、多出口分配，或直接指定節點。排查問題時，可藉此略過自動策略，確認單一節點是否正常。

proxy-groups:
  - name: 代理出口
    type: select
    proxies:
      - 自動低延遲
      - 主備切換
      - 多出口分配
      - 香港日常使用
      - 日本備援
      - 新加坡備援

  - name: 自動低延遲
    type: url-test
    proxies:
      - 香港日常使用
      - 日本備援
      - 新加坡備援
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 主備切換
    type: fallback
    proxies:
      - 香港日常使用
      - 日本備援
      - 新加坡備援
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: false

  - name: 多出口分配
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 香港日常使用
      - 日本備援
      - 新加坡備援
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: true

rules:
  - MATCH,代理出口

最後的 MATCH 只是用來示範規則與組名的關係。實際設定應保留原有的區域網路、直連與服務分流規則，並將兜底規則放在最後。若直接用這一行取代所有規則，原本應直連的流量也會進入代理出口。

使用 proxy-providers 訂閱時，改用 use

若節點來自現有的 proxy-providers，不必在組內逐一手動輸入節點名稱。假設設定中已有名為 線路訂閱 的提供者，可用以下方式引用：

proxy-groups:
  - name: 提供者自動選擇
    type: url-test
    use:
      - 線路訂閱
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

use 引用的是提供者名稱，proxies 引用的是節點或策略組名稱，兩者不可混用。提供者更新間隔決定取得節點清單的時間，健康檢查間隔則決定測試可用性的時間；將檢查間隔改成每 60 秒一次，不會讓訂閱清單也每 60 秒更新。

提供者本身也可能設定 health-check。核心會排程策略組與提供者的檢查，不能簡單將兩者的間隔相加來推算故障切換時間。維護設定時，應明確指定由哪一方負責定期檢查，避免多個提供者與策略組都採用過短週期，造成額外請求。

驗證與排查：先確認實際出口，再調整測試參數

先檢查 YAML 格式與節點引用

先備份目前可用的設定。在持續生效的覆寫機制或合併設定入口中修改策略組，避免直接編輯會被訂閱更新覆寫的暫存檔案。
使用空格縮排，不要使用 Tab。組名必須唯一，規則中的名稱須與組名完全一致，各組之間也不能形成循環引用。
若命令列核心已加入 PATH，請執行 mihomo -t -f ./config.yaml 檢查設定；並依實際檔案位置調整相對路徑。
重新載入設定，手動觸發一次健康檢查，再查看策略組候選節點的狀態。設定檢查通過，不代表節點已能連線。

使用明確指定的代理入口測試新連線

若目前設定的 HTTP 或混合代理連接埠確實是 7890，可使用以下命令進行測試。這裡的連接埠僅為驗證範例，並非所有用戶端都使用此固定值；請先在連接埠設定或設定檔的 mixed-port 中確認。

curl -I --proxy http://127.0.0.1:7890 --max-time 15 https://cp.cloudflare.com/generate_204

明確指定代理後，命令不必依賴終端機是否讀取系統代理設定。若成功收到 HTTP 204，可用來確認這條測試路徑正常；也應在用戶端的連線記錄中確認套用的規則、策略組與實際節點。若要判斷服務是否可用，請對實際服務建立新連線，不能只憑測試網址成功就下結論。

常見狀況與處理順序

所有節點都逾時：先手動選擇一個已知可用的節點。若服務存取正常但測試失敗，請檢查測試網域、DNS 與該網址是否可連線；不要立刻刪除所有節點。
url-test 不斷切換節點：先確認測試網址是否穩定，再增加容差。將 300 秒改為 10 秒通常會放大短期波動，也可能增加耗電量。
fallback 沒選擇最快的節點：這是依順序選擇健康節點的預期行為。若要比較延遲，應改用 url-test，而不是調整備援清單來模擬測速排序。
load-balance 的流量分配不平均：確認是否只有少數長連線，或多個請求都集中在相同目標。一致性雜湊與連線輪詢都不保證每個節點傳輸相同的位元組數。
策略組已切換，頁面仍顯示舊出口：先建立新連線。瀏覽器的連線重用、持續下載與長連線可能仍使用原節點；關閉連線會中斷工作，請在可以接受時再操作。
更新訂閱後設定消失：將自訂策略移至用戶端支援的持續生效覆寫機制，再確認合併後的最終設定，而非只檢查編輯器中的片段。