Clash 策略組怎麼選？比較 url-test、fallback、load-balance 參數與適用情境

三種策略組：依延遲、順序或連線分配

Clash 策略組負責決定「規則命中後要使用哪個出口」。規則會將連線交給特定群組，再由群組從候選節點中選擇出口。將策略組改為自動測速，不會自動修改網域規則，也不會讓原本走 DIRECT 的連線改走代理。

url-test 適合自動選擇探測延遲較低的出口；fallback 適合維持明確的主要與備用順序；load-balance 則適合將不同連線分配到多個出口。三者並非效能等級之分，應依照服務對延遲、出口穩定性及多線利用率的需求選擇。

url-test：用 tolerance 控制切換頻率

url-test 會透過候選節點向指定的檢測網址發出請求，再依探測結果選擇出口。這不是 ICMP ping，也不是頻寬測試。檢測耗時會受到代理連線、目標網站回應及網路狀況影響，因此比較候選節點時，應使用相同的檢測網址。

基本設定與參數單位

以下是設定片段，並非完整訂閱內容。假設目前設定的 proxies 已定義「香港-01」、「香港-02」和「日本-01」三個節點；套用時請換成現有節點的正確名稱。請勿再新增第二個頂層 proxy-groups，應將項目合併至現有清單。

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

• url：用於健康檢查的 HTTP 或 HTTPS 網址。此處使用回應內容較小的檢測端點，請勿改成需要登入的服務頁面。
• interval: 300：每 300 秒定期探測一次，也就是 5 分鐘；不是 300 毫秒。
• tolerance: 50：切換容差為 50 毫秒，避免候選節點只有些微優勢時頻繁切換。
• lazy: false：即使暫時沒有使用該群組，也會持續定期檢測，方便觀察及比較；代價是檢測請求會增加。

容差不是延遲上限

以下用一組假設數據說明：目前節點延遲為 180 毫秒，另一個節點為 155 毫秒，差距只有 25 毫秒。容差設為 50 毫秒時，不應預期每次都會切換到後者。若另一個節點降至 100 毫秒，差距擴大，才比較符合切換條件。實際選擇仍取決於當次檢測結果及節點可用狀態。

tolerance 不代表「超過 50 毫秒就無法使用」，也無法保證線路延遲始終低於某個數值。日常瀏覽可先設定 300 秒間隔與 50 毫秒容差，觀察使用情況。若出口仍頻繁變動，請先檢查節點品質與檢測目標，再考慮調高容差；不要只把檢測間隔縮短到幾秒。

fallback：依清單順序維持主備關係

fallback 會優先使用清單中排序較前且通過健康檢查的節點，不會從所有節點中挑選延遲最低者。即使第二個節點測得 80 毫秒、第一個節點為 160 毫秒，只要第一個節點仍被判定可用，主備群組就會優先使用第一個節點。

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

此處的「香港-01」是首選，「日本-01」是第一順位備援，「香港-02」是第二順位備援。若服務需要固定地區，就只應加入符合地區要求的節點。將不同地區的節點混在備援清單中，雖可能提高可用性，卻也可能造成服務地區、語言或登入風控狀態改變。

故障切換不等於工作階段移轉

• 檢測有時間差：間隔設為 300 秒，不代表故障發生後會立即切換；實際偵測時間也會受到檢測時機、逾時設定及連線觸發行為影響。
• 主要節點可能切回：排序較前的節點恢復可用後，後續連線可能會重新使用該節點，不會永久停留在備援節點。
• 既有連線不會自動轉移：原節點失效後，傳輸中的連線可能中斷，並由應用程式重新連線；策略組不提供 TCP 工作階段移轉。

遠端管理、持續上傳等工作通常更重視固定出口，可優先考慮手動 select 或順序明確的 fallback。但若工作完全不能接受出口變更，自動主備也無法取代應用程式本身的重新連線、續傳及工作階段復原機制。

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

load-balance 會讓多個候選出口參與連線分配，但不會將單一 TCP 連線拆成兩部分交由不同節點處理。因此，單一連線下載不會因為加入三條線路就自動提升為三倍速度。多工作、多目標瀏覽是否能受益，還取決於分配策略、各線路容量及目標網站的限制。

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

一致性雜湊通常會依目標網域的主網域部分進行映射；目標為 IP 時，則會依相應的位址資訊處理。實際行為請以所用核心的實作為準。它無法保證同一帳戶關聯的所有網域都使用相同出口。登入、付款及 API 網域可能分別映射，節點清單變更也可能改變映射結果。

若要輪流分配，請將範例中的策略改為 strategy: round-robin。請勿將輪詢理解為「平均分配每個請求」：多個 HTTP 請求可能共用同一條 TCP 或 QUIC 連線，而連線分配不等於請求分配。付款、帳戶管理等服務較適合使用固定出口，不宜只為了利用多條線路而強行負載平衡。

規則套用：讓連線實際進入自動策略組

定義策略組只是第一步。若規則仍指向舊群組，新增的群組就不會處理對應連線。以下以手動選擇群組作為總入口，保留三種自動策略及直連選項，方便在用戶端中比較實際行為。

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

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

此處僅示範入口項目與規則，須與前述自動群組定義合併使用。example.com 是用於示範規則匹配的保留範例網域，並非實際服務網址。MATCH 會接收此前未匹配的連線；正式設定中請保留既有的區域網路、直連及服務規則，並將兜底規則放在最後。請勿以此精簡片段覆蓋整份分流設定。

1. 先在用戶端的設定編輯頁面或覆寫功能中合併設定，並檢查 YAML 縮排；清單項目請使用空格，不要使用 Tab。
2. 重新載入設定，確認三個自動群組與「代理入口」都已出現，且沒有「代理不存在」或策略組循環參照錯誤。
3. 在代理群組頁面展開「代理入口」，選擇要測試的自動群組，不要停留在原本的手動節點。
4. 建立一條新的連線，在連線清單中查看命中的規則與代理鏈，確認最終出口符合預期。

檢測結果偏差：延遲、DNS 與 TUN 的限制

測速正常，服務仍無法使用

檢測網址可連線，只能表示該線路成功存取這個檢測目標，無法證明所有網站都能正常使用。服務可能因出口地區、目標網站封鎖、憑證問題或 DNS 解析異常而失敗。遇到這類情況，請先將入口固定到單一節點，重新測試目標服務並查看連線記錄，不要直接認定是自動群組演算法出錯。

HTTPS 檢測也可能包含建立連線及 TLS 交握所需的時間。在 mihomo 中，頂層的 unified-delay 可減少不同代理交握差異對延遲比較的影響；它不是策略組的欄位。比較數據時，應保持設定、檢測網址及測試網路一致，不能直接排列測試條件不同的結果。

TUN 不會改變策略組的選擇演算法

系統代理或 TUN 決定流量如何進入核心，規則決定流量交給哪個群組，策略組則決定出口。啟用 TUN 不會讓 fallback 自動選擇最低延遲節點，也不會讓 load-balance 具備頻寬聚合能力。若某個應用程式的連線沒有出現在核心連線清單中，應先排查流量接管路徑，而不是修改 tolerance。

使用 Fake-IP 時，核心可透過位址映射保留網域匹配資訊，但這無法取代策略組的健康檢查。若節點伺服器本身使用網域名稱，也要確保其解析路徑正常，避免代理連線依賴必須透過代理本身才能完成的 DNS 請求。DNS 故障可能導致所有自動組節點都逾時，請搭配 DNS 記錄找出問題。

參數設定：從保守設定開始驗證

初次設定可統一使用 interval: 300，排查時設為 lazy: false，確認行為正常後，再依裝置續航力與節點數量調整。若一個群組有 12 個節點，假設每個節點每輪至少探測一次，5 分鐘一輪約每小時會有 144 次檢測；實際請求數也會受到額外探測、重試及手動測速影響，不能直接視為流量帳單。

• 優先追求低延遲：選擇 url-test，先設定 50 毫秒容差，觀察新連線的出口是否變動過於頻繁。
• 優先使用主要線路：選擇 fallback，將真正希望優先使用的節點排在第一位，並確認備援節點的地區與用途。
• 讓多條線路共同分流：選擇 load-balance，先試用一致性雜湊；只有在服務允許出口變動時，才使用輪詢。
• 優先維持工作階段穩定：保留 select 手動入口，為登入、付款及長時間工作指定穩定節點。

驗證時一次只調整一個變數：先固定節點與檢測網址，再更換策略類型，最後調整間隔與容差。至少觀察兩個完整檢測週期，並分別測試新連線、持續下載及實際服務頁面。選擇結果、服務成功率與連線穩定性，比單次測速清單中最低的數字更能判斷設定是否適合目前的網路。