Clash url-test 與故障轉移怎麼配？主備節點與自動切線

為什麼有了規則分流，還要學 url-test 與故障轉移？

許多讀者已能依 網域、關鍵字或 GEOIP 把流量分到「海外代理」或「特定策略組」；實務上卻常遇到兩件事：一是同一大組裡有十幾顆節點，不確定當下哪顆最適合，只能反覆手動點選；二是最愛的那一顆偶發掛點，規則明明命中代理，實際卻超時。Clash 的 策略群組（proxy-groups） 裡，除了最直覺的 select（手動挑線），url-test 與 fallback 正是用來讓「某一組出口」依延遲測速自動選節點，或依主備順序在故障時自動切線，從而減少你盯著 UI 的時間。本文與以網域為主角的依網域分流類文章不同：重心放在同一組代理決策內部如何選邊、如何備援，而不是再教一輪 DOMAIN 規則怎麼寫。

三種常見型態：select、url-test、fallback 各解決什麼？

select：成員是節點或其他策略組，由你（或訂閱內建 UI）手動切換。優點是可控；缺點是節點一多，就要自己判斷當下誰好。

url-test：核心概念是「延遲測速」。用戶端或核心會週期性對 url 指定位置發出探測（多為 HTTP/HTTPS），依回應時間在成員中選一個當下延遲較低的節點。適合可替換的同等角色節點（多個家鄉、多個中繼）——你想的是「誰快用誰」，而不是嚴格固定先後。

fallback（常稱 故障轉移）：成員有明確先後，通常從上到下優先，當前選中的成員在健康檢查中被判定失敗時，再往下遞補。典型用途是主節點＋一顆或多顆備援，或「先專用線、不行再雜湊大組」。和 url-test 最大的心智差別是：fallback 重視的是可用性與備援序位，不是單純比誰的 ping 圖最漂亮。

兩者都可能用到 url、interval 等參數，實際欄位名稱以你所用的 Clash Meta（Mihomo） 版本與訂閱產生器為準；寫好後務必在實機上觀察目前選中成員是否如預期切換。

url-test 與 fallback 何時用哪一個？

可以先用一句話自我提問：「我希望這組節點是公平競速，還是有主有備？」

若多顆都是同用途、可互換，只是品質隨時間浮動，偏向用 url-test，讓核心依探測結果挑當下較快者。
若你明確有慣用主線、便宜備線、或家裡直連與機房線的優先序，且只有在主線不穩才願意切到次選，偏向用 fallback，避免測速永遠挑到「理論上延遲低、但實際業務不穩」的節點。

實務上兩者也能巢狀：外層 fallback 保證先走商務出口，內層再 url-test 在幾顆同區節點中自動選。下面 YAML 僅示意結構，節點名稱請改成你訂閱內實際名稱。

YAML 範例：測速組與主備組

下列片段示範 最小型 可運作寫法；實機上請併入既有 proxy-groups，且勿與訂閱自動產生的同名組衝突。

proxy-groups:
  - name: AUTO_FAST
    type: url-test
    proxies:
      - 節點A-家鄉1
      - 節點B-家鄉2
      - 節點C-家鄉3
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: PRIMARY_THEN_SPARE
    type: fallback
    proxies:
      - 主用-固定出口
      - 備用-便宜線
      - AUTO_FAST
    url: http://www.gstatic.com/generate_204
    interval: 300

  - name: PROXY
    type: select
    proxies:
      - PRIMARY_THEN_SPARE
      - AUTO_FAST
      - DIRECT
      - 其餘手動可選節點

說明：AUTO_FAST 內讓幾顆可替換節點比延遲；PRIMARY_THEN_SPARE 則是先固定主用，失敗再退到備用，甚至可把整個 AUTO_FAST 當成最後一層「雜湊大組」。最外層的 PROXY 是許多訂閱慣例裡的預設代理策略名，你的規則最後 MATCH,PROXY 時，就會走這裡；若你慣用其他名稱，請一致替換。若尚未釐清規則由上到下的匹配順序，建議先讀規則分流配置詳解，再接回本文調整「組內」邏輯。

測速 URL、間隔、容差要怎麼想？

測速 URL：常見會用產生 204 回應的短網址，目的是讓延遲量測**輕量、可重複**。實務注意兩點：一是該目標在你實際節點所在國家／ASN 是否可達，否則全組都被判成差；二是若你關心的是「特定網站體感」，有時要自訂更接近業務的探測目標（在合法、合約允許範圍內），這屬於進階微調，不是本文預設。

interval：輪詢太頻仍會增加負擔與觀感上的切換抖動；太長則主線掛了之後，fallback 要較晚才偵測到。可從訂閱建議值起步，再依你網路穩定度收斂。

tolerance（多見於 url-test）：當新節點沒有比目前使用中者明顯好超過一個閾值，可以避免「每隔幾分鐘就因幾毫秒的隨機差而換邊」造成連線斷續。具體數值依實測，沒有萬能數字。

與訂閱內建組合併、巢狀與重新命名

多數商業訂閱會預先產生 🚀 手動选择、♻ 自動选择 等帶圖示名稱 的群組。你可以：

直接把自己寫的 url-test／fallback 放進既有 select 的 proxies 清單，當成其中一個選項；或
在圖形介面中把預設指向改為你的自訂巢狀組（若用戶端支援編輯策略）。

重點是單一命名來源：rules 裡引用的群組名、proxy-groups 裡的 name、以及 UI 顯示，必須能對上；重複名稱或合併訂閱時覆寫，是新手最常見的「怎麼改都不生效」原因。

規則層要怎麼接線？

自動選線发生在策略群組內部，規則層（rules）仍負責「哪一類流量進哪一個群組」。典型接法是：特定網域或 App 相關規則指向你專用組名，而廣域海外流量 MATCH 到 PROXY；PROXY 再選中內含 url-test 或 fallback 的巢狀結構。如此一來，分流邏輯與同組內選邊邏輯分層清楚，之後除錯時可以問：是「沒有進到這條規則」，還是「進了規則但組內節點切換怪」。

若你使用 TUN 模式 讓遊戲、語音等 UDP 一併走 Clash，策略組的切換行為一樣會影響體感延遲；TUN 開法與注意事項可參考TUN 模式詳解。

實測步驟：怎麼確認真的在自動切？

儲存設定並重載核心後，在客戶端首頁或策略檢視中確認目前選中成員顯示哪顆節點、是否隸屬你預期的 url-test／fallback 組。
暫停或人為斷開「主用」節點所依賴的線路，觀察 fallback 是否在數次健康檢查內遞補到備援（時間取決於 interval 與實作）。
對 url-test：可記錄切換前後的探測延遲讀數，驗證 tolerance 是否過小導致頻繁換邊、或過大導致黏在慢節點。
搭配連線日誌，確認業務流量（如瀏覽、API）與你設想的策略組名一致，避免其實命中了另一條寬規則。

⚠️

合規與帳戶風險：請在所在地法律與服務條款允許的範圍內使用代理；頻繁切換出口可能觸發部分網站的風控與帳戶驗證。本文僅討論 Clash 機制，不提供規避監管或濫用服務的指引。

常見雷區：測速不等於業務、全組 DIRECT、與 DNS

第一，測速快不等於目標網站快。探測只反映到該 URL 的延遲與可達性，實際造訪的網站可能在別洲、別 CDN。若你鎖定單一服務，有時要回到網域規則與專屬策略組，而不是只調測速 URL。第二，若 fallback 成員寫了 DIRECT，在 ISP 不穩時可能「一 fallback 就全直連」或反過來誤以為還在代理，請確認這是否符合意圖。第三，DNS 解析路徑 若與實際連線路徑不一致，可能出現規則看起來對、實機卻怪；Fake-IP 與 DNS 細節可參考Fake-IP 與 DNS 指南。更多專案名詞可從說明文件總覽切入。

另補一點與 load-balance 的差異：若你追求的是多節點分攤併連，那是另一種群組型態，與「單一最佳延遲」的 url-test 或「失敗再換」的 fallback 目標不同；多數讀者若只想先穩定上線、少手動切換，先掌握好本文兩者即可。長連線、WebSocket 或下載斷續等情境，切換太頻仍可能造成體感卡頓，此時可回到調大 interval 或容差、或讓關鍵服務走固定 select 與本組分離，避免自動策略「好心做壞事」。

結語

當你已能寫好規則，下一步要提升日常體驗，往往就是讓 PROXY 與關鍵自訂組具備 自我調節 能力：用 url-test 把「多顆可替代節點」收斂成單一決策、用 故障轉移 把主備寫成明確的先後與遞補關係。兩者加起來，比一味堆疊 DOMAIN 規則更能減少手動切換。相較於單一節點的口耳相傳，可驗證的測速間隔、容差、巢狀層次與清晰組名，才是長期可維運的配置。若你正在尋找能清楚顯示目前選中節點、並支援策略組除錯的用戶端，建議選擇介面透明、更新來源可信的版本。→ 立即免費下載 Clash，開啟流暢上網新體驗