Clash 策略組 url-test、fallback、load-balance 怎麼選？三種自動策略的切換邏輯

三種自動策略：先確認選擇依據

Clash 自動策略組處理的是「新連線要交給哪個節點」，而不是自動改寫網站分流規則。規則會先將連線交給某個策略組，再由策略組依自身邏輯選擇節點。在規則模式下，若某個網域已符合 DIRECT，調整自動組的測速週期也不會改變該網域的出口。

三種策略都能使用健康檢查，但檢查結果的用途不同：url-test 比較延遲，fallback 依序判斷節點是否可用，load-balance 則在可用成員之間分配連線。以下主要以 mihomo 核心的設定語意為準；舊版 Clash 核心及不同用戶端可能僅支援部分欄位，請先確認實際執行的核心，不要只看應用程式名稱。

url-test：依延遲選擇，以 tolerance 降低切換抖動

url-test 會透過候選節點連線至指定測試 URL，並依探測結果選擇節點。這裡的延遲不是 ICMP Ping，也不是下載速度；它反映代理連線存取該測試網址所需的時間，並會受到節點連線、目標網站回應及網路狀態等因素影響。

日常瀏覽的起始設定

以下片段請放在設定檔頂層的 proxy-groups 底下。範例假設 香港-A、香港-B、日本-A 已列為 proxies 中的節點；實際使用時，成員名稱必須與既有節點名稱完全相同。這是策略組片段，不是包含伺服器憑證的完整訂閱。

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

• interval: 300：每 300 秒檢查一次，也就是 5 分鐘，並非 300 毫秒。
• tolerance: 50：切換容差為 50 毫秒，可避免因些微延遲差異而頻繁更換節點。
• lazy: true：啟用惰性檢查；未使用的群組不會持續以活躍群組的頻率檢查。設定檢查週期不代表背景會永遠持續探測。
• url：選擇所有候選節點都能正常存取的輕量網址；範例網址通常會回傳 HTTP 204。

用實際數值理解容差

假設目前節點 A 的測試結果為 110 毫秒，節點 B 為 90 毫秒，兩者只差 20 毫秒。若容差設為 50 毫秒，不應預期群組會因這點差距立即切換至 B。若 A 升至 180 毫秒，而 B 維持 90 毫秒，差距達 90 毫秒，就符合切換至較快節點的條件；實際更新時間仍取決於檢查與選擇時機。以上數值僅用於說明原理，並非本站實測結果。

容差不是額外等待時間，也不是判定節點故障的逾時值。設為 0 會提高對細微延遲變化的敏感度，但不保證網頁載入更快。日常使用可先從 50 毫秒開始，觀察是否頻繁切換，再決定要不要調整至 100 毫秒。

fallback：依序保留主線路，故障時啟用備援

fallback 會選擇清單中第一個可用的成員。只要第一個成員仍通過健康檢查，即使第二個延遲更低，也不會因此取代第一個。這適合「優先使用指定出口，僅在無法使用時才切換線路」，而非「永遠選擇最快的節點」。

proxy-groups:
  - name: 主備線路
    type: fallback
    proxies:
      - 香港-A
      - 日本-A
      - 香港-B
    url: https://www.gstatic.com/generate_204
    interval: 120
    lazy: true

故障與恢復時的選擇流程

1. 三個成員都可用時，會選擇清單中的第一個 香港-A。
2. 香港-A 檢查失敗、日本-A 可用時，後續連線會使用 日本-A。
3. 後續檢查確認 香港-A 已恢復後，優先順序會重新生效，新連線可能切回 香港-A。

因此，fallback 並非「切換至備援後就永久停留」的黏著式主備機制。若主線路在可用與不可用之間反覆變化，就可能發生切回。若工作時需要固定使用某條線路，使用手動 select 群組通常更直覺。

即使檢查間隔設為 120 秒，也不代表故障一定能在 120 秒內排除。實際時間還會受到故障發生位置、探測逾時、惰性檢查及應用程式重試影響。若主線路只是嚴重壅塞，但仍能連線至測試網址，fallback 也可能繼續使用它，因為「速度慢」和「無法使用」是不同狀態。

load-balance：分散連線，不合併單一連線的頻寬

load-balance 會在可用節點之間分配連線，適合多個工作同時執行，但不會將單一一般 TCP 下載連線拆分至三條線路。假設三個節點各自可提供 10 MB/s，單一連線下載不會只因啟用此策略就達到 30 MB/s。

consistent-hashing 與 round-robin 的差異

• consistent-hashing：依目標相關資訊執行一致性雜湊，讓相同目標傾向使用相同成員。適合希望減少同一目標出口變動的情境，但可用節點集合改變後，對應結果仍可能變動。
• round-robin：依序選擇可用成員，方便將多個新連線分散出去。它不會依即時頻寬、CPU 負載或剩餘流量進行調度。

proxy-groups:
  - name: 多線分流
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 香港-A
      - 香港-B
      - 日本-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

需要輪詢時，將上例的 strategy 改為 round-robin 即可，前提是目前使用的核心支援此策略欄位。這裡的分配單位是連線，不是網頁上的每次點擊，也不是 HTTP/2 連線中的每個請求。瀏覽器重複使用長連線時，即使頁面發出許多請求，也可能只會使用少數幾個節點。

interval、測試網址與節點提供者的注意事項

自動策略的檢查流量會經過候選節點。若 30 個節點的檢查間隔設為 30 秒，在持續活躍且每輪都完整檢查的簡化情況下，每小時約會產生 30 × 120 = 3600 次探測；改為 300 秒則約為 360 次。實際次數還取決於惰性檢查、提供者及核心的排程方式。這表示縮短週期會增加成本，並非越短越好。

分清訂閱更新與健康檢查

若使用 proxy-providers，提供者外層的 interval 通常控制遠端節點清單的更新週期；其中的 health-check.interval 則控制節點健康檢查。這與策略組中的同名欄位並非同一設定。將訂閱更新週期改為 60 秒，不會自動達到每分鐘測速的效果。

透過 use 引入提供者時，應確認提供者的健康檢查設定；不能只在策略組填入測試 URL，就認為所有提供者成員都已依預期完成探測。也不要未加區分地在多個位置安排高頻檢查。建議先以少量直接列出的節點驗證策略，再接入提供者，並分別檢查其更新記錄與健康狀態。

測試網址應可正常連線且結果可比較

若某些節點所在網路封鎖了測試網址，節點可能被判定為不可用，但存取其他網站仍正常。反過來說，能連上測試網址也不代表所有服務都可用。若整個群組都逾時，應先透過已知可用的節點存取同一網址，排除測試網站故障、DNS 錯誤及 TLS 交握失敗，再判斷是否為節點問題。

套用與驗證設定：確認新連線確實進入目標群組

不必同時啟用三種自動群組。若要在同一份設定中比較，可將前述三個定義放進同一個 proxy-groups 清單，再新增一個手動入口。不要在 YAML 頂層重複宣告多個同名的 proxy-groups 鍵，否則可能覆寫既有內容或造成解析錯誤。

  - name: 代理入口
    type: select
    proxies:
      - 日常自動
      - 主備線路
      - 多線分流
      - 香港-A

上例需追加到同一個清單中，並與其他群組使用相同縮排。既有規則中需要代理的目標應指向 代理入口。例如，若要明確代理 example.com 及其子網域，可將下列規則放在相關的廣泛規則之前；這只是目標規則範例，並不要求將所有既有流量都改為代理。

rules:
  - DOMAIN-SUFFIX,example.com,代理入口
  - MATCH,DIRECT

這段規則是用來說明比對關係，最後一行會讓其餘流量直連，不能直接用來取代訂閱中的完整分流規則。規則會由上而下比對，排在前面的既有規則也可能先攔截測試流量。

1. 儲存並檢查設定。確認核心未回報未知策略、群組名稱重複或節點不存在等問題；訂閱管理工具更新後可能覆蓋手動編輯的內容，若要長期修改，請使用用戶端提供的覆寫或合併設定功能。
2. 維持現有的流量接管方式。先沿用已可正常運作的系統代理或 TUN 設定，不要同時更改 DNS、連接埠與策略。這三種策略本身都不要求必須啟用 TUN。
3. 在入口中選擇目標群組。先從 日常自動 開始，執行一次檢查並記錄候選節點的延遲與目前選擇；再切換至主備群組，比較選擇順序。
4. 觀察新連線。在連線面板查看符合的規則、策略鏈與最後使用的節點。既有網頁可能會重複使用連線，必要時請關閉該頁面及其連線，再重新開啟。
5. 在可控環境中驗證故障。在本機測試設定中暫時移除主節點，或改用已知無法使用的成員，觀察後續檢查與新連線；不要透過高頻探測或中斷工作網路來測試。

常見狀況與檢查方式

• url-test 一直在兩個節點之間切換：檢查延遲差是否接近容差、測試網址是否不穩定，以及檢查週期是否設得太短。先調整一個參數，再觀察一段時間。
• fallback 沒有選擇最低延遲的節點：這是依優先順序選擇的正常結果。若要優先考量延遲，請改用 url-test，而不是繼續縮短 interval。
• load-balance 看起來只使用一個節點：先確認是否採用一致性雜湊、是否一直存取同一個目標，以及應用程式是否只建立一條長連線。
• 切換群組後出口 IP 沒變：確認查詢網站符合目標群組的規則，並重新建立連線；也要留意多個節點可能共用同一個公網出口。
• 全部顯示逾時：先檢查相同的測試 URL、節點狀態、系統時間與記錄。用戶端面板中的單次手動測速，不一定使用與自動群組相同的測試網址和參數。

選擇建議：分別設定延遲優先、主備與分流

日常瀏覽可先採用 url-test + interval 300 + tolerance 50；若要優先保留指定地區或線路，使用依順序排列的 fallback；需要分散多個獨立工作所建立的連線時，再考慮 load-balance，並先用一致性雜湊觀察服務相容性。

自動策略負責選擇節點，規則負責決定目標的流量去向，系統代理與 TUN 則負責接管流量。分開驗證這三個部分，比同時更換核心、DNS 與自動群組更容易找出問題。欄位支援與流量接管範圍可參閱本站技術參考；若要先完成匯入與基本連線，請依照使用教學逐項確認。