Clash 策略組類型怎麼選：url-test、fallback、load-balance 的差異與設定思路

Clash 設定中的策略組決定一條連線最後交給哪個節點。規則只負責將流量送入某個組，組內的 type 才決定節點如何選擇。手動組 select 由使用者指定節點；自動組則依據健康檢查、排列順序或分配演算法進行選擇。

url-test、fallback 與 load-balance 都會利用健康檢查，但目標完全不同。前者追求較低的探測延遲，第二種強調固定優先順序與故障接替，第三種則將新連線分散到多個可用節點。選錯類型時，常見結果不是設定報錯，而是頻繁切換、存取出口變動，或備援節點未按預期接手。

三種自動策略組的核心差異

判斷類型時，可以先回答一個問題：這個組更需要「選擇回應較快的節點」、「依業務優先順序進行備援」，還是「讓多個節點共同承接新連線」。三種需求分別對應 url-test、fallback 和 load-balance。

健康檢查不是持續佔用業務連線進行測速

自動組會依照 interval 指定的秒數存取測試 URL，記錄成員是否可用及回應時間。以 interval: 300 為例，通常週期為 300 秒，也就是 5 分鐘。週期過短會增加節點與本地網路的探測請求；週期過長則會延後發現線路恢復或故障。

測試 URL 通常選擇回傳內容很小、回應穩定的網址，例如 https://www.gstatic.com/generate_204。如果該網址本身受到目標網路限制，所有節點可能同時顯示失敗。此時應更換為能穩定回應的輕量網址，而不是立即判定所有節點都已失效。

url-test：依探測延遲自動擇優

url-test 會定期測試組內成員，並選擇探測延遲較低的可用節點。它適合網頁瀏覽、即時通訊、程式碼代管等對回應時間較敏感的日常流量。選擇發生在策略組層級，並不代表每個請求都會重新測速。

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

tolerance：減少幾毫秒差距造成的切換

tolerance 的單位是毫秒。上例設定為 50，表示新結果只有在差距達到容差範圍時才值得切換，具體選擇細節由所使用的核心實作決定。它的實際價值是避免兩個延遲接近的節點反覆成為優選項。

例如節點 A 實測 82 ms，節點 B 實測 106 ms，兩者相差 24 ms。在 50 ms 容差下，沒有必要只因一次探測波動就切換。若節點 A 升至 178 ms，而節點 B 維持 103 ms，差距擴大至 75 ms，此時重新選擇才更有意義。家庭 Wi-Fi 延遲波動明顯時，可先從 50 至 100 ms 開始；穩定的有線網路則可使用 20 至 50 ms。

lazy：有流量時再維持檢查

lazy: true 適合不常使用的策略組。組長時間沒有連線時，核心可以減少不必要的週期測試；再次產生符合規則的流量後恢復檢查。需要快速掌握備援線路狀態的關鍵業務組，則應結合所使用的 mihomo 版本與客戶端行為評估是否啟用。

url-test 適用與不適用的情況

• 適合多個用途相近、方案與線路品質接近的節點。
• 適合希望自動避開高延遲節點，又不要求固定出口位址的情境。
• 不適合必須長期維持同一地區或同一出口位址的登入工作階段。
• 不適合僅憑一次 204 測試判斷影片頻寬；延遲測試不能取代持續吞吐量測試。

fallback：按順序使用第一個可用節點

fallback 的重點不是誰的延遲最低，而是誰排在前面且目前可用。清單中的第一個成員是主要線路；主要線路健康檢查失敗後，組才會嘗試後面的備援成員。主要線路恢復並通過檢查後，通常會重新回到較前面的成員。

proxy-groups:
  - name: 工作線路
    type: fallback
    proxies:
      - 企業專線
      - 香港備援
      - 日本備援
    url: https://www.gstatic.com/generate_204
    interval: 180
    lazy: false

這段設定表達了明確的業務順序：先使用「企業專線」，無法使用時切換至「香港備援」，兩者都無法使用時再使用「日本備援」。即使日本節點實測只有 45 ms，而企業專線為 92 ms，只要企業專線維持可用，它仍然位於優先位置。

「可用」只代表測試 URL 能完成請求

節點能夠存取 204 測試網址，不代表它一定能存取規則對應的業務網域。某條線路可能通過健康檢查，卻無法正常存取特定服務。遇到這種情況，可以為業務組選擇更接近實際目標的測試網址，但不宜使用需要登入、會多次重新導向或回傳大型檔案的頁面。

故障切換也不會將已建立的 TCP 連線無縫搬移到另一個節點。主要線路中斷時，原有下載、SSH 或 WebSocket 連線通常會中斷；應用程式重新連線後，新連線才會經過備援成員。對長連線業務而言，也應同時檢查應用程式本身的重試機制。

fallback 的典型情境

1. 固定主要線路：主要節點具備穩定出口或特定地區，其他節點只負責故障接替。
2. 成本優先：優先使用流量充足的線路，昂貴或有流量限制的線路排在後面。
3. 地區順序：先使用香港地區，全部無法使用時再切換至日本或新加坡地區。
4. 遠端連線：遠端開發、管理面板等業務更重視出口連續性，而不是幾十毫秒的延遲差。

load-balance：將新連線分配給多個節點

load-balance 會在多個可用成員之間分配連線。它不是頻寬疊加器：單一 TCP 下載通常仍會透過一個節點，不能將三條 100 Mbps 線路自動合併成一條 300 Mbps 連線。它更適合大量獨立請求、多網域存取或多個並行工作。

proxy-groups:
  - name: 並行分流
    type: load-balance
    proxies:
      - 香港-01
      - 香港-02
      - 香港-03
    url: https://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

consistent-hashing：讓相近目標維持相對穩定

consistent-hashing 會根據連線目標計算分配結果，使相同或相近的目標傾向於落在同一成員。與完全輪替相比，它更適合網站登入、API 呼叫及需要一定出口連續性的情境。節點清單變更時，部分目標仍可能重新映射，因此它不能取代真正的固定出口。

round-robin：依新連線輪流分配

mihomo 支援的 round-robin 策略會讓新連線依序使用可用成員。假設組內有 A、B、C 三個節點，連續建立的連線可能依 A、B、C、A 的順序分配。一個網頁往往會同時連線至多個網域，因此同一次頁面載入可能出現多個出口位址。

輪詢適合並行抓取、分散連線數等不依賴單一出口的工作。帳號登入、付款、網路銀行或對 IP 變更敏感的 API 不宜使用這類組。若服務端將短時間內出現多個出口視為異常，應改用 select、fallback，或使用具備穩定映射特徵的策略。

組合策略組：先在區域內擇優，再進行區域備援

複雜設定不必在一個組內解決所有目標。策略組可以引用其他策略組，因此更清楚的寫法是先依區域建立 url-test，再由上層 fallback 決定地區優先順序。如此既能在同一區域選擇低延遲節點，也能在整個區域無法使用時切換。

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

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

  - name: 預設出口
    type: fallback
    proxies:
      - 香港自動
      - 日本自動
    url: https://www.gstatic.com/generate_204
    interval: 180

rules:
  - DOMAIN-SUFFIX,example.net,預設出口
  - MATCH,預設出口

在這套結構中，「香港自動」先從兩個香港節點中選擇合適成員；上層「預設出口」優先使用香港組，香港組無法完成檢查時才使用日本組。組名必須完全一致，包括大小寫、空格與符號。YAML 縮排建議統一使用兩個空格，不要混用 Tab。

手動組與自動組並存

實際設定通常還會保留一個 select 組，方便臨時指定節點。可以將「自動優選」、「工作線路」、「並行分流」和具體節點一起放入手動組，再讓規則指向該手動組。日常選擇自動策略，需要固定出口時則切換至具體節點。

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - 自動優選
      - 工作線路
      - 並行分流
      - 香港-01

這種結構比讓所有規則直接指向底層自動組更容易維護。客戶端介面中只需操作「節點選擇」，底層組繼續負責測試與故障判斷。修改設定後，應在客戶端執行「設定」→「重新載入」，並查看記錄是否出現策略組名稱不存在、YAML 解析失敗或節點引用錯誤。

與規則模式、系統代理和 TUN 模式的關係

策略組負責選擇出口，規則負責決定進入哪個組。在規則模式下，連線會由上至下比對 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等規則，命中後進入指定策略組。全域模式則通常將流量統一交由全域策略選擇，不再依普通規則逐條決定去向。

系統代理與 TUN 模式決定哪些流量能夠進入核心，不會改變 url-test、fallback 或 load-balance 的基本選擇邏輯。瀏覽器透過系統代理進入 Clash，或遊戲流量透過 TUN 進入 mihomo，只要最後命中同一個策略組，就會依該組類型選擇節點。

TUN 模式下需要額外留意 UDP

遊戲、語音和部分 HTTP/3 流量會使用 UDP。節點協定、服務端與客戶端核心都需要支援相應的 UDP 轉發。節點通過 TCP 測試 URL，不代表 UDP 一定可用。出現網頁正常但語音或遊戲失敗時，應在連線面板確認網路類型，並檢查節點的 UDP 能力、TUN 設定與防火牆規則。

DNS 結果會影響規則與連線目標

啟用 Fake-IP 時，DNS 模組會回傳映射位址，核心再依據映射關係還原網域並比對規則。啟用 Redir-Host 時，網域解析結果會更直接地參與連線。策略組本身不負責修復 DNS；如果網域解析逾時，三種自動組都可能沒有機會建立正常的業務連線。

參數怎麼調：從穩定設定開始

自動策略組參數沒有適用於所有網路的固定答案。家用寬頻、行動熱點、跨境專線與雲端伺服器的波動幅度各不相同。更可靠的方法是先採用保守值，記錄切換與失敗情況，再針對問題調整。

1. 先確認測試 URL 能透過每個節點穩定存取，連續檢查至少 3 次。
2. 記錄節點延遲，而不是只看一次結果。82 ms、91 ms、87 ms 屬於接近；82 ms 與 260 ms 才是明顯差距。
3. 觀察客戶端連線面板中的實際策略鏈，確認規則命中的組與預期一致。
4. 調整後重新載入設定，並建立新連線進行測試。舊連線可能仍在使用調整前的出口。
5. 出現整組失敗時，先檢查本地網路與測試網址，再檢查訂閱節點，不要同時變更多個參數。

常見誤區與排除順序

誤區一：url-test 會將每個請求都送至延遲最低的節點

它會依據最近的健康檢查結果維持目前選擇，不會在每個 HTTP 請求前重新進行完整測速。節點延遲若在兩個檢測週期之間發生變化，目前結果可能暫時落後，這是週期檢測的正常特性。

誤區二：fallback 會選擇備援清單中最快的節點

fallback 首先遵循排列順序。只要第一個成員可用，就不會因為第二個成員延遲較低而主動切換。需要依延遲選擇時，應改用 url-test，或在 fallback 內引用一個 url-test 子組。

誤區三：load-balance 能提升單一檔案的下載速度

單一連線通常會繫結一個節點。只有下載器將檔案拆分成多個獨立連線，且這些連線被分配至不同成員時，才可能看到總吞吐量變化。最終速度仍取決於來源站限速、節點頻寬、線路壅塞與分配策略。

固定排除順序

1. 在客戶端的「設定」頁面確認目前載入的是剛修改的設定檔。
2. 開啟記錄，檢查策略組類型、成員名稱與 YAML 縮排是否正確。
3. 在「代理」或「策略」頁面執行一次延遲測試，記錄失敗成員。
4. 查看「連線」面板，確認目標連線實際命中的規則與策略鏈。
5. 關閉並重新開啟目標應用程式，排除舊 TCP 連線仍在重複使用原出口。
6. 如果系統代理流量正常而 TUN 流量異常，再檢查 TUN、DNS 與防火牆，不要反覆更換策略組類型。

選擇結論：依目標而不是依名稱決定

• 希望自動使用探測延遲較低的節點，選擇 url-test。
• 希望主要線路優先，故障後按順序接替，選擇 fallback。
• 希望將新連線分散至多個節點，且業務允許出口變動，選擇 load-balance。
• 希望兼顧人工控制與自動判斷，可在外層使用 select，將自動組作為成員。
• 需要地區優先順序時，先建立區域內的 url-test，再由上層 fallback 組合。

多數個人設定從「手動選擇＋自動優選」兩層結構開始即可。只有明確存在主備線路時再加入 fallback；只有確實擁有大量獨立連線，並能接受出口分散時再使用 load-balance。類型越多不代表設定越有效，組與規則之間的職責清楚，才更容易驗證與排除問題。