Clash 策略組類型詳解：url-test、fallback 與 load-balance 差異

策略組如何參與 Clash 規則分流

Clash 設定中的代理節點負責建立實際連線，規則負責判斷流量所屬類別，而策略組位於兩者之間，決定某類流量最終交由哪個節點處理。規則中的目標通常不是直接填寫節點名稱，而是引用策略組，例如將辦公網域交給「工作服務」、串流媒體網域交給「媒體服務」，再由組內的選擇邏輯處理節點切換。

url-test、fallback 與 load-balance 都屬於自動策略組，但「自動」不代表它們會做出相同選擇。三者分別對應延遲優選、依序故障接管與多節點連線分配。若只看節點清單而忽略組別類型，同一批節點可能呈現完全不同的連線效果。

proxy-groups:
  - name: 工作服務
    type: url-test
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,example.com,工作服務
  - MATCH,工作服務

上述設定中，規則只負責將符合條件的連線送入「工作服務」。真正決定使用節點 A、B 還是 C 的，是 url-test 的測速結果與切換參數。策略組不是額外的網路通道，也不會改變節點本身的協定、加密方式或伺服器線路；它只是整理節點並執行選擇。

健康檢查在自動策略組中的作用

自動組通常需要定期透過每個候選節點存取測試 URL。核心會根據請求是否成功、回應耗時與連續檢查結果維護節點狀態。測試 URL 應穩定、回應內容較小，並盡量貼近實際網路出口。常見的 204 回應網址適合測量基本連通性；若設定主要服務於特定業務，也可以使用自己能長期控管的輕量網址。

interval 代表檢查間隔，通常以秒為單位。間隔過短會增加節點與裝置的額外請求，行動網路下也可能頻繁喚醒連線；間隔過長則會延後發現線路故障。桌面常駐環境可先從約 300 秒開始觀察，網路波動明顯或節點數量較多時，再依實際需求調整。

url-test：依健康檢查延遲選擇節點

url-test 會測試組內節點，並優先選擇目前可用節點中測得延遲較低的節點。它適合成員線路功能相近、使用者更重視回應速度的情境，例如多個相同地區出口、都能存取同一服務的節點，或日常網頁與程式碼儲存庫存取。

這裡的「延遲最低」只針對健康檢查請求，不等同於下載速度最快。小型 HTTP 請求主要反映握手、往返時間與目前線路可達性，無法完整代表大檔案吞吐量、尖峰時段壅塞或目標網站至出口伺服器的頻寬。因此，url-test 更準確的理解是「從測試結果中選擇回應較快的健康節點」，而不是持續進行頻寬競速。

tolerance 如何減少來回切換

網路延遲本身會波動。若節點 A 測得 82 毫秒、節點 B 測得 76 毫秒，僅憑 6 毫秒差距立即切換，通常不會帶來可感知的提升，卻可能讓新連線改用另一個出口。tolerance 用於設定可容忍的延遲差距；當目前節點與候選節點的差距未超過門檻時，便維持現有選擇。

- name: 日常低延遲
  type: url-test
  proxies:
    - 香港-01
    - 香港-02
    - 新加坡-01
  url: https://www.gstatic.com/generate_204
  interval: 300
  tolerance: 100
  lazy: true

在支援這些欄位的 mihomo 設定中，lazy: true 可用來減少策略組長時間未使用時的檢查活動；當組別開始承載流量後，核心會依機制更新狀態。具體觸發行為可能隨核心版本而異，使用前應以目前版本文件與執行記錄為準。

url-test 的適用範圍

適合：候選節點用途一致，地區差異不會改變網站內容或帳號風控結果。
適合：網頁瀏覽、API 請求等更依賴回應延遲的連線。
需要謹慎：必須維持固定出口 IP 的登入、付款、遠端辦公或白名單服務。
不宜只看測速：大檔案下載、影片高畫質傳輸與持續上傳，還取決於頻寬與封包遺失。

如果業務要求在工作階段盡量維持同一個出口，可以提高 tolerance、縮小成員範圍，或在自動組外再加入一個 select 手動選擇組。如此既能保留自動優選入口，也能在特定時段固定使用某個節點。

fallback：依節點順序執行故障接管

fallback 的核心不是比較哪個最快，而是依設定順序使用第一個健康節點。只要排在前面的節點仍通過健康檢查，後面的節點即使延遲更低，通常也不會取代它；前置節點無法使用時，策略組才會依序尋找下一個可用成員。

這種行為適合主備關係明確的環境。例如主要節點擁有固定出口、專用線路或更符合業務地區要求，備用節點只在主線路故障時接管。與 url-test 相比，fallback 的決策更容易預測：節點排列本身就是優先順序清單。

- name: 辦公主備
  type: fallback
  proxies:
    - 辦公主線路
    - 辦公備用線路
    - 臨時緊急線路
  url: https://www.gstatic.com/generate_204
  interval: 180
  lazy: false

上例會優先使用「辦公主線路」。當該節點健康檢查失敗時，才會嘗試「辦公備用線路」，之後才是「臨時緊急線路」。如果主線路後續恢復並重新判定為健康，策略組可能會回到較前面的節點。恢復判定與既有連線是否立即遷移，需要分開看待：策略組選擇影響的是後續連線，已建立的 TCP 或 UDP 工作階段未必能無感轉移。

節點順序比延遲數字更重要

設定 fallback 時，應先依業務優先順序排列節點，再參考測速結果。主線路應是長期希望使用的線路，備用線路則必須具備相同的關鍵存取能力。如果備用節點無法存取主要服務，即使健康檢查 URL 回應正常，也無法完成真正的接管。

對於地區敏感服務，不建議把不同地區節點任意混在同一個 fallback 組中。更穩妥的做法是先建立地區內的主備組，再將地區組交給上層手動選擇。例如「日本主備」只包含日本節點，「新加坡主備」只包含新加坡節點，使用者在最外層決定所需地區。如此發生故障時，出口地區不會因自動接管而意外變更。

適合 fallback 的典型情境

遠端辦公服務要求優先使用已加入存取白名單的固定出口。
主線路品質穩定且成本明確，備用線路僅承擔故障期間的流量。
不同節點之間具有清楚的可靠性排序，而不是單純比較瞬間延遲。
希望自動恢復基本連通性，同時維持容易稽核與說明的選擇邏輯。

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

load-balance 會讓組內多個健康節點共同承載連線。它的目標不是選出一個永久勝者，而是依據負載平衡策略，為不同連線決定出口。適合存在大量彼此獨立的請求、多個節點能力相近，且業務允許使用多個出口的環境。

需要注意的是，Clash 的負載平衡通常以連線或目標作為決策對象，並不是把同一條 TCP 連線拆分到多台代理伺服器。單一大檔案下載若只建立一條連線，速度仍受該連線所選節點限制；只有應用程式產生多條並行連線時，才可能讓多個節點分別承擔其中一部分。

- name: 多節點分配
  type: load-balance
  proxies:
    - 節點-A
    - 節點-B
    - 節點-C
  url: https://www.gstatic.com/generate_204
  interval: 300
  strategy: consistent-hashing

consistent-hashing 與 round-robin

mihomo 支援的具體均衡策略應以所使用的版本為準。常見的 consistent-hashing 會根據目標資訊進行相對穩定的映射，使相同或相關目標更可能持續分配到同一個節點。這有助於減少存取同一網站時出口頻繁變化，適合網頁包含多個資源請求、網站對工作階段來源較敏感的情況。

round-robin 傾向依序輪換可用節點，讓連續的新連線分散到不同成員。它的流量分散方式更直觀，但同一網站的多條連線可能使用不同出口。若網站根據來源 IP 維護登入狀態或執行安全檢查，這種變化可能造成重複驗證、工作階段失效或內容地區不一致。

部分 mihomo 版本還提供其他策略選項，其欄位與行為可能有所調整。遷移設定時，不應因舊檔案能夠解析，就預設所有策略語意完全一致。應查看啟動記錄中的設定警告，並透過連線詳情確認實際命中的節點。

負載平衡不適合所有業務

帳號登入、網路銀行、企業身分驗證等需要穩定出口的服務，應優先使用固定節點、select，或依目標進行穩定映射的方案。
節點出口地區不一致時，搜尋結果、媒體目錄、貨幣單位與頁面區域設定可能隨連線而變化。
節點效能差異很大時，平均分配連線不代表平均分配頻寬，較慢的節點仍會拖慢部分請求。
行動網路頻繁切換、裝置資源有限或節點數量過多時，健康檢查與並行連線會產生額外負擔。

url-test、fallback 與 load-balance 的核心差異

比較項目	url-test	fallback	load-balance
主要目標	選擇測試延遲較低的健康節點	優先使用清單中較前面的健康節點	讓多個健康節點共同承載新連線
節點順序的作用	通常不是主要選擇依據	直接表示主備優先順序	作用取決於均衡策略
切換原因	延遲差距超過容忍範圍或目前節點失效	前置節點失效，或優先順序更高的節點恢復	新連線依策略分配，節點失效後排除
出口穩定性	中等，可透過 tolerance 降低切換	較高，主節點健康時維持優先	取決於雜湊或輪詢方式
常見用途	網頁、API、同地區低延遲選擇	辦公主備、固定地區故障接管	多連線下載、分散並行請求

依需求選擇，而不是依名稱選擇

選擇策略組時，可以先回答三個問題。第一，業務是否要求固定地區或固定出口；第二，節點故障時是否允許自動切換至任意可用節點；第三，是否真的需要多個節點同時承載連線。如果必須維持主要出口，且只在故障時切換，fallback 更直接。如果節點彼此等價且優先考慮回應速度，url-test 更合適。如果請求量大、連線彼此獨立且可以接受來源變化，再考慮 load-balance。

一份設定不必只使用一種自動組。實際方案可以分層組合：底層用 fallback 整理各地區的主備節點，中層用 url-test 在數個等價地區組之間選擇回應較快的入口，頂層用 select 讓使用者手動固定策略。策略組巢狀能呈現更清楚的業務界線，但層級過多也會增加排查難度，應讓組名準確反映用途。

proxy-groups:
  - name: 香港主備
    type: fallback
    proxies:
      - 香港主線路
      - 香港備用線路
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 新加坡主備
    type: fallback
    proxies:
      - 新加坡主線路
      - 新加坡備用線路
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 自動地區
    type: url-test
    proxies:
      - 香港主備
      - 新加坡主備
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 120

  - name: 最終選擇
    type: select
    proxies:
      - 自動地區
      - 香港主備
      - 新加坡主備
      - DIRECT

設定策略組的完整檢查步驟

一、確認核心、用戶端與設定欄位

Clash 原版、Clash Meta 與後續 mihomo 分支在功能範圍與欄位支援上有所差異，圖形化用戶端也可能提供不同的策略組編輯介面。訂閱中出現某個欄位，不代表目前核心一定支援。匯入設定後應查看核心啟動記錄，確認沒有未知欄位、策略類型錯誤或代理名稱引用失敗。

若用戶端允許切換核心，需要確認實際執行的是哪一個核心，而不能只根據用戶端名稱判斷。有些用戶端還會在訂閱更新時重新產生設定，手動修改的策略組可能因此被覆寫。長期使用的自訂規則與策略，適合透過用戶端支援的覆寫、擴充設定或設定合併功能維護。

二、檢查代理名稱與縮排

YAML 對縮排很敏感，策略組中的 proxies 成員名稱必須與代理節點或其他策略組名稱完全一致。中文、空格與符號本身都可以用於名稱，但複製時要避免多餘空格。若一個組引用另一個組，也要避免形成循環引用。

proxies:
  - name: 節點-A
    type: ss
    server: server.example
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 節點-A
    url: https://www.gstatic.com/generate_204
    interval: 300

三、驗證健康檢查，不要只看圖示

用戶端顯示的延遲數字可能來自手動測速，也可能來自策略組健康檢查，兩者的測試網址與時間點未必相同。遇到節點顯示可用但網站無法開啟時，應查看連線記錄，確認規則命中了哪個策略組、策略組實際選中了哪個節點，以及請求失敗發生在 DNS、建立連線，還是目標伺服器回應階段。

如果所有成員同時逾時，應優先檢查測試 URL 是否能在目前網路存取、DNS 是否回傳異常結果、系統時間是否準確，以及節點本身是否能建立連線。不要立即透過縮短 interval 反覆測速，因為提高測試頻率無法修復基本連通問題。

四、結合系統代理與 TUN 模式驗證

策略組只有在流量進入 Clash 核心後才會生效。系統代理主要接管遵循作業系統代理設定的應用程式；不讀取系統代理的程式、部分遊戲與特定 UDP 流量，可能需要 TUN 模式才能進入規則鏈。若瀏覽器能如預期切換節點，而某個應用程式始終直接連線，應先確認流量是否已被接管，而不是先修改策略組。

啟用 TUN 模式後，還要留意 DNS 模式、路由排除與區域網路存取。錯誤的 DNS 設定可能讓網域規則無法依預期匹配，路由排除則可能使目標流量繞過核心。排查時可以選擇一個明確的測試網域，依序檢查 DNS 解析、規則匹配、策略組選擇、節點連線與目標回應。

五、處理訂閱更新後的節點變化

訂閱提供者可能新增節點、修改名稱或移除舊節點。若策略組以靜態名稱列出成員，名稱變更後就會出現引用失效。mihomo 設定也可以透過代理集合與篩選規則動態整理訂閱節點，但篩選運算式需要謹慎設計，避免將「剩餘流量」「方案資訊」等非節點項目納入自動組。

使用動態篩選時，可以依地區與用途分別建立集合，並為每組保留清楚界線。例如低延遲組只包含同一業務可接受的地區，主備組只包含確實具備接管能力的線路。節點數量不是越多越好；候選成員過多會延長健康檢查清單，也會讓異常節點更難定位。

穩定策略組的實務建議

讓組名表達決策邏輯。「香港主備」「低延遲自動」「下載均衡」比「代理組 1」更方便查看連線記錄。
將業務界線置於速度之前。先確保候選節點都符合地區、帳號與協定要求，再比較延遲或分配連線。
為自動切換保留緩衝。為 url-test 設定合理的 tolerance，避免因細微延遲波動而頻繁更換出口。
不要用 load-balance 取代測速。它用於分配連線，並不保證每條連線都會選到最快節點。
定期查看實際命中結果。透過用戶端連線頁面確認網域規則、策略組與最終節點是否符合預期。
修改後進行分層測試。先驗證節點可單獨使用，再驗證健康檢查，接著檢查規則命中，最後測試實際業務。

總而言之，url-test 解決「目前哪條健康線路回應較快」，fallback 解決「主線路故障後由誰接管」，load-balance 解決「如何讓多個健康節點參與承載連線」。只要先釐清業務需要的是速度、優先順序還是分散連線，再設定健康檢查、切換門檻與規則入口，Clash 的自動分流就能保持清楚且可預期。