Clash 策略組教學：url-test、fallback、load-balance 差異與選擇指南

三種策略組：先看選路目的

日常瀏覽想自動選擇低延遲節點，使用 url-test；主線穩定、備援線路只在故障時接手，使用 fallback；想將不同連線分配到多個節點，則使用 load-balance。三者都屬於 proxy-groups，但選擇依據不同，不能只看用戶端是否標示「自動」。

策略組負責決定使用哪個出口，不會自動讓應用程式流量進入 Clash。系統代理或 TUN 負責接管流量，規則模式則由 rules 將連線導向指定策略組。如果規則最後指向 DIRECT，調整這些組的測速參數也不會改變該連線的路徑。

url-test：依延遲選路，用 tolerance 降低切換頻率

url-test 會透過候選節點向測試網址發出請求，並依結果自動選擇節點。測得的是連線至測試端點所需的時間，不是下載速度，也不代表瀏覽所有網站的整體體驗。節點連到測試網站的路徑順暢，不代表連到影音服務或開發程式碼庫也一樣順暢。

起始參數建議：每 300 秒測試一次，容差 50 毫秒

以下是策略組定義片段，並非完整訂閱設定。範例中的「節點-A」、「節點-B」、「節點-C」必須已在現有設定的 proxies 中定義，名稱也必須完全相同。將片段合併至現有的 proxy-groups 清單即可，請勿建立重複的頂層鍵。

proxy-groups:
  - name: 自動低延遲
    type: url-test
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

• interval: 300：每 300 秒（即 5 分鐘）進行一次定期健康檢查；這不是應用程式請求的逾時時間。
• tolerance: 50：切換容差為 50 毫秒，可避免候選節點只快一點點就頻繁切換。這不是延遲上限，也不會排除延遲超過 50 毫秒的節點。
• lazy: false：即使策略組暫時未使用，也會定期檢查，方便查看測試結果；節點較多時，測試請求也會增加。
• url：選擇回應快且長期穩定可連線的測試端點。範例端點通常會回傳 HTTP 204；請勿使用需要登入、頻繁重新導向或會觸發風控驗證的頁面。

例如，在其他條件相同時，目前節點測得 120 毫秒，候選節點為 105 毫秒，兩者相差 15 毫秒，通常不足以在 50 毫秒容差下觸發切換；候選節點降至 60 毫秒時，切換才較有意義。這只是參數說明範例，並非本站實測結果，實際選擇仍應以目前核心狀態與記錄為準。

不宜只依延遲決定的工作

大型下載、長時間影音串流與遠端桌面也會受到頻寬、封包遺失與抖動影響。可先用自動策略組篩選可用節點，再於相同時段、連線至相同目標比較傳輸速度。若登入工作階段需要固定出口 IP，較適合手動選擇節點，或使用主備順序明確的策略組。

fallback：依清單順序選擇第一個可用節點

fallback 的重點在於優先順序。只要清單前面的節點通過健康檢查，就會優先使用；前面的節點無法使用時，才會改選後續可用節點。因此，主線必須排在第一個，備援線路依序排在後面。

proxy-groups:
  - name: 主線故障切換
    type: fallback
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

假設節點-A 的測試延遲為 180 毫秒、節點-B 為 75 毫秒，只要 A 的狀態仍正常，策略組就會優先使用 A。在這裡加入 tolerance，也不會讓它變成依延遲選路的策略組。若需求是「哪個節點快就用哪個」，請改用 url-test。

恢復情況與故障判定

• 主線恢復正常後，後續選路會重新優先使用主線。故障偵測與恢復取決於檢查結果及核心的觸發機制，無法保證即時完成。
• 策略組切換主要影響後續建立的連線。已建立的 TCP 連線不會轉移至新節點；原連線中斷後，應用程式通常需要重新連線。
• 測試端點可以連線，只代表該項檢查通過。若特定網站無法連線，主線仍可能被判定為正常，此時應檢查目標網站或相關規則。

對於視訊會議、遠端終端等持續連線，主備切換是故障後的恢復方式，不是無感切換機制。部署前可暫時停用測試主線，觀察新連線是否改走備援，再恢復主線並確認優先順序。測試時請勿同時修改 DNS 和 TUN 設定，否則難以判斷變化來自哪個環節。

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

load-balance 會在可用成員之間分配流量，實際分配方式取決於 strategy。它不是將單一檔案連線拆成多條線路同時傳輸的頻寬聚合工具。單一 TCP 連線仍會經由一個選定的出口；只有應用程式自行建立多條連線時，才可能使用多個節點。

proxy-groups:
  - name: 多連線分配
    type: load-balance
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashing 與 round-robin

使用輪詢時，同一網站的多條新連線也可能來自不同出口 IP。對登入風控嚴格的服務、付款頁面或要求 IP 固定的 API，不適合直接採用這種分配方式。一致性雜湊雖可減少變動，但成員健康狀態或節點清單變更時，也無法保證出口永遠固定。

如果三個節點共用同一個上游瓶頸，分配連線也不會憑空增加可用頻寬。確認效果時，應同時查看連線面板中的實際節點、目標網站的傳輸量與失敗率，而不只是確認三個成員都有測試延遲。

將自動策略組加入規則：保留手動選擇入口

三種自動策略組可以同時存在，再由一個 select 策略組決定目前使用哪種策略。如此一來，切換日常瀏覽、主備切換與多連線情境時，不必反覆編輯規則。以下片段須與前文的三個策略組定義合併，不能單獨當作完整設定載入。

proxy-groups:
  - name: 代理出口
    type: select
    proxies:
      - 自動低延遲
      - 主線故障切換
      - 多連線分配
      - 節點-A
      - DIRECT

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

這裡的 MATCH 只是示範如何在兜底規則中引用策略組，並不是完整的區域分流方案。現有訂閱通常還包含區域網路、本地網站與規則集等規則，請保留原有分流邏輯，只將需要代理的規則目標改為「代理出口」。規則會由上而下比對，過於寬泛的規則若放得太前面，後續規則就可能無法命中。

1. 先備份目前可用的設定，並確認核心能辨識三個自動策略組及其成員名稱。
2. 在用戶端的代理或策略組頁面，將「代理出口」選為「自動低延遲」等目標策略組；實際名稱與選單位置依用戶端而異。
3. 使用規則模式瀏覽測試網站，並在連線詳細資訊中確認命中的規則、策略鏈與最終節點。
4. 改選其他策略組後，建立新連線進行驗證；舊連線可能仍使用原節點，不能只重新整理一次頁面就下結論。

若要先確認應用程式是否經過代理，可依照系統代理設定步驟檢查流量接管方式，再依照延遲測試步驟查看策略組狀態。請勿以切換全域模式取代規則命中檢查。

常見設定錯誤：檢查間隔、成員來源與訂閱覆寫

將 interval 設成毫秒

interval: 300000 代表 300000 秒，不是 5 分鐘。若要每 5 分鐘檢查一次，請填入 300。也不建議為了「加快反應」直接設為 1：節點越多，請求負擔越大，而且頻繁檢查無法解決節點本身壅塞的問題。

只填入節點名稱，設定中卻沒有對應成員

proxies 引用的是已存在的節點或策略組名稱，不是訂閱連結。大小寫、空格與符號都必須一致。策略組之間也不能形成循環引用，例如「代理出口」包含「自動低延遲」，而「自動低延遲」又包含「代理出口」。

若節點來自 proxy-providers，可透過 use 引用已定義的提供者，例如 use: [訂閱節點]。「訂閱節點」必須是現有的提供者鍵名。提供者的 health-check 與策略組內的檢查屬於不同設定層，不要以為修改策略組的檢查間隔，就會同步改變所有提供者的檢查設定。

更新訂閱後，自訂策略組消失

直接編輯遠端訂閱產生的檔案，常會在下次更新時被覆寫。建議優先使用用戶端支援的覆寫、合併或擴充設定功能；各用戶端的操作方式並不相同。儲存後先檢查設定，再更新一次訂閱，確認策略組定義、規則引用與手動選擇節點的入口仍然存在。

選擇建議：依服務穩定性決定自動化程度

• 日常瀏覽與一般代理：從 url-test、300 秒檢查間隔與 50 毫秒容差開始，觀察是否頻繁切換。
• 固定主線與備援線路：選用 fallback，將主節點排在清單第一位，並實際測試斷線與恢復情況。
• 多目標、多連線工作：可考慮 load-balance，先使用一致性雜湊，再確認服務是否適合輪詢。
• 帳號工作階段與固定出口：在 select 中保留明確的節點選項；必要時將相關網域個別導向固定策略組。

策略組的目的，是讓選路方式符合實際需求，而不是讓所有情境都追求最低測速數字。先保留一份可還原的設定，每次只修改一項參數，再透過新連線確認最終出口，才能看出設定變更如何影響使用體驗。