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

三種自動策略組：先確認選擇目標

Clash 的策略組不是新的代理伺服器，而是用來選擇既有節點的設定層。規則會先決定請求進入哪個策略組，再由策略組選擇使用的節點。設定中加入自動組，不代表所有流量都會經過它；只有規則或上層選擇組引用該組，自動選擇才會影響相應請求。

三種類型都能搭配健康檢查，但選擇依據不同：url-test 著重探測延遲，fallback 著重預設順序，load-balance 著重連線分配。一般瀏覽可優先考慮前兩者；確實需要讓多個出口分擔不同連線時，再考慮負載平衡。

策略組類型	選擇依據	適用需求	主要限制
url-test	探測延遲與切換容差	在同類型節點中自動選擇延遲較低的出口	延遲低不代表下載速度快
fallback	清單中第一個健康的節點	優先使用主線路，故障時改用備援線路	不會因備援線路速度較快就主動切換
load-balance	雜湊或輪詢等分配策略	讓不同連線使用不同的可用節點	不會合併單一連線的頻寬

url、interval 與 lazy：健康檢查如何執行

url 是探測目標，不是訂閱網址

url 指定健康檢查請求要連線的網址。核心會透過候選節點向該網址發出 HTTP 探測，記錄是否成功及所需時間。它不是訂閱下載連結，也不是用來下載大型檔案的測速網址。範例使用 https://www.gstatic.com/generate_204，這是常見的輕量探測端點，但是否適用仍須視你的線路與目標網路而定。

為了公平比較，同一個策略組應使用相同的探測網址。節點連上探測網站很快，不代表存取影音網站或公司系統也很快；反之，若探測網域遭到限制，也可能讓可用線路被判定為異常。排查時應分別確認「探測失敗」與「服務存取失敗」。

interval 以秒計算，不是毫秒

interval: 300 表示每隔 300 秒，也就是 5 分鐘安排一次檢查。它不是每個請求的逾時時間，也不保證所有應用程式都能在 300 秒內察覺故障。懶惰檢測、排程時機、檢測耗時與既有連線狀態，都會影響實際效果。

一般瀏覽可先從 300 秒開始，觀察一段時間後再調整。
若希望更快發現主線路故障，可評估設為 60 秒，但檢查請求也會增加。
若有 20 個節點，每 60 秒完整檢查一輪，理論上每小時約會探測 1200 次；每 300 秒一輪則約 240 次，實際次數仍會受懶惰檢測等機制影響。

lazy 決定閒置策略組是否持續定期檢查

在支援此欄位的核心中，lazy: true 可減少未使用策略組的檢測負擔；lazy: false 則允許閒置策略組持續定期檢查。若希望備援組尚未被選用時也能維持較新的健康狀態，可以考慮關閉懶惰檢測；不過節點與自動組較多時，請留意額外負擔。這不會自動重送已經失敗的服務請求。

url-test：自動選擇低延遲節點，tolerance 控制切換

url-test 會探測候選節點，並依據結果自動選擇節點。適合節點用途相近、可接受出口變動的情境，例如數條同地區的一般瀏覽線路。若候選節點在地區、帳號風控或可存取服務方面差異很大，單靠比較延遲通常不是合適的篩選方式。

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

這三個節點名稱必須已存在於設定的 proxies 中，而且名稱必須完全一致。此範例僅為策略組片段，不包含伺服器位址、認證資訊或完整規則，不能直接當作可連線的訂閱使用。

tolerance 的單位是毫秒

tolerance: 50 表示切換容差為 50 毫秒，可降低節點因延遲小幅波動而頻繁切換的機率。舉例來說，假設目前節點測得 120 毫秒，另一個節點測得 100 毫秒，差距只有 20 毫秒，通常沒必要只為這點差異切換；若另一個節點降至 60 毫秒，改善幅度達 60 毫秒，就可能符合切換條件。以上數值僅供說明，並非本站實測結果。

容差不是延遲上限，也不是失效門檻。設定為 50 不代表延遲超過 50 毫秒的節點都會遭到排除。目前使用的節點若無法連線，也不能靠調高容差強行保留。實際的比較邊界與首次選擇行為，請以所用核心的實作為準。

頻繁切換：先確認節點是否反覆逾時，再考慮適度調高容差。
測速延遲低但下載慢：另外測試實際服務，並檢查傳輸量、封包遺失與線路壅塞。
帳號限定使用特定地區：先限制候選節點的地區，或改用手動選擇，避免混用不同地區的節點。

fallback：優先使用主線路，故障後切換至備援

fallback 會依照 proxies 清單順序尋找可用節點。第一個節點健康時，即使後面的節點延遲更低，也不會因此成為首選。它適合「主線路出口較穩定，備援線路只在緊急時使用」的需求，而不是「任何時候都選最快的節點」。

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

這個順序表示：優先使用香港線路 A；健康檢查失敗後，才考慮日本線路 A；前兩個節點都無法使用時，再改用新加坡線路 A。後續檢查確認優先順序較高的節點恢復後，新連線可以切回較前面的可用節點。因此，若主節點反覆恢復又故障，出口也可能來回切換。

故障切換不代表既有連線會遷移

一次影片播放、SSH 工作階段或大型檔案下載，通常都已建立連線。策略組切換節點後，無法將同一條 TCP 連線平順地移至另一台伺服器。舊連線可能中斷，應用程式需要自行重新連線；新的連線才會依照新的選擇建立。對即時通話或遠端終端機而言，備援線路能縮短恢復時間，但無法保證完全不中斷。

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

load-balance 會在可用節點之間分配流量。它的效益通常來自將多條連線分散到不同出口，而不是讓單一下載連線同時享有兩條線路的速度。即使應用程式支援多工下載，是否能受益仍取決於伺服器限制、分配策略、線路頻寬及應用程式本身的運作方式。

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

consistent-hashing：讓同類型目標的出口保持穩定

在 mihomo 中，consistent-hashing 通常會依照目標網域的主網域部分進行一致性雜湊；沒有可用網域名稱時，則會使用目標 IP。此策略傾向讓相同目標連到同一個節點，但不代表「一個帳號永久綁定一個出口」。可用節點集合、目標網域或其他分配條件變動時，選擇結果都可能改變。

同一個網頁通常會連線至登入、API、圖片與靜態資源等多個網域，因此「開啟同一個網站」不代表所有請求都會使用同一個出口。若是登入工作階段、付款或地區敏感服務，較穩妥的做法是讓相關網域規則指向固定節點或受控的專用策略組。

round-robin：依序分配新連線

在支援此策略的核心中，將 strategy 設為 round-robin，即可透過輪詢方式在可用候選節點間分配新連線。它不是逐個封包輪流傳送，也不保證資料量平均：一條連線可能傳輸 2 GB，另一條只有 2 KB；連線數接近，不代表流量也接近。

舊版 Clash 核心支援的 strategy 範圍可能不同，不應將 mihomo 的所有策略值直接複製到已停止維護的用戶端。遇到欄位不受支援或行為不符時，請先確認核心名稱與版本，再查閱對應文件；不要只因介面成功儲存，就認定欄位已生效。

將自動組套用至規則：設定 select 入口並完整引用

只新增 proxy-groups 不會自動取代現有規則。較方便的做法是在上層加入一個 select 手動選擇組，將三種自動組都列為選項，再讓需要代理的規則引用這個入口。如此一來，就能在介面中切換方案，不必每次重寫規則。

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

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

這段同樣是設定片段，必須與前面的自動組放在同一份設定中。example.com 僅用來示範規則語法，並非測速網站。此規則只會將該網域及其子網域交由「代理入口」處理，其餘請求則透過最後的 MATCH,DIRECT 直連；請勿將此範例誤認為適用於日常使用的完整分流規則。

先保留原有訂閱設定，並在測試副本中新增策略組，避免更新訂閱後修改內容遺失。
逐一核對節點名稱、策略組名稱與規則引用；大小寫、空格及中文字都必須完全一致。
整份設定只保留一個頂層 proxy-groups 和一個頂層 rules，將清單項目合併進去，不要重複貼上頂層鍵。
在 Clash for Windows 的 Profiles 中選取測試設定，接著前往 Proxies，使用 Rule 模式並展開「代理入口」，選擇要測試的自動組。
若使用 Global 模式，流量會改由全域策略處理，原有規則引用便不再決定流量去向；使用 Direct 模式也無法驗證自動組在日常分流中的效果。

若要長期保留修改，應使用目前用戶端支援的覆寫、Mixin 或設定合併機制，並檢查最後產生的執行設定。不同用戶端處理陣列的方式可能是取代或合併，不能假設追加幾行就一定能保留訂閱中的所有組。

自動策略組未生效：四步驟排查

第一步：確認核心接受設定

查看 Logs 是否出現 YAML 解析失敗、節點不存在或策略值不受支援等訊息。YAML 使用空格縮排，不可使用 Tab；proxies 下的每個清單項目都必須對齊。節點名稱若含有冒號後接空格等特殊組合，建議以引號括住整個名稱。

第二步：分別測試節點與探測網址

先手動選取單一節點，連線至實際目標，再執行組內延遲測試。如果只有某個探測網址失敗，應檢查該網址是否可連線及 HTTPS 交握狀況，而不是立刻刪除所有節點。若節點本身無法連線，調整 tolerance 或更換負載平衡演算法，也無法解決認證、伺服器或網路故障。

第三步：確認請求實際套用的策略

在 Connections 中查看新請求使用的規則與代理鏈，確認流量確實經過目標策略組。若請求符合較前面的直連規則，或應用程式未經過用戶端，自動組自然不會發揮作用。瀏覽器能使用代理、其他應用程式卻不行時，也要檢查系統代理、應用程式的獨立代理設定或 TUN 接管範圍；策略組無法取代流量接入設定。

第四步：以新連線確認變更

切換策略組或等待檢查完成後，重新發出請求，避免持續觀察舊連線。測試 fallback 時，可在受控環境中暫時讓主節點無法連線，記錄檢查時間、首次失敗時間與恢復時間；測試 url-test 時，應記錄多輪延遲，不要只比較單次結果。測試 load-balance 時，請觀察多條連線的代理鏈，而不是只重新整理一個可能重用連線的頁面。

一般瀏覽：搭配同地區節點使用 url-test，先從 300 秒間隔、50 毫秒容差開始評估。
固定主線：使用 fallback，依業務優先順序排列，並確認主線恢復後的切換狀況。
多連線工作：確認可接受出口變動後再使用 load-balance，並分別測試雜湊與輪詢策略。
敏感工作階段：優先使用固定節點或專用選擇組，不要完全仰賴自動延遲比較來維持出口穩定。

選擇策略組的關鍵不在於哪一種「比較進階」，而在於要改善什麼：延遲、主備順序，還是連線分配。先限定候選節點，再設定檢查參數，最後以實際服務驗證，通常比一再縮短檢查間隔更有效。