Clash 策略組設定教學：url-test、fallback、load-balance 用法與範例

先分清規則、策略組與節點

在 Clash 設定中，rules 決定連線要交給哪個策略組，proxy-groups 決定該組從哪些節點或下層策略組選擇出口，proxies 和 proxy-providers 則提供候選節點。排查「規則已命中，出口卻不對」時，應先查看規則指向的策略組，再確認組內目前選取的成員，而不只是檢查節點清單。

策略組的 type 決定選擇方式：select 由使用者手動指定；url-test 依探測延遲自動選擇；fallback 按清單順序選用可用項目；load-balance 則將連線分配到可用節點。這些策略組都能作為規則的目標，但「自動選擇」不會修改訂閱中的節點，也不會改變規則的比對順序。

select：出口由使用者手動選擇

select 通常放在規則與其他策略組之間。例如，規則指向「手動選擇」，組內同時列出「自動優選」、「故障切換」、個別節點和 DIRECT。如此一來，不必修改規則，就能在用戶端的「代理」頁面切換出口。DIRECT 代表直接連線；將它列入策略組，方便比較代理與直連的結果。

select 不會依延遲自動更換成員。若清單中同時有自動策略組和個別節點，選取「自動優選」後，才會由下層的 url-test 決定實際使用的節點。訂閱更新或組名變更後，用戶端顯示的目前選項也可能需要重新確認；更新設定後，先檢查組內成員是否仍存在，再確認實際出口。

url-test：依探測延遲選擇，不是依測速頻寬

url-test 使用 url 指定探測網址，並以 interval 設定探測間隔，單位為秒。例如 interval: 300 代表每 300 秒進行一次定期探測；用戶端顯示的延遲來自探測請求，不代表下載速度，也不能單獨反映影片串流的傳輸效能。探測網址應能穩定回應，範例使用常見的 https://www.gstatic.com/generate_204。若目前的網路或節點無法連線，請改用確認可正常存取的輕量網址，否則延遲欄可能一直顯示失敗。

tolerance: 50 表示設定 50 毫秒的選擇容差，避免延遲相近的節點頻繁切換；它不是連線逾時，也不代表「超過 50 毫秒就判定故障」。如果某項服務需要固定出口 IP，例如登入狀態會受出口變動影響，請優先在 select 中指定特定節點，不要只依最低探測延遲決定出口。

fallback：清單順序就是優先順序

fallback 同樣會透過 url 和 interval 檢查成員是否可用，但不會選擇延遲最低的節點。假設候選順序為「香港 01」、「香港 02」、「日本 01」，只要「香港 01」仍判定為可用，即使「香港 02」的探測延遲更低，策略組仍會優先使用「香港 01」。只有第一個成員無法使用時，才會依序嘗試後續成員。

因此，fallback 適合需要主要與備援節點的連線：將預計長期使用的節點放在前面，備援節點排在後面。安排順序時別只看節點名稱，也要確認節點確實支援所需服務。探測失敗後是否切換，取決於健康檢查結果；它不會對每個網頁請求即時重試。也不能假設已建立的連線會自動轉移至新節點。

load-balance：分配連線，不會合併單一連線的頻寬

load-balance 會將連線分配至多個可用節點。mihomo 設定中的 strategy: consistent-hashing 採用一致性雜湊策略，讓相同目標傾向使用相同節點；strategy: round-robin 則以輪詢方式分配。這裡分配的是不同連線，不會將單一檔案拆成多條線路合併傳輸，因此不能把多個節點標示的頻寬相加，當成單一連線的速度。

選擇策略前先考量使用情境：若希望連線至同一網站時盡量維持相同出口，可先試試 consistent-hashing；若要讓多個彼此獨立的請求輪流使用節點，可測試 round-robin。登入、付款或依賴固定來源位址的服務，可能會因出口輪替而觸發額外驗證。這時改用特定節點或 fallback，會比一再縮短探測間隔更直接。

可直接修改的 proxy-groups 設定範例

以下範例假設目前設定的 proxies 或代理提供者中，已有名為「香港 01」、「香港 02」及「日本 01」的節點。貼上前，請將這三個名稱逐字改成設定中的實際節點名稱，空格也必須一致。範例中的 proxy-groups 和 rules 是頂層欄位，不要縮排到個別節點之下。若檔案中已有同名頂層欄位，請合併內容，不要再新增一份。

proxy-groups:
  - name: 自動優選
    type: url-test
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

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

  - name: 負載平衡
    type: load-balance
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

  - name: 手動選擇
    type: select
    proxies:
      - 自動優選
      - 故障切換
      - 負載平衡
      - 香港 01
      - DIRECT

rules:
  - MATCH,手動選擇

MATCH 是兜底規則，請放在既有規則的最後。如果直接用範例中的 rules 覆蓋原始檔案，原有的分流規則就不會繼續生效。若要保留現有分流，請只將各條規則的目標策略組名稱改為「手動選擇」，並保留原有順序。若要讓「負載平衡」以輪詢方式運作，確認核心支援後，再將它的 strategy 改為 round-robin。

使用代理提供者時的設定方式

如果節點是由 proxy-providers 提供，而非直接列在設定的 proxies 中，策略組可使用 use 引用既有的提供者名稱。例如，提供者的頂層鍵名為 main-provider 時，可在對應策略組中設定 use: [main-provider]。請先確認提供者已成功載入，再檢查組內是否出現節點；單純設定 use 不會建立訂閱，也不會代填訂閱網址。若還要加入手動設定的節點，可依所用核心支援的語法，在同一個策略組中分別設定 use 和 proxies。

匯入後的檢查順序

1. 先檢查語法和名稱。YAML 使用空格縮排，type、proxies、url 和 interval 應屬於同一個策略組。若出現找不到節點的提示，請逐字核對成員名稱；若提示欄位重複，請檢查是否貼上了第二個頂層 proxy-groups 或 rules。
2. 接著檢查健康狀態。在用戶端的「代理」頁面開啟「自動優選」或「故障切換」，執行延遲測試，確認三個節點是否都有回傳結果。若全部失敗，請先檢查探測網址是否可連線，以及節點本身是否正常，不要立刻將 interval: 300 改成更短的間隔。
3. 最後確認流量路徑。在「代理」頁面選取「手動選擇」及其下層策略組，確認用戶端已啟用流量接管方式，再前往目標網站。如果使用規則模式，請查看連線記錄，確認命中了哪條規則；若目前是全域或直連模式，就不能只憑 rules 中的 MATCH 判斷實際出口。

需要穩定指定出口時，使用 select；優先考量探測延遲時，使用 url-test；主要與備援順序明確時，使用 fallback；需要將不同連線分配至多個節點時，再使用 load-balance。四種策略組可並存於同一份設定中，重點是讓規則指向正確的策略組，並在更新訂閱後重新檢查節點名稱、探測結果和目前選取項目。