Clash 策略組 url-test、fallback、load-balance 比較與選擇

三種策略組怎麼選

Clash 自動策略組解決的是「這條連線要透過哪個節點出去」，並非讓每個 App 自動取得更高頻寬。url-test 比較探測延遲，fallback 依節點優先順序切換，load-balance 則將不同連線分配至可用節點。先確認需求是低延遲、固定主備，還是分散連線，再調整設定欄位。

策略邏輯由核心執行。用戶端負責匯入訂閱、顯示測速結果及提交選擇；不同用戶端即使按鈕名稱相似，使用的核心及支援欄位也可能不同。以下 YAML 以 mihomo（即 Clash Meta 後續採用的核心名稱）所支援的設定為準。其他 Clash 核心是否接受相同欄位，請以其設定文件及載入記錄為準。

url-test：依探測延遲自動選擇

url-test 會透過各候選節點連線至指定測試 URL，記錄探測延遲，再從可用候選節點中選擇出口。這裡的「測速」是對單次請求進行延遲探測，並非持續下載測試。結果會受到本機網路、節點至目標網站的路由、DNS、連線建立及伺服器回應等因素影響。

interval 與 tolerance 的作用

• interval: 300：週期性健康檢查的間隔為 300 秒，也就是 5 分鐘。這不是連線逾時時間。
• tolerance: 50：延遲切換容差為 50 毫秒。用來避免候選節點只快一點點時頻繁切換。
• timeout: 5000：單次健康檢查的逾時上限為 5000 毫秒。探測時間超過上限時，可能會判定為失敗。
• lazy: false：策略組閒置時不暫停週期性健康檢查，方便觀察連續探測結果。

例如，目前節點測得 120 毫秒，另一個節點測得 95 毫秒，兩者只差 25 毫秒；若容差設為 50 毫秒，就不應期待只憑這點優勢便切換。若另一個節點降至 60 毫秒，差距達 60 毫秒，才可能超過此容差。以上數值僅用來說明設定，並非實際線路測試結果；最終選擇也會受節點存活狀態及核心實作影響。

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

測試網址應能透過每個候選節點存取，且回應內容精簡、運作穩定。範例 URL 僅供連線探測，不代表能反映所有網站的連線品質。若主要使用特定服務網站，也應另外測試該網站的實際請求；不要將登入頁、驗證碼頁或大型檔案網址直接當作週期性探測目標。

fallback：依清單順序保留主備線路

fallback 的主要目標不是選擇延遲最低的節點，而是從候選清單中選用順序最前且通過健康檢查的節點。適合希望平時固定使用同一出口，只在主線路故障時切換至備援線路的情境。

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

故障切換與恢復順序

1. 「香港-A」通過檢查時會優先使用，即使「日本-A」的探測延遲較低也一樣。
2. 「香港-A」被判定為無法使用後，會選擇下一個可用的「日本-A」；若它也無法使用，才會檢查「香港-B」。
3. 後續健康檢查確認「香港-A」恢復後，策略可能重新優先選用它，後續連線也可能回到主線路。

因此，fallback 代表依優先順序選擇，不等於「切換到備援後就一直留在備援」。若業務需求是經人工確認後才切回，應以手動 select 組管理出口，不能只靠自動主備組完成這項流程。

故障不一定會在發生的同一秒被偵測到。若只考慮週期性檢查，線路可能在一次探測成功後立即中斷，接著必須等到下一輪檢查及逾時判定。其他故障觸發機制則取決於核心設定，不能將 interval: 300 解讀為保證立即切換。

備援線路最好有不同的故障來源。名稱不同但實際共用同一上游出口的兩個節點，可能同時故障。重要工作應分別檢查本機網路、節點可用性及目標服務狀態，避免將目標網站本身故障誤判為主節點故障。

load-balance：分配連線，不合併頻寬

load-balance 會在可用節點之間分配連線。多個網頁、下載工作或前往不同目標的請求，可以透過不同出口連線，但已建立的單一 TCP 連線仍會使用原先選定的節點。瀏覽器顯示的總下載速度是否提高，取決於工作是否並行、伺服器限制，以及各節點是否共用頻寬。

proxy-groups:
  - name: 分散連線
    type: load-balance
    proxies:
      - 香港-A
      - 香港-B
      - 日本-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: false
    strategy: consistent-hashing

consistent-hashing 與 round-robin

一致性雜湊並非永久綁定。候選節點數量或健康狀態改變後，對應關係可能隨之變動；網域是否可用、目標如何識別，也會影響分配結果。單一頁面可能會請求多個不同網域，因此「同一個頁面」不代表「所有請求都使用同一個出口」。

mihomo 也提供 sticky-sessions 策略，可依來源及目標相關資訊，在一段時間內維持分配黏著性。若要使用，請先確認目前的核心支援此功能並核對其行為；不要將擴充欄位直接複製到尚未確認相容性的舊版核心設定中。

登入與長時間連線的出口安排

銀行、支付、企業驗證或對出口 IP 敏感的服務，較適合分流至固定節點或手動策略組。負載平衡可能讓同一帳戶的不同連線使用不同公網 IP，導致重新驗證。即使採用一致性雜湊，也應將相關網域一併檢查，而非只測試首頁。

策略組接入規則與訂閱覆寫

定義策略組不代表流量已經進入該組。在規則模式下，連線會先依 rules 由上而下比對，再由符合的規則指定節點或策略組。用戶端的系統代理、TUN 與規則比對分屬不同層次：前兩者決定流量如何進入核心，策略組則決定進入後的出口選擇。

可以將三種自動策略組放進同一個手動入口，在用戶端選擇所需策略。以下片段以三個自動組都已定義為前提；組名可自行設定，但參照名稱必須一致，也不能讓策略組之間形成循環參照。

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - 自動延遲
      - 主備線路
      - 分散連線

rules:
  - DOMAIN-SUFFIX,example.com,主備線路
  - MATCH,出口選擇

example.com 是用來示範規則結構的保留範例網域。這條規則說明可以將特定網域固定交由主備組處理，其餘連線再由「出口選擇」處理；並非建議取代訂閱中的所有既有規則。MATCH 是兜底規則，應放在需要優先比對的規則之後。

保留訂閱更新後的設定

• 直接修改從訂閱下載的 YAML，下一次更新時可能會被覆寫。請先確認用戶端是否支援持續保留的覆寫或設定合併功能。
• 使用用戶端的覆寫功能時，請確認陣列是整體取代、附加項目，還是依名稱合併。不同用戶端的實作方式不可直接互相套用。
• 使用 proxy-providers 時，策略組通常會透過 use 參照提供者。提供者本身的健康檢查與策略組的候選節點管理，也都需要一併確認。
• 訂閱端變更節點名稱後，靜態 proxies 參照可能會失效。更新後請檢查載入記錄及組內候選節點清單。

通用欄位與規則順序可參閱YAML 手冊的策略組說明。若涉及流量接入方式，再對照TUN 設定教學；不必為了更換策略組而同時修改所有網路設定。

自動切換異常的檢查順序

測速正常，下載速度卻很慢

先釐清延遲與傳輸量的差異。健康檢查只會請求小型資源，無法測出尖峰時段的壅塞、持續傳輸限速或單一連線頻寬。請固定下載目標與測試時段，手動選擇候選節點比較持續傳輸速度；不要只憑 80 毫秒與 100 毫秒的差距判斷哪條線路下載較快。

節點已中斷，卻沒有切換

1. 確認目前是否為規則模式，並在連線記錄中核對實際符合的規則及最終出口。
2. 確認 App 流量確實有進入 Clash。終端機工具可能需要另外設定代理環境變數，不一定會遵循 macOS 系統代理設定。
3. 檢查 url 是否能透過節點測試、interval 是否設得太長，以及策略組是否因延遲檢查而未持續進行預期的探測。
4. 重新建立一條測試連線，確認是「新連線仍未切換」，還是「舊連線仍在使用原出口」。

url-test 頻繁切換節點

先記錄多個檢查週期的延遲變化，再調整容差。可以先以 interval: 300 和 tolerance: 50 作為起點觀察，不必把間隔縮短至幾秒。若候選節點只有輕微波動，適度增加容差有助於減少切換；若測試網址本身不穩定，應先改用合適的探測目標。

所有節點都顯示無法使用

優先檢查測試 URL 是否可存取、DNS 解析、本機網路及訂閱憑證，不要立刻重新安裝用戶端。使用同一節點連線至其他已知可用的小型頁面，再比對記錄中的逾時、解析失敗或連線遭拒等訊息。所有候選節點同時失敗，可能是共用依賴項故障，而非每條遠端線路同時中斷。

設定驗證與日常選用

網頁瀏覽及互動式請求可先使用 url-test；有明確主線路且希望備援接手時，使用 fallback；需要分散多個獨立工作流量時，再考慮 load-balance。若單一帳戶需要穩定的公網 IP，固定節點或手動選擇通常較容易控管。

1. 保留原始設定。留存可供還原的副本，先只修改策略組，不要同時調整 DNS、TUN 堆疊及所有規則。
2. 確認設定已載入。檢查用戶端記錄，排除未知欄位、找不到節點名稱及策略組循環參照等錯誤。
3. 驗證實際出口。送出新請求，並在連線記錄中查看符合的規則、策略鏈及最終節點，不要只看策略組標題。
4. 至少觀察兩個週期。若間隔設為 300 秒，請留出相應時間讓健康檢查完成；手動測速只能反映當次結果。
5. 在可控環境測試備援。在可復原的環境中模擬主節點無法使用，再讓它恢復，分別觀察後續連線的切換與切回情況。

策略組設定的重點，是讓選擇規則符合實際需求。延遲、可用性、出口穩定度及並行分配是不同指標；分開驗證，比反覆按測速或盲目縮短檢查間隔更容易找出問題。