進階設定 閱讀時間約 12 分鐘

Clash 策略組設定教學：url-test、fallback、load-balance 差異

掌握 url-test、fallback 與 load-balance 的選擇邏輯及 interval、tolerance 等參數，依延遲、穩定性或連線分配需求設定策略組。

三種自動策略組怎麼選

Clash 策略組負責從多個出站中選擇路線，規則則決定連線要進入哪個策略組。兩者屬於不同層級：即使自動組設定正確，若規則將連線導向 DIRECT，該連線仍不會使用組內節點。本文以 mihomo（原 Clash Meta）的設定語法為準；其他核心或較舊版本支援的參數可能不同，編輯前請到用戶端的「關於」或核心資訊頁確認實際使用的核心。

先依需求選擇類型：想要較低延遲，選用 url-test；希望主線路可用時持續使用主線路，選用 fallback；希望將不同連線分配到多個出口，選用 load-balance。三者都能偵測可用性，但採用偵測結果的方式不同。

類型 選擇依據 適用情境 主要限制
url-test 比較候選出站到測試網址的延遲，並依容差選擇。 日常瀏覽、自動選擇同一地區的較佳節點。 測得延遲低，不代表大型檔案下載速度快。
fallback 依清單順序選擇第一個可用的出站。 主備線路、優先使用指定地區。 優先節點變慢但仍可用時，通常不會切換到其他節點。
load-balance 依指定的分配演算法，將連線分配到可用出站。 多項工作同時執行、分散連線負載。 不會將單一 TCP 連線拆分到多條線路來合併頻寬。

url-test 設定：自動選擇與切換容差

以下範例假設目前設定的 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: true

interval 與 tolerance 分別控制什麼

  • interval: 300：每 300 秒（也就是 5 分鐘）進行一次定期偵測，不是 300 毫秒。
  • tolerance: 50：切換容差為 50 毫秒，可減少延遲些微波動造成的頻繁切換。它不是偵測逾時時間，也不是延遲上限。
  • lazy: true：啟用延遲偵測，未使用此組時可略過定期偵測。手動測速、首次使用等行為仍會受到用戶端與核心實作方式影響。
  • url：可用性與延遲測試的目標網址。建議選擇穩定、回應內容小，且能代表目標網路路徑的網址。

例如，目前節點測得延遲為 110 毫秒，另一個節點為 95 毫秒，兩者只差 15 毫秒；若容差設為 50 毫秒，就不應預期每次都切換到數值最低的節點。容差用來抑制波動，不代表保證在特定時間切換。目前使用的節點失效時，核心也無法只根據這兩個延遲數值繼續判斷。

這組數值僅用來說明參數，並非實際線路測試結果。測試網址的 TLS 交握、網路壅塞、伺服器回應及連線重用情況都會影響測得數值。若網頁延遲低但下載仍慢，請進一步檢查傳輸速度、封包遺失及尖峰時段壅塞，不要反覆將 tolerance 設為 0 來取代問題診斷。

fallback 設定：明確指定主備順序

fallback 著重「清單中誰先可用」，而不是「誰最快」。主線路可用時，即使備援線路測得數值較低，通常仍會繼續使用主線路。適合有地區、資費或出口偏好的情境。

proxy-groups:
  - name: 主備線路
    type: fallback
    proxies:
      - 香港-01
      - 香港-02
      - 日本-01
    url: https://www.gstatic.com/generate_204
    interval: 120
    lazy: true

依照這個順序，香港-01 優先級最高，香港-02 次之，日本-01 則是最後的備援。若第一個節點無法通過測試而第二個正常，策略組就會選擇第二個；之後的偵測若發現第一個恢復可用，便會重新優先選用第一個。

自動故障切換不代表連線能無縫轉移

  • 偵測週期為 120 秒，不代表發生任何故障後都能在 120 秒內恢復；實際時間也取決於偵測是否觸發、探測耗時及應用程式本身的重試機制。
  • 節點能連上測試網址，不代表一定能存取服務網站；地區限制、目標網站封鎖或特定網站的路由異常，都可能無法透過測試發現。
  • 切換策略主要影響之後新建立的連線；已建立的下載、影片串流或 WebSocket 連線不會自動轉移到另一條線路。

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

load-balance 適合有多條連線同時進行的工作。以下使用 consistent-hashing，在候選清單穩定時，讓相同目標盡可能維持相同的出口對應。這有助於避免連上同一網站時頻繁更換出口，但不保證 IP 位址永久固定。

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

常見分配演算法怎麼選

  • consistent-hashing：依目標資訊進行一致性雜湊分配。分配結果會受到目標網域是否可見、候選節點是否變動等因素影響。
  • round-robin：以輪詢方式分配連線。這種方式較直觀，但連線數量相近不代表流量大小相近，也不保證每條線路承載相同的資料量。

例如，某個程式同時建立 8 條下載連線，負載平衡可能會將這些連線分配到不同節點；若伺服器只允許一條連線，傳輸速度仍受該連線所選線路的效能限制。瀏覽器也可能透過 HTTP/2 在單一連線上重用多個請求，因此網頁包含許多資源，也不能據此判斷流量一定會平均分配到所有節點。

網路銀行、帳戶管理及需要固定地區的服務，建議優先使用固定節點或固定地區策略。即使採用一致性雜湊，節點離線、候選清單變動或目標網域變更後，出口仍可能改變。涉及身分驗證的服務，不宜只為了「均衡」就擴大候選地區範圍。

組合策略組：依用途保留手動選擇入口

日常設定可將三種自動組放進一個 select 組：預設選擇自動選擇，需要固定優先順序時切換到主備線路，同時有多項工作時再選連線分配。以下片段應追加到現有的 proxy-groups 清單中；rules 僅為展示兜底規則的獨立範例，不能直接取代現有完整的分流規則。

proxy-groups:
  - name: 網路出口
    type: select
    proxies:
      - 自動選擇
      - 主備線路
      - 連線分配
      - 香港-01

rules:
  - MATCH,網路出口

上方的 MATCH 會接收所有到達此處且尚未符合其他規則的連線。若要保留區域網路、中國大陸網站或特定業務專用規則，請將這些具體規則放在它前面。規則通常依序由上而下比對，不能先放兜底規則，再期待後續的分流規則繼續生效。

引用的組名必須完全一致，也不能形成循環。例如「網路出口」引用「自動選擇」時，「自動選擇」就不能再引用「網路出口」。初次排查時，建議使用一層手動選擇器加一層自動組，避免過多層級的巢狀設定讓測速路徑與最終出口難以辨識。

更新訂閱後如何保留修改內容

  1. 先備份目前的設定，並記下節點名稱、組名及相關規則。
  2. 確認用戶端是否提供覆寫、合併或擴充設定的功能。直接編輯訂閱產生的檔案，可能會在下次更新時被覆蓋。
  3. 若使用 proxy-providers，可依用戶端支援情況使用 use 引用提供者；不要將提供者名稱誤當成節點名稱，放進 proxies。
  4. 更新訂閱後，請檢查節點是否重新命名、候選清單是否變動，再進行設定檢查與手動測速。

自動策略沒有生效時的排查順序

先確認設定已成功載入，再追蹤實際連線。不要同時修改 DNS、TUN、策略類型和測試網址。每次只調整一項，才容易判斷是哪個參數造成影響。

第一步：檢查 YAML 語法與引用關係

縮排請使用空格，不要使用定位字元；清單項目前保留 -；同一個檔案中避免重複定義頂層 proxy-groups。若本機已安裝 mihomo 命令列程式，可執行以下指令測試設定。指令中的檔名是目前目錄下的 config.yaml，並非要求將訂閱改成這個檔名。

mihomo -t -f config.yaml

若出現找不到代理或策略組的提示，請先修正名稱引用。通過語法檢查只代表設定能成功解析，不代表遠端節點可連線，或測試網址運作正常。

第二步：確認流量是否進入目標組

在用戶端的連線清單中搜尋目標網域，查看命中的規則、策略鏈及最終節點。系統代理通常只會影響讀取該設定的應用程式；TUN 則透過虛擬網卡接管符合條件的流量。兩者都不會改變 fallback 的優先級演算法。若應用程式的流量未進入核心，調整策略組參數也無法改變該應用程式的出口。

若設定中確實有 mixed-port: 7890，可以使用以下指令明確透過本機代理請求網頁。此處的 7890 是範例監聽連接埠，請確認與實際設定一致；不要誤用外部控制介面的連接埠。

curl -x http://127.0.0.1:7890 -I https://example.com

第三步：分辨測速異常與服務異常

  • 所有節點都顯示逾時：先檢查本機網路、節點憑證及測試目標是否可連線，不要立刻認定所有線路同時失效。
  • 自動組測得到延遲，網站仍無法開啟：檢查目標網站的 DNS、規則比對結果及連線記錄，確認問題是否只發生在該網站。
  • 幾分鐘內反覆切換：先維持使用同一個測試網址，再適度提高 url-test 容差，例如從 20 毫秒調整至 50 毫秒，並觀察後續偵測結果。
  • 切換後舊工作沒有變化：請建立新連線再試。必要時只關閉相關連線，避免直接中斷所有進行中的工作。

選擇原則可以很簡單：優先考量延遲就選 url-test，優先遵循順序就選 fallback，需要分配連線則選 load-balance。再用規則明確指定流量入口，並保留可手動選擇的出口，通常比堆疊多層自動組更容易維護。完整語法可參閱本站的協定手冊；首次設定可先閱讀安裝與設定教學。

下載Clash