Clash 策略組類型比較：url-test、fallback 與 load-balance 怎麼選

先釐清策略組、節點與代理規則

Clash 與採用 mihomo 核心的 Clash Verge Rev 會將代理節點整理至策略組，再由規則決定某條連線應交由哪個策略組處理。策略組不是新的代理伺服器，也不會改變節點原有的協定、傳輸方式或出口位置；它負責的是「從組內成員中選出本次連線要使用的成員」。

例如，規則可以將影音串流網站網域交給「串流媒體」組，辦公網域交給「穩定線路」組，其餘流量交給「預設代理」組。每個組內也能使用不同類型：url-test 依據測試結果傾向選擇延遲較低的可用成員，fallback 按設定順序使用第一個可用成員，load-balance 則將不同連線分配給多個可用成員。

因此，三者的差異不能只用「哪個速度快」來概括。選擇時至少要核對四個面向：

• 成員選擇依據：依延遲、固定優先順序，或分配演算法來選擇。
• 故障後的行為：重新測速、順序往後移，或繼續在其餘成員之間分配。
• 出口一致性：同一目標或同一工作階段是否需要盡量維持相同的出口位址。
• 裝置成本：定期測試會消耗少量網路請求、電量與背景資源，行動裝置尤其需要合理設定間隔。

健康檢查測試的是什麼

自動策略通常會連線至設定中的測試位址，並在指定時間間隔內更新可用性或延遲結果。常見測試位址會回傳很小的 HTTP 回應，用來判斷 DNS、TCP、TLS 與代理鏈路是否能完成一次請求。這項結果可反映基本連通性，但不能等同於所有網站的實際下載速度。

測試目標的位置、節點至目標網站的路由、短暫壅塞及電信業者網路都會影響結果。某節點對測試位址的延遲最低，不代表存取其他地區的業務服務時也一定最快。若特定服務有明確的區域與穩定性要求，更合適的做法是先依用途篩選節點，再在較小範圍內使用自動策略。

url-test：依測試延遲選擇可用成員

url-test 會對組內成員執行連通性測試，並從可用成員中選擇測試延遲較低的一個。它適合成員功能相近、出口區域相同，而使用者主要在意互動延遲的情境。例如，同一地區有多條一般線路時，可以先用 url-test 自動完成基本篩選，減少頻繁手動切換。

以下是常見的設定結構。欄位支援情況與具體核心版本有關，匯入前應以目前的 mihomo 設定文件與用戶端日誌為準：

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval 代表測試間隔，通常以秒為單位。間隔過短會增加背景測試頻率，卻未必改善使用體驗；間隔過長則可能無法及時辨識線路狀態變化。桌上型常駐裝置可依網路波動設定為數分鐘，行動裝置則可適度延長。

tolerance 用於減少延遲差異很小時的頻繁切換。假設目前成員延遲為 95 毫秒，另一個成員測得 80 毫秒，兩者差距不大，繼續保留目前成員往往比立即切換更穩定。容許值並非越低越好；設為零可能讓輕微的測量抖動反覆改變選定項目。

啟用 lazy 後，核心可等到策略組實際被使用時才執行相應測試，有助於減少長期未使用策略組的背景請求。不過，惰性檢查的具體觸發時機與快取行為取決於核心實作，判斷結果時應以日誌及用戶端顯示的最後測試時間為準。

url-test 的適用情境與限制

• 適合網頁瀏覽、程式碼儲存庫存取，以及需要較低回應時間的日常連線。
• 適合同區域、同用途、品質相近的一組節點，不適合將功能差異明顯的出口混在一起，只依延遲進行選擇。
• 測試延遲不直接代表頻寬。大型檔案下載更容易受到出口頻寬、伺服器限速與長時間壅塞影響。
• 選定項目變更後，新連線可能使用新的出口位址。對出口一致性敏感的登入工作階段需要特別謹慎。

fallback：按順序使用第一個可用成員

fallback 的核心是優先順序，而不是比較哪個延遲最低。核心會檢查組內成員是否可用，並優先選擇清單中排在前面的可用項目。首選成員不可用時，才會使用後續成員；首選成員恢復後，之後的新連線通常會回到優先順序較高的成員。

proxy-groups:
  - name: 穩定線路
    type: fallback
    proxies:
      - 主線路
      - 備用線路-一
      - 備用線路-二
    url: http://www.gstatic.com/generate_204
    interval: 300
    lazy: true

這種邏輯特別適合線路之間存在明確等級的情況。例如，主線路出口固定、相容於目標服務且長期穩定，備用線路只在主線路故障時啟用。即使備用線路的測試延遲偶爾較低，fallback 也不會因此跳過仍可用的主線路。

「可用」需要結合測試位址來理解。測試成功只能證明節點可以存取該測試目標，不能保證所有目標服務都能存取。如果主線路能正常回應連通性測試，但某個業務網域受到路由、區域或伺服器端策略影響，策略組可能仍會將主線路視為可用。此時應調整業務規則、拆分策略組，或改用更具代表性的測試目標，而不是單純縮短檢查間隔。

fallback 更適合哪些工作

遠端辦公、固定區域服務、家庭閘道器及長時間運作的裝置，通常更重視「首選線路維持不變，故障時才往後切換」。這類需求與 fallback 的順序語意一致。設定時應將真正希望長期使用的成員放在最前面，並確保備用成員具備相同的業務存取能力。

如果清單順序沒有明確意義，所有成員都能任意替換，那麼 url-test 往往更符合日常自動選擇的需求。反過來，如果使用者希望手動決定目前節點，應使用 select 類型，而不是期待 fallback 記住一次性的手動選擇。

load-balance：將連線分配給多個可用成員

load-balance 的主要目標不是選出唯一的「最快節點」，而是依策略將不同連線分配給組內多個可用成員。它適合大量彼此獨立的請求、並行下載工作或多裝置共用閘道器，但不能將一條已建立的單一連線頻寬直接疊加成多個節點的頻寬。

proxy-groups:
  - name: 並行分配
    type: load-balance
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

常見的 consistent-hashing 會依據目標資訊進行一致性映射，讓相同或相近的目標在成員清單穩定時傾向使用同一個成員。這有助於減少同一網站在連續請求之間頻繁變更出口。成員故障或清單變動時，部分映射仍會調整，因此它不是永久固定的出口。

round-robin 則更接近輪流分配新連線。它能讓成員獲得較平均的連線機會，但同一應用程式存取多個網域或建立多條連線時，可能出現不同的出口位址。實際可用的 strategy 值會隨 Clash 分支與 mihomo 版本而變化，使用前應查閱目前的核心文件，不能直接將其他實作的欄位複製到設定中。

負載平衡不等於單一連線聚合

使用瀏覽器下載檔案時，如果伺服器只建立單一連線，該連線通常只會經過一個成員。只有下載器、瀏覽器或應用程式建立多條獨立連線，且這些連線被分配至不同成員時，整體吞吐量才可能利用多條線路。最終速度仍會受到本地網路上限、節點限速、目標伺服器與協定行為影響。

負載平衡也會帶來出口一致性問題。部分網站可能將短時間內頻繁變化的來源位址視為異常，登入狀態、驗證碼頻率或區域內容也可能受到影響。對於這類服務，可以透過規則將網域交給 fallback、url-test 或固定的 select 組，再將靜態資源、軟體更新等並行請求交給負載平衡組。

UDP 流量同樣需要留意工作階段映射與節點支援情況。語音、遊戲或 QUIC 連線對路徑變化較為敏感，不應只為了「均衡」而讓相關流量頻繁切換出口。完成設定後，應使用實際應用程式測試封包遺失、延遲抖動與重新連線情況，而不是只查看健康檢查數值。

依裝置與情境選擇策略組

桌面日常瀏覽：優先考慮 url-test

Windows、macOS 或 Linux 桌面裝置通常會同時處理網頁、程式碼下載與即時通訊。如果節點來自同一地區、存取能力相近，可以使用 url-test，並設定合理的容許值以避免抖動。對於必須固定區域或需要穩定出口的網域，再透過規則分流至獨立的 fallback 或手動選擇組。

遠端辦公與固定業務：優先考慮 fallback

企業系統、遠端桌面、管理後台與長期登入服務更重視可預測性。將最符合要求的線路放在第一位，再依實際可靠程度排列備用成員，比單純按毫秒延遲排序更合適。備用成員應事先驗證目標服務、DNS 解析與 UDP 支援，不能等主線路故障後才發現備用線路不相容。

家庭閘道器與多裝置並行：謹慎使用 load-balance

路由器或旁路閘道器同時承載多台裝置時，連線數量較多，負載平衡更容易發揮連線分配的作用。建議使用規則將對出口一致性敏感的服務獨立分組，再讓系統更新、靜態資源與一般並行請求進入 load-balance。閘道器硬體效能有限時，還要留意健康檢查、TUN 轉送與大量連線追蹤造成的資源占用。

行動裝置：延長測試間隔並縮小成員範圍

筆電與行動終端會在 Wi-Fi、熱點及行動網路之間切換。網路環境變化本身就可能使測試結果失效，過於頻繁的健康檢查意義有限。可以減少自動組中的成員數量、延長間隔，並啟用適當的惰性檢查。若裝置只是偶爾使用代理，手動選擇組也可能比複雜的自動策略更直觀。

TUN 模式不會改變策略組語意

TUN 模式負責接管更多系統流量，包括部分不遵循系統代理設定的程式；它不會把 url-test 變成負載平衡，也不會改變 fallback 的成員順序。流量進入 mihomo 後，仍會先依規則匹配至策略組，再由策略組選擇成員。

啟用 TUN 後，連線範圍會擴大，DNS、區域網路流量與 UDP 應用也可能進入核心，因此策略組設定問題會表現得更加明顯。排查時要區分「流量是否由 TUN 接管」、「規則命中了哪個策略組」以及「策略組最後選中了哪個成員」三個階段。

策略組未如預期切換的排查順序

1. 確認實際執行中的設定。

   訂閱更新後可能產生新的策略組，設定覆寫也可能改變組名、成員與測試參數。先在 Clash Verge Rev 的設定頁確認目前啟用的設定，再核對執行中的策略組內容。

2. 查看規則命中結果。

   連線沒有進入目標策略組時，調整組內演算法不會產生效果。開啟連線或日誌頁面，確認網域、目標位址、規則類型以及最後命中的策略名稱。

3. 檢查健康測試狀態。

   觀察各成員的最後測試時間、延遲與可用狀態。全部逾時通常需要檢查測試位址、DNS、節點本身與本地網路；只有個別成員失敗，則應單獨驗證對應線路。

4. 核對名稱與縮排。

   YAML 對縮排十分敏感，proxies 中的名稱也必須與節點或其他策略組名稱完全相符。名稱包含特殊字元時，可以用引號包住，避免解析時產生歧義。

5. 使用新連線重新測試。

   關閉測試應用程式中的現有工作階段，或等待連線結束後重新存取。只重新整理介面上的策略狀態，無法讓所有已建立的連線立即切換。

6. 區分 DNS 與代理故障。

   網域無法解析時，策略組可能尚未取得可連線的目標。應先檢查 DNS 日誌、nameserver 設定與攔截設定，再判斷節點選擇是否異常。直接使用 IP 可以連線而網域失敗時，通常更應優先排查解析鏈路。

三類策略的快速結論

• 需要自動選擇低延遲成員：使用 url-test，並透過容許值減少頻繁切換。
• 需要固定主線路與依序備援：使用 fallback，依實際業務優先順序排列成員。
• 需要將大量獨立連線分散至多個成員：使用 load-balance，同時處理出口一致性問題。
• 需要由使用者明確指定節點：使用 select，不要用自動策略模擬手動控制。

實際設定可以組合使用：頂層策略組提供手動選擇，內部再放入自動測速組、故障轉移組與負載平衡組。規則只引用用途明確的組名，組內成員維持同類，測試位址與間隔則依裝置和業務調整。如此既方便在 Clash Verge Rev 中查看狀態，也能在發生故障時快速判斷問題出在規則、健康檢查還是節點本身。