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

先依需求選擇策略組

想自行選節點，使用 select；想自動挑選延遲較低的節點，使用 url-test；想優先使用固定節點，故障時再切換備援，使用 fallback；想將不同連線分配到多個節點，使用 load-balance。這四種方式解決的問題各不相同，不能只看名稱裡有沒有「自動」。

策略組是節點或其他策略組的集合。規則會先決定流量交給哪個組，再由該組決定實際出口。例如 MATCH,出口選擇 表示：未符合前面規則的連線，交由「出口選擇」處理。它不是測速指令，也不會讓所有規則自動改用這個組。

類型	選擇依據	適用情境	注意事項
`select`	由使用者手動選擇	固定地區、手動排除問題	一般手動選取的節點故障後，不會自動切換
`url-test`	探測結果與延遲差距	日常自動選擇低延遲出口	探測延遲不等於下載頻寬
`fallback`	清單順序與可用狀態	主要線路搭配備援線路	備援節點即使較快，也不一定會被選中
`load-balance`	分配演算法與可用狀態	將不同連線分散到多個出口	不會將單一下載連線的頻寬合併

設定前先確認核心與節點名稱

用戶端負責操作介面，核心負責執行設定。不同用戶端即使介面按鈕相似，內建核心也可能不同。請先在用戶端的「關於」或核心資訊頁面確認使用的是 Clash 相容核心還是 mihomo，再查閱對應版本的設定說明。以下採用常見的 Clash 策略組欄位，其中負載平衡範例明確使用 mihomo 支援的 consistent-hashing 策略。

先備份目前的設定檔，以及用戶端另行儲存的覆寫設定。覆寫是指在訂閱原始設定上追加或修改欄位的機制。
確認現有的 proxies 中有可用節點，並複製完整名稱；空格、大小寫與符號都必須一致。
如果節點來自 proxy-providers，應在策略組中使用 use 引用對應的提供者，而不是把提供者名稱當成節點填入 proxies。
找出用戶端的本機設定或覆寫入口。直接修改下載的訂閱檔，可能會在下次更新時被覆蓋。

select：透過單一入口手動切換策略

select 本身不會比較延遲，而是將候選項目顯示在介面上，由使用者決定要選哪一個。候選項目可以是實際節點，也可以是自動測速組、故障切換組等其他策略組。因此，最實用的架構通常是外層手動選擇、內層自動處理。

proxy-groups:
  - 出口選擇
    type: select
    proxies:
      - 自動測速
      - 故障切換
      - 連線分流
      - 香港主線
      - 日本備援
      - 新加坡備援

這段設定引用的三個子組會在後文定義。實際使用時，請將四個組的清單項目合併到同一個頂層 proxy-groups 下。不要在同一份 YAML 檔中重複新增同名的頂層索引鍵；重複索引鍵可能導致解析錯誤，也可能讓前面的設定被後面的內容覆蓋。

初次載入時通常會使用清單中的第一個項目，但用戶端也可能會還原上次儲存的選擇。調整清單順序後，仍應前往策略組頁面確認目前選取的項目。排除問題時，可暫時指定一個實際節點，先排除子組巢狀設定造成的影響。

url-test：自動測速與 tolerance 的作用

url-test 會透過候選節點連線到指定的測試網址，並依據探測結果選擇出口。比較的是向該測試網址發出請求所需的時間，不代表所有網站的整體表現。某個節點連線至測試網址很快，在影音網站、遊戲伺服器或大型檔案下載上的表現仍可能普通。

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

interval 單位為秒，tolerance 單位為毫秒

interval: 300：將週期探測間隔設為 300 秒，也就是 5 分鐘。這不是每 300 毫秒切換一次節點。
tolerance: 50：為自動選擇設定 50 毫秒的切換容差，避免節點延遲只有些微差距時頻繁切換。
lazy: false：不會因策略組近期未使用而略過週期探測，但會增加閒置時的網路活動；手機上可視需求改為 true。

用一組假設數據理解容差：目前節點延遲為 120 毫秒，另一個節點為 100 毫秒，只快了 20 毫秒；設定 50 毫秒容差時，通常會維持使用目前節點。如果另一個節點降至 60 毫秒，快了 60 毫秒，就可能觸發切換。這只是機制示例，並非實際線路測試或效能保證；實際選擇也會受到探測是否成功、歷史狀態及核心實作方式影響。

容差不是逾時時間。若目前節點探測失敗，不代表「還要等滿 50 毫秒才切換」。手機使用時，可先從 300 秒間隔、50 毫秒容差開始觀察。將間隔縮短至 5 秒，會大幅增加探測次數，卻無法保證服務連線更穩定。

fallback：依優先順序故障切換

fallback 會依清單順序尋找可用節點。它的目標是維持首選線路，而非永遠挑選速度最快的節點。以下設定會先嘗試「香港主線」，只有在判定該節點不可用時，才會考慮「日本備援」，接著才是「新加坡備援」。

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

假設主線探測延遲為 180 毫秒，備援節點只有 80 毫秒，只要主線仍被判定為可用，通常就會繼續使用主線。主線恢復並在後續探測中被識別後，策略組會再次優先選用主線。因此，對固定出口地區或對帳號登入環境較敏感的情境而言，故障切換通常比一味追求最低延遲更容易管理。

另外，「測試網址可連線」只表示該次探測成功。若節點能連線至測試網址，卻無法存取目標服務，策略組仍可能將它視為可用。此時應檢查目標服務的地區限制、DNS 解析及規則命中狀況，而不是只縮短探測間隔。

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

load-balance 會依演算法將不同連線分配至候選節點。以下採用 consistent-hashing，也就是一致性雜湊策略：依據目標資訊，讓同一類目標盡可能使用穩定的出口。在 mihomo 中，通常會根據目標網域的可註冊主網域等資訊進行映射，實際細節請以使用中的核心版本為準。

  - 連線分流
    type: load-balance
    proxies:
      - 香港主線
      - 日本備援
      - 新加坡備援
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

另一個常見選項是 round-robin，也就是輪詢分配。它會依序為新連線選擇出口，不會讓已建立的連線每傳輸一段資料就切換節點。對需要維持穩定登入狀態的網站而言，若多個連線從不同地區的出口發出，可能會觸發額外驗證，因此不適合不加區分地套用至所有流量。

若單一檔案只建立一條 TCP 下載連線，不會因策略組中有三個節點就自動獲得三倍速度。
多筆獨立下載或連往不同目標的連線，可能會分配到不同節點，但分配結果不保證資料量平均。
若多個節點最終共用同一條受限的上游線路，分流連線也無法突破該線路的瓶頸。
UDP 能否正常使用，還取決於實際節點協定、伺服器端能力及流量接管方式，不能只靠策略組類型判斷。

讓規則實際套用這些策略組

定義好策略組後，還需要透過規則將連線導入。以下只列出兩條規則，方便說明它們在既有規則架構中的位置。網域範例 example.com 僅用於示範精確分流，不代表任何實際服務的需求。

rules:
  - DOMAIN-SUFFIX,example.com,故障切換
  - MATCH,出口選擇

規則會由上往下比對，通常命中後就不會繼續查找。特定網域規則必須放在最後的 MATCH 之前；若既有設定已包含規則集、區域網路直連及地區分流，請保留原有內容，只調整確實需要變更的策略目標。不要為了測試一個策略組，就把整份規則縮減成上述兩行。

同時確認用戶端目前使用規則模式。全域模式會套用全域策略，直連模式則不會依照上述規則選擇代理出口。在 Android 上透過 VpnService 接管流量，或在桌面啟用 TUN，都不會改變這四種策略組的基本選路邏輯；TUN 是流量接管方式，不是第五種測速演算法。

載入、驗證與常見問題排除

先檢查語法。 YAML 使用空格縮排，不可使用定位字元。四個策略組都應位於同一個 proxy-groups 清單下，且組名不可重複。
重新載入設定。在用戶端的設定頁面啟用修改後的設定，確認是否出現找不到節點、組別引用無效或欄位不受支援等錯誤。
手動測試一次。在策略組頁面啟動延遲測試，確認三個節點都有結果。留意介面顯示的是策略組的測試結果，還是訂閱提供者的另一套健康檢查結果。
確認規則是否命中。開啟連線記錄，檢查目標網域、命中的規則及最終節點。只看到已選取「出口選擇」，還不能確認實際使用的是哪個子組成員。
進行可還原的故障測試。在測試設定中暫時移除主線，重新載入後建立新連線，觀察備援是否正常運作。完成後請還原原始設定，不要修改線上伺服器來模擬故障。

更新設定後，策略組又還原了

優先確認訂閱更新是否覆蓋本機修改。請將自訂策略放在用戶端支援的覆寫或合併機制中，並確認合併方式是追加、取代還是透過指令碼處理。不同用戶端處理同名策略組的方式各異，不能只憑「儲存成功」就判定最終設定正確；應檢查實際生效的設定。

延遲正常，網頁仍然無法開啟

先用 select 固定選取一個已知可用的節點，再查看連線記錄。如果目標網域被錯誤分配為直連，調整策略組的測速參數也無濟於事。如果測試網址正常，但目標服務無法使用，請檢查 DNS、服務地區限制及協定支援。切換 Wi-Fi 與行動網路後也應重新測試，舊結果不代表新網路的狀況。

多個策略組同時測速，手機耗電增加

如果三個自動策略組各有三個節點，且每隔 300 秒探測一次，各組分別執行時，每輪可能會進行九次探測；提供者本身的健康檢查也可能另外執行。這只是簡化的請求次數估算，核心可能會進行排程或重用，不能直接據此推算耗電量。手機上通常只需保留一種主要自動策略；閒置組可考慮設定 lazy: true，並避免同時將提供者健康檢查設得太頻繁。

日常使用可以從簡單設定開始：外層 select 保留手動控制，內層只放一個 url-test 或 fallback。需要將服務連線分配至多個節點時，再另外新增負載平衡組。先確認規則與節點都能正常使用，再調整探測參數，比一次疊加多層策略更容易找出問題。