Clash 策略組 url-test、fallback、load-balance 差異與 YAML 設定範例

如何選擇策略組

要自動選擇低延遲出口，請用 url-test；要固定主備順序，請用 fallback；要將不同連線分配到多個出口，請用 load-balance。這三者都是策略組，不是代理協定，也不會建立新節點。組內必須引用已存在的代理節點或相容的策略組。

Clash 是規則代理核心及其用戶端生態的常見統稱，Clash Meta 後續以 mihomo 名稱持續維護。用戶端介面相似，不代表採用相同核心。本文的 YAML 範例以 mihomo 為目標；舊版 Clash 核心對選用欄位及負載平衡演算法的支援可能不同，請以實際核心文件與設定檢查結果為準。

類型	選路依據	適用情境	主要限制
`url-test`	探測結果與切換容許值	日常瀏覽，自動選擇延遲較低的節點	探測延遲不等於下載頻寬
`fallback`	清單中優先順序最高的可用成員	優先使用主線路，故障時改用備援線路	主線路速度較慢但仍可用時，通常不會切換
`load-balance`	可用成員與指定的分配演算法	將多個目標或連線分配到不同出口	不會將單一連線的頻寬相加

url-test：依探測延遲選路

url-test 會讓各成員連線至指定 URL、記錄探測結果，再據此選擇出口。適合節點品質會隨時間變化，又不想頻繁手動切換的情境。測量的是對探測目標發出一次請求所需的時間，並非單純測量本機至節點伺服器的 ICMP 延遲。

interval 與 tolerance 的單位不同

interval: 300：自動健康檢查間隔為 300 秒，也就是 5 分鐘，不是 300 毫秒。
tolerance: 50：切換容許值為 50 毫秒，可減少延遲些微波動造成的頻繁切換，並非探測逾時設定。
url：健康檢查使用的 HTTP 或 HTTPS 網址。應選擇穩定、回應內容少，且所有成員都能存取的網址。
lazy: false：停用惰性檢查，方便在驗證期間持續觀察檢查結果；節點較多時會增加背景探測請求。

假設目前出口的探測延遲為 120 毫秒，另一個成員為 95 毫秒，改善幅度只有 25 毫秒；容許值為 50 毫秒時，不應預期會立即切換。若另一個成員為 60 毫秒，改善幅度達 60 毫秒，便超過此容許值。這個例子僅用來說明參數關係，並非實測結果；實際選擇也會受成員可用性、探測完成時間及核心實作方式影響。

不要把容許值設得很高來「提高穩定性」。例如設為 500 毫秒，就會容忍明顯的延遲差距。可以先使用 interval: 300 和 tolerance: 50 觀察，再依網路波動幅度調整。影片緩衝或下載速度不理想時，也應檢查封包遺失、頻寬及目標網站的連線路徑，而不只是看面板上的最低數字。

fallback：依清單順序切換主備線路

fallback 會選擇清單中順位最前且健康的成員。清單順序就是優先順序：第一個成員可用時優先使用；第一個不可用時，才會考慮第二個。它不以最低延遲為目標，也不需要設定 tolerance 欄位。

將平常優先使用的節點放在 proxies 的第一項。
依優先順序排列備援節點，並盡量避免所有成員都依賴同一條故障線路。
使用一致的探測 URL，先以 300 秒的間隔觀察可用性。
主節點恢復並通過健康檢查後，後續連線可再次優先使用主節點。

假設第一個成員的探測延遲為 180 毫秒，第二個為 80 毫秒，只要第一個仍被判定為可用，fallback 就不會只因第二個速度較快而主動改選低延遲節點。若主線路「可以開啟探測網址，但業務網站很慢」，策略組仍可能繼續使用主線路。

load-balance：依演算法分配連線

load-balance 會將不同連線分配給組內可用的成員。適合有多個並行請求，且允許不同請求使用不同出口的服務。三條線路各自有一定頻寬，不代表單一下載連線就能取得三條線路的總頻寬。

mihomo 常見分配演算法

strategy 值	主要行為	使用注意事項
`consistent-hashing`	依目標位址相關資訊進行一致性雜湊分配	有助於讓相同目標維持較穩定的出口，但成員變動後可能重新對應
`round-robin`	為新連線輪流選擇可用成員	同一網站的不同連線可能使用不同的公用 IP
`sticky-sessions`	依據來源與目標資訊，維持一段時間的黏著式分配	請確認核心支援，不能視為帳號層級固定出口的保證

範例採用 consistent-hashing。目標分組方式會受網域資訊是否可見等條件影響，不能解讀為「一個帳號永遠對應一個節點」。若付款、後台登入或企業驗證等服務會檢查出口 IP，請優先使用固定節點，或另外建立手動選擇組。

round-robin 是在連線分配層級輪替，不會把單一 TCP 連線的封包逐一送往不同節點。瀏覽器可能重複使用 HTTP/2 連線，因此重新載入頁面幾次，也不一定能觀察到公用 IP 嚴格交替。要驗證負載平衡行為，請查看用戶端連線紀錄，並建立多個獨立的新連線。

proxy-groups 設定範例

以下是可合併至 mihomo 設定檔的策略組片段。前提是設定檔的 proxies 中已存在名為「香港01」、「日本01」、「新加坡01」的三個節點。請將這些名稱替換為實際節點名稱，並保留節點原有的伺服器、協定與認證欄位。

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - 自動測速
      - 故障切換
      - 負載平衡出口
      - DIRECT

  - name: 自動測速
    type: url-test
    proxies:
      - 香港01
      - 日本01
      - 新加坡01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

  - name: 故障切換
    type: fallback
    proxies:
      - 香港01
      - 日本01
      - 新加坡01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

  - name: 負載平衡出口
    type: load-balance
    proxies:
      - 香港01
      - 日本01
      - 新加坡01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

這裡的 generate_204 網址僅供健康檢查使用，不是訂閱連結，也不是節點伺服器。該網址通常會回應 HTTP 204；如果目前的網路或出口無法穩定存取，請改用已確認可用的輕量探測網址。不要選擇需要登入、有複雜重新導向或回應內容很大的網頁。

將業務規則連結至策略組

定義策略組後，還需要在規則中引用它。以下是規則語法範例，不建議用來取代整套既有規則。請保留現有的區域網路、直連及業務分流規則，並將最終兜底規則放在最後：

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

example.com 是規則語法中的範例網域，實際使用時應替換為要分流的業務網域。MATCH 會比對前面尚未符合規則的連線，因此不可放在其他細部規則之前。在用戶端選擇規則模式，再從「出口選擇」中選取「自動測速」、「故障切換」或「負載平衡出口」，對應策略組才會處理這部分流量。

訂閱與 provider 的合併重點

透過 proxy-providers 載入節點時，策略組通常會使用 use 引用 provider，而不是將 provider 名稱寫在 proxies 中。兩者屬於不同的命名空間。以下假設現有設定已定義名為「訂閱節點」的 provider：

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

此片段未包含 provider 的下載網址、快取路徑與更新設定，不能單獨作為完整設定使用。如果原訂閱已提供可用的策略組，請先確認現有策略組的行為，不必另外建立一套相同的組。同時將數十個節點放入多個自動策略組，可能會增加探測請求與排查難度。

provider 的 health-check.interval 與策略組的 interval 位於不同的設定位置，不能只修改其中一處，就假設所有檢查間隔都已變更。實際探測的安排與共用方式取決於核心實作。排查時請同時檢查 provider 與策略組設定，並以實際記錄為準。

更新訂閱可能會覆蓋直接修改的設定檔。若要長期保留自訂組，請使用用戶端支援的覆寫、合併或擴充設定機制。不同用戶端的功能入口名稱可能不同，可以先到「訂閱」或「設定」頁面開啟目前設定的操作選單，確認編輯的是可持續使用的覆寫檔，還是下載後的暫存設定。

設定驗證與異常排查

依序驗證，不要只看測速數字

備份目前的設定。保留一份可正常使用的設定副本，並記下目前的核心名稱。以命令列部署時，可執行 mihomo -v 查看版本資訊。
檢查語法與引用。在命令列環境執行 mihomo -t -f ./config.yaml。若設定依賴相對路徑資源，請在實際執行目錄與環境中進行檢查。
重新載入設定。使用用戶端的設定重新載入功能，或依部署方式重新啟動核心。只儲存檔案，不一定會變更目前正在執行的設定。
執行健康檢查。在策略組頁面進行一次測速，確認至少有一個成員可用。首次檢查尚未完成時，不要只根據舊的延遲數值判斷選擇結果。
檢查規則比對結果。在連線紀錄中查看目標網域、符合的規則、策略鏈與最終節點，確認流量確實經過新建的策略組。
建立新連線並重新測試。關閉測試應用程式的舊連線後再試一次。請比較探測狀態、策略選擇與實際連線結果，而不是只重新整理同一個長連線頁面。

常見狀況與可能原因

提示找不到代理：檢查節點名稱是否完全相同，尤其是空格、大小寫及訂閱更新後的名稱變更；使用 provider 時，請檢查 use 引用。
自動測速組沒有切換：檢查目前模式、規則是否符合該組，以及延遲差是否超過 tolerance；不要把另一個未使用、名稱相似的組誤認為目前出口。
所有成員都顯示逾時：先單獨測試一個節點，再檢查探測 URL、DNS 與網路連線狀況。共用的探測目標發生故障，可能導致多條正常線路同時被判定為異常。
fallback 一直使用第一個成員：如果第一個成員仍健康，這是符合順序優先邏輯的結果；若要追求較低延遲，請改用 url-test。
load-balance 導致登入狀態異常：檢查是否使用輪詢，以及服務是否會檢查出口 IP。將該服務單獨分流至固定節點，通常比頻繁更換負載平衡演算法更直接。
更新訂閱後自訂組消失：檢查修改內容是否寫在會被更新覆蓋的檔案中，並將需要保留的修改移至用戶端支援的覆寫機制。

最後依需求精簡設定：日常瀏覽優先測試 url-test，固定主備順序請選 fallback，只有確實需要分攤多條連線時才使用 load-balance。繼續調整規則或 DNS 前，可以先閱讀設定檔參考；安裝與匯入步驟請參閱用戶端設定教學。