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

先依需求選組：低延遲、固定優先順序或分攤連線

url-test 會在可用節點中依探測延遲選路；fallback 會依設定順序選擇第一個可用節點；load-balance 則依指定演算法分配不同連線。三者都能使用健康檢查，但「檢查節點是否可用」和「決定連線交給哪個節點」是兩回事。不能只因為有自動探測，就把它們都當成自動選最快節點。

類型	選擇依據	適用需求	主要限制
`url-test`	探測 URL 的延遲與切換容許值	日常瀏覽，自動選擇回應較快的節點	探測延遲不等於下載頻寬
`fallback`	候選順序與可用狀態	固定主要線路，故障時切換至備援	排在後面的低延遲節點不會優先使用
`load-balance`	雜湊或輪詢等分配演算法	將多條連線分配至不同節點	不會將單一連線的頻寬合併成多節點頻寬

例如三個節點的探測結果分別為 HK-A 90ms、HK-B 65ms、JP-A 130ms。自動測速組在符合切換條件時會傾向選擇 HK-B；故障切換組若依 HK-A、HK-B、JP-A 排列，仍會使用狀態正常的 HK-A；負載平衡組則可能讓不同目的地經由不同節點連線。這些數值僅用來說明選路方式，不代表實際線路測試結果或速度保證。

url-test 設定：用 tolerance 限制小幅延遲波動

url-test 會透過候選節點連線至指定 URL，並以請求耗時作為選路依據。這不是直接對節點伺服器執行一次 ICMP ping；結果會受到節點握手、出口線路、目標網站及連線重複使用等因素影響。因此，測試網址應保持穩定，最好也能代表實際連線方向。

proxy-groups:
  - name: 自動測速
    type: url-test
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

先搞懂三個參數的單位

interval: 300：探測間隔為 300 秒，也就是 5 分鐘，不是 300 毫秒。
tolerance: 50：切換容許值為 50 毫秒，用來減少延遲小幅波動造成的切換，不是請求逾時時間。
lazy: true：啟用延遲探測；策略組未使用時，週期性探測可能會暫停。這不代表應用程式的每個請求都會先進行測速。

假設目前節點延遲約 90ms，另一個節點約 65ms，兩者只差 25ms。設定 50ms 容許值後，不應預期策略組會立刻切換到後者。若另一個節點降至約 30ms，才較符合觸發切換的條件。實際選擇也取決於目前節點是否正常、探測結果是否更新；若目前節點已無法使用，也不能把容許值解讀為必須繼續保留故障節點。

日常使用可先從 300 秒探測間隔、50ms 容許值開始觀察。將間隔縮短至 5 秒，通常只會增加探測請求、喚醒行動網路並加重伺服器負擔。將容許值設為 0，則可能因幾毫秒的差異而頻繁改變後續連線的出口。需要維持連線穩定時，應先減少不必要的切換，而不是一味追求面板上最小的數值。

fallback 設定：節點順序就是優先順序

fallback 的核心不是「誰比較快就用誰」，而是「從上到下，第一個正常的節點是誰」。主要線路正常時，即使備援線路延遲更低，也不會因此取代主要線路。適合重視固定地區、固定出口或費用優先順序的情境。

proxy-groups:
  - name: 主備線路
    type: fallback
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

HK-A、HK-B 都正常：優先選擇 HK-A。
健康檢查確認 HK-A 無法使用、HK-B 可以使用：後續連線改用 HK-B。
後續檢查確認 HK-A 恢復正常：策略組會重新優先選擇 HK-A。

這裡所說的「恢復」是以健康檢查結果為準。300 秒的檢查間隔不代表所有故障都能在一秒內切換，也不代表一定要等滿 300 秒：手動測試、用戶端觸發方式及核心實作都會影響狀態更新。進行中的 TCP 連線也不會自動轉移至備援伺服器；已中斷的下載、SSH 或視訊連線仍需由應用程式重新連線。

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

load-balance 會將連線分配至多個正常節點。它不是逐一輪流傳送資料封包，也不會自動將三條 100Mbps 線路合併成一條 300Mbps 隧道。單一 TCP 連線仍會經由選定的節點傳輸；應用程式建立多條連線時，才可能看到多個節點同時承載流量。

proxy-groups:
  - name: 連線分攤
    type: load-balance
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

consistent-hashing 和 round-robin 該怎麼選？

consistent-hashing：根據目標資訊進行一致性雜湊，傾向讓同一目標使用相同出口。實際使用的雜湊鍵會受核心實作及是否取得網域資訊影響，不能解讀為所有帳號工作階段都會永久綁定。
round-robin：以輪詢方式分配連線。想觀察多條連線的分攤效果時可使用，但同一網站的不同連線可能會經由不同出口。

需要輪詢時，只要將範例最後一行改成 strategy: round-robin，不必重寫整個策略組。不要只用「開啟一個下載工作是否變快」來判斷負載平衡有沒有運作；更直接的做法是在用戶端連線清單中查看多個目的地及多條新連線實際使用的代理鏈。

即使使用一致性雜湊，同一個網頁也可能同時連線至登入、圖片、API、驗證碼等多個網域，這些網域不保證會分配到同一節點。涉及地區限制、帳號安全或來源 IP 一致性的服務，不適合直接使用跨地區負載平衡。節點集合或健康狀態改變時，原有的對應關係也可能重新分配。

巢狀 select 組：保留手動切換入口與規則出口

自動策略組通常不需要直接承接所有流量入口。較容易維護的架構是由外層 select 選擇工作模式，內層則分別負責自動測速、主備切換與連線分攤。遇到探測異常時，可直接在用戶端介面切換至特定節點，不必臨時修改策略組類型。

以下是整合範例，可取代前面三個獨立片段。每個候選名稱都必須能對應到現有節點或已定義的策略組；不要讓「代理出口」反過來成為其子組的候選項目，否則會形成循環參照。

proxy-groups:
  - name: 代理出口
    type: select
    proxies:
      - 自動測速
      - 主備線路
      - 連線分攤
      - HK-A
      - HK-B
      - JP-A

  - name: 自動測速
    type: url-test
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 主備線路
    type: fallback
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

  - name: 連線分攤
    type: load-balance
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

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

若節點來自 proxy-providers，可在支援的策略組中使用 use 引入現有 provider，而不是將 provider 名稱填入 proxies 當成節點。也請檢查 provider 的 health-check：provider 節點的健康檢查必須在對應的提供者端正確設定，不能只看到策略組寫了 url，就認定所有來源節點都已依預期完成探測。

訂閱更新可能會覆蓋直接修改的設定。修改前請先備份，再確認用戶端提供的是本機覆寫、設定合併，還是臨時編輯入口。這裡說明的是核心 YAML 結構，不能假設不同用戶端都有完全相同的「設定」選單。基本匯入步驟請參考入門指南，規則與 DNS 的關係可參閱進階設定。

套用後依四個步驟驗證，避免「策略組在切換，流量卻沒變」

確認設定已成功載入。重新載入後，先查看錯誤紀錄。節點名稱大小寫、縮排錯誤、不支援的策略類型或重複的頂層鍵，都可能導致新設定未生效。若介面仍顯示舊的策略組，應先排除載入問題。
確認模式與規則是否命中。在 Proxies 查看外層策略組目前選擇的項目，在 Rules 核對目標規則，再從 Logs 或連線詳細資訊確認最終連線路徑。只有使用規則模式時，才會依 rules 分流；全域模式可能會略過為特定網域設計的入口。
手動測試並記錄結果。手動觸發策略組測試，記下時間、URL、節點延遲及最後選定的節點。比較前後結果時請使用相同的測試網址，避免把不同目的地的延遲當成同一項指標。
建立新連線再確認一次。策略組切換後，舊連線可能仍使用原本的節點。請發出新的命令列請求，或結束測試應用程式的連線後再試，接著查看代理鏈；不要只憑重新整理頁面後的主觀速度判斷。

用 curl 排除瀏覽器連線重複使用的影響

假設本機 HTTP 或 mixed 代理監聽於 127.0.0.1:7890，即可執行以下命令。連接埠請以用戶端目前的設定為準；若 7890 是純 SOCKS 連接埠，就不能直接照抄 HTTP 代理通訊協定的寫法。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --head https://example.com/

Windows PowerShell 可將命令開頭改為 curl.exe，避免部分環境中的命令別名差異。這項請求會套用前述 example.com 範例規則，可搭配紀錄確認流量是否經過「代理出口」。它只能驗證該目標的請求路徑與回應，不代表所有網站、UDP 流量或 TUN 接管都正常。

若啟用 TUN，連線可能會由虛擬網卡接管，但最後使用哪個策略組，仍由工作模式與規則決定。啟用 TUN 不會讓 fallback 變成測速組，也不會讓 load-balance 自動具備合併單一連線頻寬的能力。

常見異常：先確認探測結果，再調整參數

測速全都 timeout，但部分網站仍可開啟

這通常表示「測試 URL 無法連線」和「所有服務都無法連線」沒有區分清楚。請先檢查測試網址的 DNS、TLS 及節點出口連線狀況，再換成確實能回傳小型回應的 HTTPS 網址交叉驗證。不要把需要登入、會出現跳轉驗證或可能遭到限流的服務首頁，當成長期健康檢查端點。

url-test 一直停留在舊節點

先確認策略組是否正在使用、延遲探測是否影響更新，以及延遲差距是否超過 tolerance。再檢查目前的連線是否早已建立。面板顯示另一個節點快 10ms，而容許值為 50ms，並不代表設定故障。只有在探測結果已更新、延遲差距明顯，且新連線仍不符合預期時，才繼續檢查核心版本與策略組引用關係。

fallback 沒有選擇延遲最低的備援節點

這是依順序優先選擇的正常結果。若希望主要節點故障後，從備援節點中挑選速度最快的線路，可將一個 url-test 組放在主備組的備援位置，再透過實際連線驗證巢狀選擇結果。巢狀組會增加狀態判斷的複雜度；只有兩三條線路時，先採用扁平架構會更容易找出問題。

使用負載平衡後，網站反覆要求重新登入

先將該網站單獨分流至固定節點或手動選擇組，觀察新的工作階段是否恢復穩定。只把輪詢改成一致性雜湊未必足夠，因為網站可能會透過多個網域共同驗證地區與 IP。先處理工作階段問題，再評估是否仍需要為這類服務分攤連線。

選擇原則：日常瀏覽可先使用容許值適當的 url-test；需要固定主要線路時使用 fallback；只有明確需要分攤多條連線時才使用 load-balance。在三者外層保留一個 select，再搭配規則命中、健康檢查與新連線紀錄進行驗證，比反覆調整測速間隔更容易找出原因。