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

策略組在規則與節點之間扮演什麼角色

策略組（Proxy Group）會將規則指定的策略轉換為實際使用的節點。例如，規則將某個網域交給「日常代理」，該策略組再依手動選擇、延遲測試或故障切換邏輯決定出口。規則決定「這次連線交給誰」，策略組則決定「交給這個組後使用哪個節點」。

本文以 Clash Verge Rev 使用的 mihomo 核心設定為例。介面負責顯示與切換，proxy-groups 中的 type 才會決定策略組的行為。系統代理和 TUN 模式會影響流量如何進入核心，但不會讓 select 自動變成測速組，也不會改變負載平衡演算法。

類型	選擇依據	常見用途	主要限制
`select`	由使用者手動選擇成員	固定地區、手動指定出口	不會自動改選其他成員
`url-test`	探測延遲與切換容差	自動選擇延遲較低的同類線路	探測延遲低不代表下載速度快
`fallback`	成員順序與可用狀態	主要線路故障時切換至備援	不會自動選擇延遲最低的節點
`load-balance`	指定的連線分配演算法	將多條連線分配至多個出口	不會合併單一連線的頻寬

select：手動選擇入口與固定出口

select 適合需要明確指定出口的情境。在 Clash Verge Rev 的「代理」頁面展開對應策略組，點選節點或子組即可切換。若選取的節點失效，手動策略組不會只因其他成員可用就自動切換；不過，如果選取的成員本身是自動策略組，子組仍會依自身設定自動選擇。

將自動策略組放進手動入口

常見做法是將最外層設為 select，並在其中加入「自動低延遲」、「主備線路」和個別節點。平時選擇自動策略組，遇到地區限制或需要固定出口時，再手動指定節點。如此一來，規則始終指向同一個入口，不必為了臨時切換線路而修改整份規則表。

登入帳號、付款或管理後台：優先選擇地區穩定、出口明確的節點。
一般網頁瀏覽：可選擇自動測速子組，減少手動切換。
疑難排解：直接固定使用一個節點，避免自動切換影響判斷。

「固定節點」不等於「固定公網 IP」。服務端可能更換出口，或採用多出口架構。若服務需要固定 IP，應確認服務供應商提供的線路特性，不能只靠用戶端策略組保證。

url-test：依探測延遲選擇節點，tolerance 控制切換幅度

url-test 會透過候選節點連線至指定的測試 URL，記錄探測結果，並根據目前節點狀態與容差選擇節點。這類策略組適合用於地區和用途相近的線路。若混用不同地區的節點，延遲較低的地區可能持續獲選，但不一定符合目標網站的地區需求。

interval、timeout 與 tolerance 的單位

interval: 300：單位為秒，表示健康檢查的間隔為 5 分鐘。
timeout: 5000：單位為毫秒，單次探測的逾時時間為 5 秒。
tolerance: 50：單位為毫秒，用來避免因小幅延遲波動而切換線路。
lazy: true：啟用延遲檢查，策略組未使用時可能不會依間隔持續探測；不代表「每 300 秒一定會測試所有候選節點」。

以下以示意數據說明：目前節點延遲為 105ms，另一個節點為 80ms，差距只有 25ms。在 tolerance: 50 的設定下，這點差距通常不足以觸發切換；若目前節點升至 180ms，而候選節點仍為 80ms，差距便明顯超過容差。節點無法使用時，系統仍會依可用狀態重新選擇；容差並不代表必須繼續使用故障節點。

測速結果不能取代傳輸量測試

測試 URL 回傳的小型回應主要用來判斷連線是否可達及請求延遲。延遲 80ms 的節點不一定比 120ms 的節點更適合下載大型檔案；頻寬、網路壅塞、目標網站的路由和伺服器負載都可能影響結果。也別把用戶端顯示的探測延遲直接當成 ICMP ping 值，兩者的測量路徑和運作方式不同。

fallback：依清單順序切換主線與備援線路

fallback 會從成員清單前端開始尋找可用節點。只要優先節點通過可用性檢查，就會優先使用，不會比較所有節點並挑出延遲最低者。因此，主要線路應放在前面，備援線路依序列在後面。清單順序代表使用優先級，而非備註順序。

例如，節點 A 的延遲為 160ms，節點 B 為 70ms；只要 A 可用且排在 B 前面，主備策略組仍會優先使用 A。只有 A 的健康檢查失敗後，才會切換至後續可用的成員。之後探測發現 A 已恢復，新連線便可再次優先使用 A。

故障切換不等於連線遷移

已建立的 TCP 連線會綁定原有線路。策略組切換至備援節點後，既有連線不會無縫移轉至另一個出口。網頁可能透過新請求恢復，但下載、遠端終端機或會議連線可能需要重新連線。檢查間隔、單次逾時、延遲檢查設定與故障發生時機都會影響偵測速度，不能將 interval: 300 解讀為保證在 300 秒內恢復。

主備線路應盡量選擇不同的故障域，例如不同入口或不同伺服器，而非同一台伺服器上的兩個名稱。
主備策略組適合「優先維持指定線路」，不適合「永遠選擇延遲最低的節點」。
若備援線路採計量收費，應搭配流量統計確認實際用量；健康檢查本身也會產生少量請求。

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

load-balance 會依策略將連線分配給候選節點。它不會拆分同一條 TCP 連線，分別交由兩個節點傳輸，也不等同於多線路聚合。單一連線的下載工作通常仍受所選節點的頻寬限制；多連線服務才可能將負載分散到不同出口。

常見 strategy 策略比較

strategy	主要行為	選用注意事項
`consistent-hashing`	依目標資訊進行一致性雜湊映射	相同目標傾向使用同一出口；成員變更時仍可能改變映射結果
`round-robin`	在可用成員之間輪流分配連線	同一網站的不同連線可能使用不同的出口 IP
`sticky-sessions`	依來源位址與目標位址的組合，在一段時間內維持相同映射	這是 mihomo 的工作階段黏著策略，不代表永久固定出口

目標是網域還是 IP，以及 DNS 模式是否保留網域資訊，都可能影響實際分配結果。別因此推論「同一個瀏覽器永遠只會使用一個節點」。帳號服務可能同時連線至登入網域、靜態資源網域和 API 網域，即使採用一致性雜湊，也可能使用不同出口。

完整組態範例：一個手動入口，三種自動策略

以下是可併入現有 mihomo 設定的策略組與規則片段，並非包含節點憑證的完整訂閱。HK-A、HK-B 和 SG-A 必須已定義在目前設定的 proxies 中，名稱也必須完全一致。若節點來自 proxy-providers，應依實際的 provider 名稱使用 use 引入，不能只把提供器名稱當成節點名稱填入清單。

proxy-groups:
  - name: 日常代理
    type: select
    proxies:
      - 自動低延遲
      - 主備線路
      - 多連線分配
      - HK-A
      - HK-B
      - SG-A

  - name: 自動低延遲
    type: url-test
    proxies:
      - HK-A
      - HK-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: true

  - name: 主備線路
    type: fallback
    proxies:
      - HK-A
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: true

  - name: 多連線分配
    type: load-balance
    proxies:
      - HK-A
      - HK-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: true
    strategy: consistent-hashing

rules:
  - DOMAIN-SUFFIX,example.com,日常代理
  - MATCH,日常代理

合併設定時需檢查的三個位置

合併策略組清單：將新策略組加入原有的 proxy-groups，不要在同一層重複新增同名鍵。策略組名稱應保持唯一，子組之間也不可互相循環引用。
保留原有分流規則：範例中的 example.com 是示範用的比對網域。若現有設定已有直連、封鎖和地區規則，請保留這些規則，並將兜底的 MATCH 放在規則清單末尾。規則依序比對，不能把兜底規則放在業務規則前面。
確認修改的設定層級：在 Clash Verge Rev 的「設定檔」頁面確認目前啟用的設定。遠端訂閱更新可能覆蓋直接修改的內容；若要長期保留變更，應使用目前用戶端支援的合併設定或腳本機制，並確認最終生效的設定。

以上三種自動策略組都使用 lazy: true，適合在未使用時減少探測的情境。若確實需要在背景持續檢查，可評估改為 false，並留意節點數量和檢查頻率。例如，一個策略組包含 20 個節點、間隔為 300 秒，單輪就會進行 20 次探測；多個策略組重複引用這些節點時，還應一併觀察核心排程和 provider 健康檢查所帶來的實際負載。

依使用情境選擇策略組，並驗證實際流量是否命中

三種常見設定的取捨

網頁瀏覽、日常辦公：外層使用 select，預設選擇同一地區的 url-test；先以 300 秒檢查間隔和 50ms 容差觀察，再依延遲波動情況調整。
優先使用主要線路，故障時切換備援：選擇 fallback，將希望長期使用的線路排在第一位。故障時允許重新連線，並實際測試主要線路恢復後的切換行為。
大量可接受多出口的連線：可考慮使用 load-balance；先試用一致性雜湊，再評估是否確實需要輪詢。不要只為了加快單一下載工作就改用負載平衡。

在 Clash Verge Rev 中的驗證步驟

開啟「設定檔」頁面，確認目標設定已啟用。若套用設定時發生錯誤，先到「日誌」頁面檢查策略組類型、節點名稱或 YAML 縮排錯誤；設定載入失敗時不要繼續測試。
開啟「代理」頁面，在「日常代理」中選取要測試的子組。使用「規則」模式確認規則分流；「全域」模式使用全域策略入口，結果可能與業務規則不同。
執行一次策略組測速，記錄測試時間、目前節點和延遲。別只看某個節點顯示綠色數值，也要確認最外層入口實際選中了哪個策略組。
造訪一個確定應經由代理連線的網站，再到「連線」頁面依網域篩選，查看命中的規則與代理鏈。策略組已選取，不代表該請求確實使用了它。
關閉舊頁面的連線或重新發出請求後再比較。若要測試主備切換，可在能復原的測試環境中暫時停用主要線路，並記錄偵測到故障的時間，以及備援連線建立的時間。

若「測速正常但網站無法開啟」，先區分探測目標與實際服務是否可達，再檢查服務網域的 DNS 解析、規則命中情形、節點地區限制和日誌錯誤。若「切換後出口沒變」，優先檢查是否沿用舊連線、規則是否設為直連、全域入口是否選錯，以及兩個節點是否共用同一個公網出口。

選擇策略組的重點不在自動化程度，而在選擇依據是否符合需求：需要手動控制就用 select，希望依延遲選路就用 url-test，需要按順序切換主備線路就用 fallback，需要分散多條連線再考慮 load-balance。規則、策略組和節點各有分工，才能逐層找出問題。設定欄位也可參考協定手冊核對，相關概念請參閱術語表。