Clash 策略組 url-test、fallback 與 load-balance 怎麼選

1. 先釐清：最低延遲、優先順序與連線分流

三種策略組都能包含多個代理節點，但用途各不相同。url-test 依探測延遲自動選擇；fallback 按清單順序選擇可用節點；load-balance 則依分配演算法，將不同連線交由多個可用節點處理。選擇前，先確認需求是「自動挑選最佳節點」、「主備切換」還是「分散連線」。

類型	主要依據	適用情境	注意事項
`url-test`	健康檢查測得的延遲	日常瀏覽、自動選擇低延遲節點	探測速度快，不代表下載頻寬大
`fallback`	節點順序與可用狀態	固定主要線路，由備援線路接手	不會因備援節點較快就主動改選
`load-balance`	連線分配策略與可用狀態	讓多個節點分擔不同目標或連線	不會疊加單一連線的頻寬

本文設定以使用 mihomo 核心的用戶端為準。舊版 Clash 與不同分支對擴充欄位的支援可能不同，尤其是負載平衡演算法。請先在用戶端的「關於」或核心資訊中確認核心名稱，儲存設定後再檢查載入結果；不要只看用戶端名稱判斷相容性。

2. url-test：依探測延遲選擇，以 tolerance 減少波動

url-test 適合沒有固定出口需求的日常流量。核心會透過各個候選節點連線至測試網址、記錄探測結果，再依據可用性、延遲與切換容差選擇出口。測量的是特定 HTTP 請求所花的時間，不是 ICMP ping，也不是持續下載測速。

基本設定：每 300 秒探測一次，容差 50 毫秒

以下片段需合併至現有設定。範例中的「香港 01」、「香港 02」、「日本 01」必須已存在於 proxies，且名稱須與實際節點完全一致；若使用訂閱節點池，後文會說明 use 的寫法。

proxy-groups:
  - name: 自動低延遲
    type: url-test
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

interval: 300：定期探測間隔為 300 秒，也就是 5 分鐘，不是 300 毫秒。
tolerance: 50：切換容差為 50 毫秒，可避免延遲只有些微變化時頻繁切換節點。
lazy: false：停用延遲探測，讓未使用的群組也能定期更新健康狀態；代價是探測請求會增加。

例如，目前節點測得 110 毫秒，另一個節點為 95 毫秒，差距只有 15 毫秒。設定 50 毫秒容差後，不應將這次差異解讀為「一定要切換」。若候選節點降至 45 毫秒，改善幅度達 65 毫秒，才較符合切換條件。以上數值僅用於說明參數，並非線路實測；實際結果也會受到探測時機、目前節點狀態與核心實作方式影響。

延遲最低，為什麼看影片還是卡？

小型探測請求無法代表尖峰時段的傳輸量。節點可能對測試網址回應很快，卻限制影音服務的速度，或是通往目標網站的路徑壅塞。遇到這種情況，應一併比較實際使用狀況與連線記錄，而不是把 interval 從 300 改成 5，試圖靠頻繁測速提升頻寬。

若低延遲節點在兩個地區間反覆切換，登入網站可能會偵測到出口變動。可適度提高 tolerance，或將同一地區的節點分成獨立群組。若業務需要長期固定出口，則較適合手動選擇或明確設定主備架構。

3. fallback：依節點順序設定主備關係

fallback 的關鍵在於順序。清單中第一個可用節點的優先順序最高；該節點無法使用時，才會依序嘗試後續候選節點。主節點經健康檢查恢復可用後，選路也可能回到優先順序較高的節點，因此並非「切換到備援後就永遠停留在那裡」。

proxy-groups:
  - name: 主備線路
    type: fallback
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 60
    lazy: false

在這個範例中，即使「香港 01」的延遲是 180 毫秒、「香港 02」是 60 毫秒，只要前者被判定為可用，仍會優先使用「香港 01」。因此，將較慢但穩定的線路排在第一位，就是有效的主備設定，不代表測速失靈。

切換時間並非固定 60 秒

interval: 60 只設定定期探測的間隔，並非故障復原時間的保證。故障若發生在兩次探測之間，可能得等到下次檢查；單次檢查本身也需要時間。連線失敗所觸發的額外檢查及相關參數，也會因核心版本與設定而異。

將業務優先使用的節點排在最前面，不要只依測速結果任意調整清單順序。
主備節點應盡量避免共用相同的故障點；若上游發生相同故障，所有候選節點可能同時失效。
主節點失效後，現有 TCP 連線可能中斷，需要由應用程式重新連線；策略組不會遷移既有連線。

4. load-balance：分配不同連線，不會疊加單一連線速度

load-balance 會在可用候選節點中進行選擇，但不會將單一 TCP 連線拆分至多個代理節點。單一執行緒下載通常仍由一個出口承載；多連線下載則可能使用不同節點，也會受到下載工具、伺服器、連線重用與分配演算法影響，不能因此保證總速度成倍提升。

consistent-hashing：讓相同目標盡量使用同一出口

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

consistent-hashing 會依目標位址進行一致性雜湊分配，讓相同目標盡量使用同一節點。可用節點集合變動時，對應關係仍可能改變。這適合分散不同目標的連線，但不代表「整個瀏覽器永遠固定使用同一出口」：同一個頁面可能會連線至登入、圖片、介面等多個網域。

round-robin：輪流分配新連線

將上例的 strategy 改為 round-robin，即可輪流分配連線。輪詢不代表依流量大小平均分配，也不會依剩餘流量配額自動調整。一條長時間下載連線與一條很快結束的網頁連線，流量大小可能相差甚遠。

登入、付款或對出口變動敏感的服務，建議使用固定節點或獨立的穩定策略組。既有 HTTP/2 長連線可能承載大量請求，因此也不能只靠連續重新整理幾次網頁，就判定輪詢未生效。請在連線面板確認新建立的連線實際使用哪個節點。

5. interval、tolerance 與節點池：設定注意事項

欄位	說明	設定建議
`url`	健康檢查使用的 HTTP 測試網址	選擇穩定、回應內容小的目標；比較不同群組時，請使用相同網址
`interval`	探測間隔，單位為秒	日常使用可從 300 秒開始；主備需求則可視情況縮短
`tolerance`	`url-test` 的切換容差，單位為毫秒	可從 50 毫秒開始設定，不用來決定主備優先順序
`lazy`	未使用群組時是否略過定期探測	若需持續更新備援群組狀態，請明確設為 false
`strategy`	`load-balance` 的分配演算法	明確選擇一致性雜湊或輪詢，不要與測速容差混為一談

別混淆 proxies 與 use

proxies 用來指定節點或其他策略組的名稱；use 則指定 proxy-providers 中定義的節點提供者。假設現有設定已定義名為「訂閱節點池」的提供者，可如下設定讓自動群組使用：

proxy-groups:
  - name: 訂閱自動選擇
    type: url-test
    use:
      - 訂閱節點池
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

這不是可獨立運作的完整設定，前提是「訂閱節點池」已存在。提供者的 interval 控制節點資源更新間隔；提供者中的 health-check.interval 控制健康檢查間隔；群組內的 interval 則控制策略組的探測週期。這幾個同名欄位位於不同層級，不能互相取代。

節點數量也會影響成本。若一個群組包含 30 個候選節點，每 300 秒對所有候選節點執行一輪探測，每小時約會產生 360 次探測請求；實際次數會受到延遲探測、額外檢查等機制影響。將間隔縮短至 30 秒會大幅增加請求量，卻不一定能改善日常使用體驗。

6. 套用規則與用戶端：先確認群組，再檢查流量

建立策略組後，還需要讓規則或上層手動選擇群組來引用它。以下組合方便比較三種行為；合併時，請將這些群組加入同一個 proxy-groups 清單，不要在 YAML 頂層重複宣告多個同名鍵。

proxy-groups:
  - name: 代理出口
    type: select
    proxies:
      - 自動低延遲
      - 主備線路
      - 多線分流
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,代理出口
  - MATCH,代理出口

這個片段以先前已建立三個自動群組為前提，只示範引用關係，並非台灣本地與海外分流方案：最後的 MATCH 會將先前未符合規則的請求交給「代理出口」。請依實際用途保留既有規則，不要為了測試而覆蓋原有的直連規則。

備份設定。先匯出目前設定；遠端訂閱更新可能會覆蓋直接修改的內容。若要長期保留，請使用用戶端支援的覆寫、合併或擴充設定功能。
載入設定。檢查記錄中是否出現未知群組名稱、未知節點名稱或 YAML 縮排錯誤。縮排請使用空格，不要使用定位字元。
切換規則模式。確認用戶端目前使用「規則」模式；在「全域」模式下，規則清單無法用來驗證流量分流路徑。
選擇入口群組。在「代理」頁面找到「代理出口」，分別選擇三個自動群組，再執行用戶端提供的「測速」或「延遲測試」。按鈕名稱會因用戶端而異。
檢查連線。開啟「連線」頁面，確認請求命中的規則、策略鏈與最終節點。手動測速是即時測試，不等同於完整觀察定期健康檢查週期。

驗證主備切換時，可先備份，再從測試設定中暫時移除首選節點，重新載入後觀察下一個候選節點是否接手。驗證出口切換時，請建立新的業務連線，避免瀏覽器連線集區繼續重用舊連線。若要排查 TUN 模式的流量接管問題，可參閱故障排除手冊，先確認流量確實進入核心。

7. 依使用情境選擇預設方案

日常瀏覽與一般應用程式：先選用 url-test，以 300 秒探測間隔、50 毫秒容差作為測試起點，再依實際波動調整。
有固定首選線路：選用 fallback，仔細排列候選節點順序；備援線路延遲較低，也不會改變優先順序。
多條線路分擔不同連線：選用 load-balance，優先考慮 consistent-hashing；確實需要輪詢時，再使用 round-robin。
帳號需要穩定出口：另外設定手動選擇群組與網域規則，不要將這類請求混入頻繁變動的自動群組。

最後應確認「實際請求符合了哪條規則、最終使用哪個節點」。延遲數值、群組名稱中的「自動」字樣，以及系統代理開關，都不能取代這項檢查。先用少量候選節點驗證邏輯，再擴充節點池，通常比同時調整測速間隔、DNS 與 TUN 設定更容易找出問題。