Clash 分流裡 URL-Test 與 Fallback 怎麼寫：
自動測速選節點與主節點掉線切換

1 策略組在幫您做什麼：select 以外的兩條路

在 Clash 系設定裡，proxy-groups 把多個節點（或子群組）打包成一個可被規則引用的名字。最常見的是 select：完全由您手動選；進階需求則是 url-test 與 fallback。url-test 會對清單內節點定期發起延遲測試（對您指定的測速網址做連線／取得延遲），挑出目前延遲最低者作為當前出口。fallback 則不重排延遲，而是依照您在 proxies 陣列中的由上而下順序，找到第一個「健康」的節點；當目前節點被判定失敗或逾時，就往下切換，實現故障轉移。

兩者都能減少手動切換，但解決的痛點不同：若您在意「哪條線現在比較快」，優先考慮 url-test；若您在意「主線掛了要有備援順序」，優先考慮 fallback。實務上也很常把兩者巢狀組合：外層 fallback 串多個機房／多條入口，內層 url-test 在同機房內自動挑節點。若您的訂閱仍是通用格式，可先完成訂閱轉換再回來改策略組，會比較不會遇到「有規則卻沒節點名稱」的錯位。

記住一句話：規則引用的是「策略組名稱」，不是單一節點暱稱。改名、emoji、訂閱更新導致節點改名時，都要確認 rules 與 proxy-groups 仍對得上。

2 url-test：自動選節點與關鍵參數

url-test 類型的策略組至少需要：name、type: url-test、proxies（節點名稱清單，順序僅作為同延遲時的預設優先，實際仍以測得延遲為主）、以及 url（測速目標）。常見寫法會對 http://www.gstatic.com/generate_204 或機場建議的測速位址發請求；重點是該網址在您的網路環境下能穩定回應，且與您實際上網場景不要差太多（例如全走 TLS 的站卻用極輕量的 204，有時會出現「測速很穩、實際網站很慢」的落差）。

interval、tolerance、lazy

interval 控制多久做一次延遲測試（秒）。設太短會增加背景連線與機場負擔；設太長則切換反應慢。tolerance 用來避免「延遲在幾毫秒之間抖動就頻繁換節點」：只有當新最佳節點比目前節點好超過容差，才會切換。lazy 若為 true，代表未被規則命中前可能不做完整測速（依核心版本與用戶端行為略有差異），有助省電與減少連線，但若您希望一啟動就備好最佳節點，可評估改為 false 或接受首次命中時才完整測試。

# Example — replace proxy names with your subscription names
proxy-groups:
  - name: AUTO-BEST
    type: url-test
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

3 fallback：故障轉移與順序思維

fallback 類型同樣需要 url 作為健康檢查依據，並透過 interval 定期複查。與 url-test 最大的差異是：它不會因延遲較低就換到清單後面的節點，而是盡量維持清單最上方可用者；只有當目前節點不健康時，才往下找。因此請把最想當主線的節點放在最上面，備援依信任度往下排。部分核心還支援 timeout 等欄位（依版本文件為準），用於定義「多久算掛了」。

proxy-groups:
  - name: FAILOVER
    type: fallback
    proxies:
      - 主線-香港
      - 備援-日本
      - 備援-新加坡
      - DIRECT
    url: http://www.gstatic.com/generate_204
    interval: 300

上例最後放入 DIRECT 代表「代理全掛時仍允許直連」；是否適合取決於您的分流哲學與風險承受度。若您希望代理失敗時寧可斷線也不要洩漏真實 IP，就不要把 DIRECT 放進備援鏈，改以純代理節點或封鎖規則處理。這類取捨也與 DNS 解析是否一致有關，建議一併參考Meta 核心 DNS 與 FakeIP的整體設定思路。

4 實務組合：外層 fallback、內層 url-test

當您同時有「多條機場線路」與「每條線底下多節點」時，巢狀策略組很常見：例如先以 fallback 固定優先使用某一訂閱或某一地區池，再在該池內用 url-test 自動挑延遲最低者。YAML 裡只要讓外層 proxies 列出另一個策略組的名稱即可（子群組須先定義或至少在解析順序上可被核心理解；實務上建議把被引用的群組寫在上方，避免部分工具排序不當）。

proxy-groups:
  - name: POOL-HK
    type: url-test
    proxies:
      - HK-1
      - HK-2
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 30

  - name: POOL-JP
    type: url-test
    proxies:
      - JP-1
      - JP-2
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 30

  - name: PROXY
    type: fallback
    proxies:
      - POOL-HK
      - POOL-JP
    url: http://www.gstatic.com/generate_204
    interval: 600

如此一來，規則只需寫 MATCH,PROXY 或將特定網域指向 PROXY，不必在每次訂閱更新後重新手動挑節點。若您使用社群規則集（例如 ACL 類），可一併閱讀ACL4SSR 與 Rule Provider，確認最終 rules 指向的策略組名稱與本文自訂的 PROXY 一致。

5 讓規則命中策略組：命名與模式

寫好 proxy-groups 後，請在 rules 尾端或適當位置，把需要走代理的流量指向您的群組名稱（上例為 PROXY 或 AUTO-BEST）。若 mode 是 rule，規則才會生效；誤設成 global 會讓您以為「策略組壞掉」，其實是模式覆蓋了分流。另請確認圖形用戶端沒有另外覆寫「系統選中的節點」而與 YAML 不一致——多數用戶端會以您最後儲存的設定檔為準，但仍有少數場景會快取舊群組狀態，遇到異常可先重新載入設定或重啟核心。

桌面環境若尚未安裝用戶端，可先參考Clash Verge Rev Windows 安裝教學完成匯入，再把本文片段貼入自訂設定或合併至訂閱產生的檔案。記得備份原始檔，並在每次合併後檢查縮排是否仍為兩空白或四空白的一致風格，YAML 對縮排錯誤非常敏感。

6 常見坑與建議除錯順序

• 節點改名導致策略組空白：訂閱更新後 emoji 或前綴變動，proxies 內字串對不上就會載入失敗。請以用戶端實際節點清單為準重新貼名稱。
• 測速網址被擋或 DNS 污染：延遲全顯示逾時或極大值時，先換一個可信的 url，並確認 DNS 與規則沒有讓測速請求誤走直連到無法存取的目標。
• tolerance 設太小：節點頻繁跳動、體感「斷一下又連上」，可適度放寬容差或拉長 interval。
• 把 url-test 當「永遠最快」：它只反映對單一測速 URL的延遲，與您實際瀏覽的網站路由可能不同；若某站特別慢，仍要回到規則與 DNS，而不是只調策略組。
• fallback 順序與預期相反：記住「越上面越優先」，不是越下面越優先；與 url-test 的「挑最低延遲」邏輯不同，請勿混用概念。

7 總結

Clash URL-Test 與 Fallback 是 proxy-groups 裡最能改善「日常懶得切節點」的兩種型態：前者用延遲測試達成自動選節點，後者用健康檢查與固定順序達成故障轉移。把 url、interval、tolerance、lazy 調到符合您網路環境與機場特性，並讓 rules 穩定指向同一策略組名稱，就能與訂閱、規則集、DNS 設定環環相扣。相較手動點選，結構化的策略組更利於長期維護，也更接近「匯入後就讓核心幫您決定出口」的理想體驗。

若您尚未選定桌面用戶端或需要跨平台一致的安裝包，建議從本站下載頁取得與站內教學對齊的版本，再將本文 YAML 片段合併進您的設定。相比僅依賴圖形介面逐次點選，先把策略組想清楚，往往能一次解決大半「換節點很煩」的問題。

→ 立即免費下載 Clash，體驗策略組與規則分流一氣呵成