Clash 策略組設定詳解：url-test、fallback 與 load-balance 的差異

先釐清策略組要解決的問題

Clash 或 mihomo 讀取訂閱後，通常會取得一批代理節點。策略組位於節點與分流規則之間：規則將請求交給某個策略組，再由策略組決定實際使用哪個節點。手動選擇組由使用者指定節點；自動策略組則依照延遲、可用狀態或分配演算法持續選擇。

url-test、fallback 與 load-balance 都會對組內節點執行健康檢查，但三者的選擇目標不同。若將它們簡單理解為「都能自動選節點」，很容易導致設定偏差。例如，備援線路需要穩定的主備順序，卻誤設為優先選擇最低延遲；下載任務想分散連線，卻誤以為負載平衡能疊加單一連線的頻寬。

策略組類型	主要目標	選擇方式	適用情境
`url-test`	降低存取延遲	從健康節點中選擇測速結果較低者	網頁、搜尋、互動式應用程式
`fallback`	維持線路可用性	依清單順序使用第一個健康節點	主線路加備援線路、遠端辦公
`load-balance`	分散多個連線	依一致性雜湊或輪詢演算法分配	多連線下載、並行請求、批次工作

url-test：以回應延遲為主要選擇依據

url-test 會透過組內各節點存取指定測試網址，記錄回應耗時，並從可用節點中選擇較快者。它適合網頁瀏覽、即時通訊、遠端終端機等對互動延遲敏感的流量。測得的 68 ms、115 ms 或 240 ms 是測試請求的往返表現，不等於下載速度，也不能直接代表節點的可用頻寬。

可直接使用的基本設定

proxy-groups:
  - name: "自動選擇"
    type: url-test
    proxies:
      - "香港 01"
      - "香港 02"
      - "日本 01"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80
    lazy: true

rules:
  - DOMAIN-SUFFIX,example.com,自動選擇
  - MATCH,自動選擇

這段設定每 300 秒安排一次健康檢查，測試網址正常時會回傳空回應。tolerance: 80 表示目前節點與候選節點的延遲差距未明顯超過 80 毫秒時，盡量避免頻繁切換。假設目前節點為 92 ms，新結果為 54 ms，兩者只差 38 ms，通常維持目前節點會比立即切換更穩定；若新節點為 55 ms、目前節點升至 190 ms，切換就更有意義。

參數如何設定較穩妥

url：測試網址應回傳體積小、穩定且可預期的回應。若測速目標本身受到流量限制或地區封鎖，所有節點都可能被誤判為異常。
interval：單位為秒。日常使用可從 300 秒開始；網路變化頻繁時可縮短至 120 秒；固定的家用網路設定為 600 秒也相當合理。
tolerance：單位為毫秒。設定為 0 會讓細微的延遲變化也影響選擇，容易在數值接近的節點間反覆切換。常用範圍為 50 至 150 毫秒。
lazy：啟用後，未實際使用的策略組可減少不必要的主動測試。若需要持續監測備援組，則可依核心行為與實際需求決定是否關閉。
proxies：節點名稱必須與設定中定義的名稱完全一致，若包含空格、地區符號或數字，建議加上引號。

延遲最低不一定代表體驗最好。一個節點測得 48 ms，但晚間可用頻寬只有 8 Mbps；另一個節點測得 86 ms，卻能穩定達到 120 Mbps。開啟網頁可能較適合前者，大型檔案下載則可能較適合後者。因此，url-test 的正確定位是以延遲為導向的選擇，而不是綜合效能評分。

fallback：依優先順序維持可用性

fallback 同樣會執行健康檢查，但不會從所有健康節點中尋找最低延遲者。它依照 proxies 清單順序檢查，優先使用排在前面且目前可用的節點。第一項失效後才會切換到第二項；第一項恢復並通過檢查後，策略組即可回到優先線路。

這種行為適合「主線路優先、備援線路兜底」的明確需求。例如，公司業務需要固定地區的出口，主節點應維持在首位；只有主節點連線失敗，才允許切換至同地區的備援節點。此時即使備援節點延遲低 30 ms，也不應主動取代主節點。

主備線路 YAML 範例

proxy-groups:
  - name: "辦公線路"
    type: fallback
    proxies:
      - "新加坡 專線"
      - "新加坡 備援"
      - "日本 備援"
    url: "http://www.gstatic.com/generate_204"
    interval: 180
    lazy: false

rules:
  - DOMAIN-SUFFIX,corp.example,辦公線路
  - DOMAIN-SUFFIX,meeting.example,辦公線路

這裡的排序就是優先順序：先使用「新加坡專線」，無法使用時切換至「新加坡備援」，兩者都失敗後才使用「日本備援」。interval: 180 表示約每 3 分鐘重新檢查一次。故障發生在兩次檢查之間時，正在建立的連線仍可能先經歷逾時，因此對恢復時間要求高的業務，不宜將間隔設得過長。

哪些情況不適合使用 fallback

希望始終選擇目前最低延遲的節點時，應使用 url-test。
希望多個節點同時承擔大量獨立連線時，應考慮 load-balance。
多個節點沒有明確優先級，只是名稱排序不同；使用 fallback 不會自動比較它們的速度。
需要固定出口位址的登入工作階段，不應任意放入跨地區的備援節點，否則故障切換後出口地區會改變。

load-balance：將多個連線分配給不同節點

load-balance 的目標是讓組內多個健康節點共同承擔連線，而不是選出唯一的「最快節點」。它較適合網頁包含大量獨立資源、分段下載、並行 API 請求或批次工作。具體的連線分配方式由 strategy 決定，mihomo 常用策略包括 consistent-hashing 與 round-robin。

一致性雜湊設定

proxy-groups:
  - name: "並行分流"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - "香港 01"
      - "香港 02"
      - "香港 03"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    lazy: true

rules:
  - DOMAIN-SUFFIX,download.example,並行分流
  - DOMAIN-SUFFIX,static.example,並行分流

consistent-hashing 會根據目標資訊進行穩定映射，使相同目標在節點集合沒有明顯變動時，傾向於分配至同一個代理。它能減少同一網站的多個請求頻繁更換出口位址，適合登入狀態、CDN 資源及對出口一致性有一定要求的情境。

輪詢設定

proxy-groups:
  - name: "輪詢節點"
    type: load-balance
    strategy: round-robin
    proxies:
      - "日本 01"
      - "日本 02"
      - "日本 03"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    lazy: true

round-robin 會以輪詢方式將新連線依序分配給健康節點，更直接地分散連線數量。它適合目標服務允許出口變動的並行工作。若同一網站對 IP 變更敏感，輪詢可能導致登入、驗證碼或工作階段驗證出現額外問題，此時應優先採用一致性雜湊，或直接使用單節點策略。

健康檢查參數與節點來源

三種策略組都依賴健康檢查。測試結果顯示逾時或負數時，不要立刻判定訂閱節點全部失效。先確認測試 URL 可存取、系統時間正確、DNS 能解析目標網域，並檢查本機防火牆是否攔截核心程序。若某個測試網址在特定網路中不穩定，可以改用另一個回傳小型回應的 HTTPS 或 HTTP 網址，再比較結果。

現象	優先檢查項目	建議操作
所有節點同時逾時	測試 URL、DNS、本機網路	直接用瀏覽器存取測試網址，並檢查核心日誌
單一節點持續逾時	節點參數、伺服器狀態	手動選擇該節點測試實際連線
url-test 頻繁切換	`tolerance` 太小	從 80 ms 或 100 ms 開始調整
fallback 沒有選擇最低延遲節點	節點排列順序	依業務優先級重新排序，或改用 url-test
負載平衡後登入失效	出口位址頻繁變更	改用一致性雜湊或單節點組

訂閱節點較多時使用代理提供者

節點由訂閱動態更新時，逐一填寫 proxies 不便維護。mihomo 可以透過 proxy-providers 定義訂閱來源，再在策略組中使用 use 引用提供者。訂閱更新後，符合條件的節點會加入對應的策略組。

proxy-providers:
  main-subscription:
    type: http
    url: "https://subscription.example/profile.yaml"
    path: "./providers/main.yaml"
    interval: 21600
    health-check:
      enable: true
      url: "http://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: "香港自動"
    type: url-test
    use:
      - main-subscription
    filter: "(?i)香港|港|HK"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

filter 使用正規表示式篩選節點名稱。範例會保留名稱中含有「香港」「港」或「HK」的節點，(?i) 表示英文比對時忽略大小寫。不同訂閱的命名方式可能是「Hong Kong」「HKG」或地區旗幟符號，實際使用前應查看節點清單，再依真實名稱調整表示式。

提供者層與策略組層都可能執行健康檢查。前者用於維護節點可用狀態，後者用於策略選擇。節點數量達到 100 個以上時，將多個檢查間隔都設為 30 秒會產生大量探測請求。日常設定通常使用 300 秒；訂閱更新間隔可設為 21600 秒，也就是 6 小時。

在 Clash Nyanpasu 中套用設定

先確認目前執行的核心支援設定中的策略類型與參數。在 Clash Nyanpasu 中可進入「設定」→「Clash 核心」查看核心類型與版本；使用 mihomo 核心時，可在日誌開頭確認實際載入的版本。本文範例採用 mihomo 常見語法，較早期的 Clash 分支可能無法辨識部分負載平衡策略或提供者篩選參數。

進入「設定檔」頁面，找到目前啟用的訂閱設定檔。
開啟設定檔編輯入口，定位頂層的 proxy-groups 區段。
將新策略組加入 proxy-groups，注意每一層使用一致的空格縮排，不要使用 Tab。
在 rules 中將需要處理的網域、規則集或兜底規則指向新的組名。
儲存並重新載入設定檔，接著開啟「日誌」檢查是否出現 YAML 解析錯誤或找不到代理節點的提示。
在代理組介面執行一次延遲測試，確認節點狀態與自動選擇結果符合預期。

組合使用三種策略組

複雜設定不必只選一種類型。可以先依地區建立 url-test 組，再將地區組用於手動選擇；也可以為關鍵業務建立 fallback，為大量下載建立 load-balance。需要注意的是，策略組巢狀應保持目標清楚，避免形成循環引用。

proxy-groups:
  - name: "香港低延遲"
    type: url-test
    proxies:
      - "香港 01"
      - "香港 02"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "日本低延遲"
    type: url-test
    proxies:
      - "日本 01"
      - "日本 02"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "關鍵業務"
    type: fallback
    proxies:
      - "香港低延遲"
      - "日本低延遲"
    url: "http://www.gstatic.com/generate_204"
    interval: 180

  - name: "節點選擇"
    type: select
    proxies:
      - "香港低延遲"
      - "日本低延遲"
      - "關鍵業務"
      - DIRECT

這個結構會先在各地區內選擇低延遲節點，再讓「關鍵業務」依香港優先、日本備援的順序運作。最外層的「節點選擇」保留手動控制入口。若香港節點整體無法使用，fallback 才會轉向日本組；若香港組內只有一個節點異常，內部的 url-test 會先嘗試切換至另一個香港節點。

常見設定錯誤與排查順序

組名或節點名稱不一致

YAML 中的名稱會依完整字串比對。「香港 01」與「香港01」是兩個不同名稱，全形空格與半形空格也可能造成引用失敗。日誌出現 proxy not found 類似訊息時，應複製節點原始名稱，而不是重新手動輸入。

縮排正確但層級放錯

proxy-groups、proxy-providers 與 rules 都是頂層欄位。若將策略組誤放在 proxies 節點內，即使文字看起來整齊，也無法正確載入。列表項目前使用兩個空格只是常見寫法，真正重要的是維持同一層級的一致性。

測速正常，但實際網站仍無法存取

先將策略切換至全域或手動節點進行測試，區分規則問題與節點問題。如果手動節點可以存取，而規則模式失敗，應檢查規則順序。Clash 規則會由上至下比對，較早出現的 DOMAIN、DOMAIN-SUFFIX、規則集或 GEOIP 可能已將請求送往其他策略組。

TUN 模式下的結果與系統代理不同

系統代理只會接管遵循系統代理設定的應用程式；TUN 模式則透過虛擬網路介面接管更廣泛的流量。切換至 TUN 後，終端機程式、遊戲或獨立更新程式可能開始進入 Clash，策略組負載也會隨之變化。排查時應記錄目前模式、DNS 設定與目標程序，避免將流量入口變化誤判為策略組故障。

修改訂閱後設定被覆蓋

直接編輯由遠端訂閱產生的設定檔，下一次更新時可能恢復為訂閱的原始內容。長期使用的自訂策略應放入用戶端支援的覆寫、合併或腳本處理機制中。調整前可先複製一份本機設定檔進行測試，確認策略組、規則引用與提供者篩選都能正常載入，再遷移至持續維護的方案。

選擇結論：依目標而非名稱決定

網頁瀏覽、搜尋與遠端互動優先考慮 url-test，並使用 50 至 150 ms 的 tolerance 減少波動。
主線路必須優先，只有發生故障時才切換至備援線路，請使用 fallback；節點排列順序就是業務優先級。
工作包含大量獨立連線，且希望分散至多個節點時，使用 load-balance；登入狀態敏感時，優先選擇一致性雜湊。
單一連線速度緩慢時，不要依賴負載平衡疊加頻寬，應分別檢查節點容量、協定開銷、本機網路與目標伺服器的限速。
無論採用哪一種自動組，都要同時檢查規則指向、健康檢查網址、核心相容性，以及訂閱更新後的節點名稱。

實際設定可以從包含 3 個節點、每 300 秒檢查一次的簡單組開始，觀察一天內的延遲、切換次數與日誌，再逐步調整。先釐清是追求最低延遲、優先確保可用性，還是分散並行連線，通常就能在三種策略組之間做出正確選擇。