Clash 策略群組完整解析：url-test、fallback、load-balance 怎麼選

在 Clash 設定中，策略群組位於規則與實際代理節點之間。規則負責判斷連線屬於哪一類流量，策略群組再決定最後交由哪個節點處理。若只把策略群組視為「節點資料夾」，很容易做出錯誤判斷：不同群組類型有各自的選擇條件、健康檢查方式與故障處理順序，名稱相近不代表運作方式相同。

url-test、fallback 與 load-balance 都能引用多個代理，但分別處理三種不同需求。前者會找出探測結果較佳的節點，中者依預設優先順序保留備援線路，後者則把不同連線分配給多個可用節點。選擇前應先釐清目標是降低日常延遲、維持出口優先順序，還是分散並行連線，而不是只看用戶端介面顯示的延遲數字。

策略群組在規則分流中的位置

一筆請求進入 Clash 或 Mihomo 後，通常會先經過 DNS 與入站處理，再依設定中的規則由上而下比對。規則目標可以是特定節點，也可以是策略群組。實務上通常會把規則指向群組名稱，例如讓開發服務進入「自動選擇」、工作系統進入「主備線路」，大量獨立下載工作則進入「連線分散」。

策略群組只會處理由規則送入該群組的連線。即使建立了多個測速群組，只要規則最後指向 DIRECT，該連線仍會直接連線；如果最後命中 MATCH 並進入另一個群組，也不會呼叫前面的測速群組。因此，排查「節點明明可用，流量卻沒有經過它」時，必須同時查看規則命中紀錄與策略群組目前的選擇，不能只盯著節點清單。

自動群組與手動 select 群組的關係

select 是常見的手動選擇群組，可將自動群組設為其中一個選項。如此既能維持日常自動選擇，也能在目標網站限制特定出口時，暫時切換到固定節點。自動群組本身也可供其他群組引用，但巢狀層級太多會提高排查難度。設定時最好讓群組名稱直接表達用途，例如「網頁自動」「工作主備」「下載分散」，避免只寫「群組一」「群組二」。

url-test：依探測結果自動選擇

url-test 會讓核心使用指定 URL 探測群組內的候選代理，並依結果選出表現較佳的節點。適合網頁瀏覽、程式碼託管、軟體更新等希望自動避開高延遲線路的日常流量。這裡的「較佳」主要取決於探測請求的回應時間與可用性，並非對頻寬、封包遺失或尖峰時段穩定性進行完整評估。

探測 URL 應保持穩定、回應內容小，且能回傳明確的成功狀態。許多設定會使用回傳空內容的 HTTP 端點，以減少測試流量。若測試網址在某些網路環境中遭到重新導向、流量限制或特別最佳化，測得的排序就可能偏離實際使用狀況。更換測試網址時，應確認所有候選線路都能在相同條件下存取該端點。

proxy-groups:
  - name: 網頁自動
    type: url-test
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

interval 代表週期性探測間隔，單位通常為秒。間隔太短會增加請求量，也容易讓選擇結果隨輕微的網路波動而改變；間隔太長則可能在節點故障後較晚更新狀態。一般終端裝置通常每隔數分鐘檢查一次，會比十幾秒一次更穩定，實際數值仍須配合節點數量與裝置效能調整。

tolerance 用來設定切換容差。當目前節點與候選節點的差距未超過容差時，維持現狀可減少頻繁切換。假設目前結果為 125 毫秒，另一個節點為 90 毫秒，若容差設為 50 毫秒，兩者差距不足以觸發切換；只有差距持續擴大並超過門檻，自動群組才更有理由更新選擇。不同核心版本與用戶端顯示的選項可能略有差異，請以實際使用的 Mihomo 或 Clash 核心文件為準。

啟用 lazy 後，健康檢查通常會傾向在群組實際被使用時才執行，以減少閒置群組的週期性探測。適合設定中有許多地區群組、平常卻只使用少數群組的情況。若某個群組負責必須快速偵測故障的重要連線，就需要在延後發現故障與背景探測負擔之間取捨。

fallback：依順序保留主備線路

fallback 的核心不是「選最快」，而是「選擇清單中第一個可用項目」。排列越前面的節點優先順序越高，只要健康檢查仍判定它可用，就會繼續使用；只有目前的優先項目失效，才會往後尋找可用節點。這種方式適合出口身分、地區或線路穩定性比幾毫秒延遲更重要的情境。

例如，工作服務需要長期使用固定地區的出口，可將主節點放在第一位、同地區備援節點放在第二位，跨地區緊急節點則排在最後。即使備援節點的探測延遲較低，也不會越過仍可用的主節點。這樣可減少出口變動，但也表示主節點處於「可以連線但使用體驗較差」的狀態時，群組可能不會自動切換。

proxy-groups:
  - name: 工作主備
    type: fallback
    proxies:
      - 主線路
      - 同區備援
      - 異地緊急備援
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

「可用」取決於健康檢查，而健康檢查只能觀察指定端點。若某個節點可存取探測 URL，卻無法開啟特定服務網域，fallback 仍可能繼續使用它。遇到這種情況，應先確認目標網域是否命中正確規則，再檢查 DNS 解析、目標網站限制，以及線路是否支援特定協定。只縮短探測間隔，無法解決實際服務端點與探測端點不一致的問題。

主線路恢復後，群組可能重新切回清單中較前面的節點。若線路在可用與不可用之間反覆變動，就會產生來回切換。可從三方面改善：選擇更穩定的探測端點、適度延長檢查間隔，以及重新評估不穩定節點是否適合擔任最高優先項目。若需求是持續使用目前可用的出口，直到手動切換為止，手動 select 群組通常比自動備援更合適。

錯誤備援的常見原因

• 清單順序與實際主備需求相反，低優先順序的線路反而排在最前面。
• 某條線路無法存取健康檢查網址，但實際服務網址可以開啟，導致節點過早被判定為不可用。
• 訂閱更新後節點名稱改變，造成靜態群組引用失效或指向其他節點。
• 規則並未進入該 fallback 群組，觀察到的出口其實來自其他群組或最終備用規則。
• 用戶端介面快取了舊狀態，核心的實際選擇與頁面顯示未同步更新，需要查看連線紀錄確認。

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

load-balance 處理的是多條獨立連線。核心會依負載平衡策略，為不同連線選擇群組內的可用節點。它不會把多個節點的頻寬合併成一條更寬的通道，也不會任意將單一 TCP 連線的封包拆分到不同出口。若單一檔案下載只有一條連線，通常仍由一個節點處理；進行多連線下載、發出多個並行請求，或多台裝置同時存取時，才比較容易觀察到分配效果。

Mihomo 常見的負載平衡策略包括 consistent-hashing 與 round-robin。一致性雜湊傾向讓相同目標持續使用同一節點，有助於減少同一網站在短時間內頻繁更換出口。輪詢則依連線順序選擇可用節點，分散方式較直接，但同一服務的不同連線可能經由不同出口。

proxy-groups:
  - name: 下載分散
    type: load-balance
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

對登入狀態敏感或會驗證出口 IP 位址的服務，一致性雜湊通常比輪詢穩定。部分網站會將登入工作階段、風險控管狀態或地區內容與出口 IP 位址綁定；若頁面資源與 API 請求分別使用不同節點，可能出現重複驗證、地區跳動或工作階段失效。即使採用一致性雜湊，不同網域的資源仍可能被分配到不同節點，因此金融服務、企業登入及需要固定出口的應用，較適合使用固定節點或 fallback。

輪詢適合大量彼此獨立、可接受出口變動的連線，例如多個軟體套件下載工作、分散的公開資源請求，或區域網路中多台裝置產生的大量非敏感連線。能否提升整體傳輸量，仍取決於本地網路頻寬、遠端伺服器限制、節點上游容量與並行連線模式。若瓶頸在家用網路或目標伺服器，增加節點數量也無法突破限制。

訂閱節點如何搭配健康檢查

節點來自訂閱時，常見方式是透過 proxy-providers 管理遠端提供者，再讓多個策略群組以 use 引用同一個提供者。如此在訂閱更新後，新節點可直接加入對應的動態群組，不必在每個群組中逐一複製名稱。提供者的更新週期與健康檢查週期是兩回事：前者決定何時擷取節點清單，後者決定何時檢測現有節點的狀態。

proxy-providers:
  provider-main:
    type: http
    url: https://example.com/clash-provider.yaml
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: 訂閱自動
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

提供者健康檢查與策略群組探測可能會同時存在。設定大量節點時，應留意重複探測造成的網路請求與裝置負載，行動裝置、效能較低的路由器，以及節點眾多的訂閱尤其明顯。可統一檢查週期、啟用按需檢查，或只讓實際參與選擇的群組執行必要測試。減少探測不等於關閉所有檢查，而是讓檢查頻率符合故障偵測需求。

訂閱更新也可能改變節點名稱、排序或標籤。使用 filter 篩選地區時，應確認正規表示式沒有誤選測試節點，也沒有漏掉名稱格式變更後的節點。若 fallback 透過提供者動態引用節點，提供者回傳的順序也可能影響優先順序；對於必須固定順序的主備線路，明確列出節點通常更容易控制，但節點更名後也必須更新設定。

依使用需求選擇策略群組

日常瀏覽與一般應用程式

可優先考慮 url-test，設定適中的探測週期與容差，並保留手動選擇入口。它能在功能相近的多個節點中自動完成日常選擇。若節點地區差異明顯，可先依地區建立自動群組，再透過上層 select 選擇地區，避免自動測試將出口切換到不符合使用需求的區域。

固定地區、工作系統與遠端連線

可優先考慮 fallback，將最符合出口需求的線路排在前面，同地區的備援線路依序排在後方。若服務嚴格綁定出口 IP 位址，直接使用固定節點或手動群組可能更合適。自動備援可提升故障時的連線持續性，但出口變動本身也可能觸發目標服務的安全驗證。

並行下載與多裝置共用

可考慮 load-balance，並依服務對出口一致性的要求，選擇一致性雜湊或輪詢。不要把登入、付款、企業身分驗證等敏感連線放入輪詢群組。較穩妥的做法是透過規則，將下載網域、更新服務或特定裝置流量導入負載平衡群組，其他流量則繼續使用穩定出口。

TUN 模式下的策略選擇

TUN 模式擴大了核心可以接管的流量範圍，但不會改變這三類策略群組的基本判斷邏輯。進入 TUN 的連線仍需先比對規則，再進入對應的策略群組。啟用 TUN 後若存取結果發生變化，應分別檢查系統路由、DNS 劫持或重新導向設定、規則命中情況與策略群組選項，不要把所有異常都歸因於自動測速。

頻繁切換與錯誤備援的排查順序

1. 確認規則命中情況。在用戶端連線紀錄中找到目標網域，檢查它實際進入哪個策略群組。若規則目標有誤，調整健康檢查也不會改變流量去向。
2. 確認群組類型符合需求。需要主備順序卻使用 url-test，或需要固定出口卻使用輪詢，都會得到看似異常、實際上符合設定邏輯的結果。
3. 檢查探測端點。確認測試 URL 在所有節點上都能穩定回傳成功狀態，避免地區限制、重新導向或伺服器端流量限制影響判斷。
4. 檢查間隔與容差。url-test 頻繁切換時，應先增加容差；若故障偵測太慢，再評估檢查週期，而不是直接改成極短間隔。
5. 核對節點順序。fallback 會由前往後選擇可用項目，第一項必須是真正希望優先使用的線路。
6. 檢查訂閱更新結果。確認節點名稱、篩選規則與提供者狀態，避免群組內的實際候選節點與預期不符。
7. 觀察實際連線，不要只看首頁數字。延遲面板顯示的是探測結果，連線紀錄才能指出特定服務最後使用了哪個節點。

選擇策略群組的關鍵，在於分開處理「速度排序」「主備優先順序」與「連線分散」。url-test 適合從功能相近的節點中自動挑選，fallback 適合維持明確的線路優先順序，load-balance 則適合在多條獨立連線之間進行分配。完成設定後，應使用實際服務驗證規則命中、節點選擇與出口穩定性，而不是只憑一次延遲測試下結論。