這篇適合誰：已裝好 Verge Rev，想把手動選節點與「自動容錯」分開處理

Clash Verge Rev 在 Windows 11 上把 Mihomo（Clash Meta 系譜）包成桌面程式後，新手最容易把三種體感相似的東西混在同一個抽屜：手動 selector、自動測延遲的 url-test、以及本篇要談的 fallback。你若曾在搜尋框打過「Clash Verge Rev fallback」「fallback group」「health-check」或「延遲測試怎麼略過壞節點」，卻發現教學多半在講延遲排行，那正好：本篇把 fallback 策略組從 url-test 文脈裡獨立拉出來，鎖定清單順序優先＋健康檢查這條邏輯，並給你可照做的介面／YAML 對照與自檢順序。

閱讀前預設你已能載入訂閱、看到節點名稱、規則能帶你到某個策略組。若仍卡在匯入或 SmartScreen，請先到 訂閱匯入教學與 Windows 11 安裝與訂閱；想先建立 Verge 全局面貌可讀 Clash Verge Rev 總覽。已熟悉內建延遲面板、但想補齊「fallback 與 url-test 差異」者，可交叉對照 Win11 策略組與延遲測試。

版面差異：不同版本的 Clash Verge Rev 可能把「策略組／Proxy Groups」編輯入口放在設定檔、覆寫或外掛編輯器中。核心只吃合併後的 YAML 語意；因此本文以 Mihomo 對 fallback 的欄位慣例為準，請你用「儲存後重載、再看連線紀錄」驗證，而不是執著於某個按鈕叫法。

fallback 策略組在做什麼？跟 selector、url-test 差在哪？

用一句話記：fallback 會依你在 proxies: 陣列裡寫的順序，從上到下找第一個「健康」的成員來用。它不是在每次測速後把全組節點做延遲排序後挑冠軍；那是 url-test 的場景。你也可以把 fallback 想成「你親自排好的接棒名單」：主線掛了就換副線，副線不行再換備援，而不是每輪比賽重選誰跑最快。

selector則是把選擇權交給你：你想連哪個就點哪個，核心不替你自動換。當你希望長輩或固定裝置不要自動跳節點，selector 仍是首選；當你希望在办公室網路品質抖動時盡量少手動干預，fallback 或 url-test 才進場。

那為什麼站內還要寫一篇 fallback，而不併進 url-test？因為實務上有大量需求是「我只要優先用這三台，其它都當備胎」，而不是「永遠用延遲最低那一台」。某些頂配節點成本高、連線品質穩定，你可能寧願固定優先序，只在探測失敗時才降落；這種時候 fallback 比 url-test 更貼語意。

選型心法：要手動指定用 selector；要自動挑最快用 url-test；要依你排的順序自動跳過不健康節點用 fallback。若同一組名稱裡混著想「又要排序又要比快」，通常代表你其實需要兩個策略組分工，再由規則分流。

health-check、策略組 URL 與「略過故障節點」的關係

在 Mihomo 系譜裡，fallback 與 url-test 這類會自動切換成員的策略組，通常會附帶週期性的健康檢查：對每個成員朝你指定的 探測 URL 發請求，依成功與否與回應時間決定是否視為可用。介面上你看到的延遲測試／測速按鈕，本質上是把這套探測以可讀的毫秒或超時狀態顯示出來；重點是「有沒有通過門檻」，而不只是數字好看。

因此，策略組 URL（health-check 用）請不要隨便抄一段網路上最長被轉貼的網址就結案：若該 URL 在你 ISP、地區路由、或學校/公司出口被干擾，可能導致整組被判不健康，反而頻繁跳到清單後段。較穩的做法是先挑一個對你環境實測可達、回應單純的探測點，再觀察 10～20 分鐘內是否穩定。

interval與timeout則決定你願意花多久確認「這條線掛了」：間隔太短可能放大短暫抖動，看起來像在抽換節點；間隔太長則故障感知的延遲變大，使用者會先覺得「網頁開一半才換線」。Windows 11 上若同時開著省電、Wi‑Fi 漫遊或 VPN，這些參數更需要用連線紀錄對照主觀體感微調，而不是一次寫死成網美參數。

YAML 長什麼樣子？ proxies 順序就是容錯優先序

下方是一個示意結構，欄位名稱請以你實際核心版本與訂閱模板為準；重點是 type: fallback 與成員順序。

proxy-groups:
  - name: MyFallback
    type: fallback
    proxies:
      - Node-A-Preferred
      - Node-B-Backup
      - Node-C-Emergency
    url: http://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000

在上例中，只要 Node-A-Preferred 在健康檢查裡被判定可用，後面的成員不會因為延遲更低而被搶走；只有當它探測失敗或超時，才會轮到 Node-B-Backup。這就是 fallback 與 url-test 最大的體感差異：前者尊重你排的社會階級，後者尊重當下延遲排行。

若你的模板把探測欄位包在巢狀區塊（例如某些產生器寫成 health-check: 子表），請以合併後實際生效的 YAML為準。Clash Verge Rev 的「設定檔預覽」或外部編輯器能看到最終結果時，優先相信最終結果，而不是訂閱原文片段。

名稱一致性：proxies: 清單裡的每一行都必須能對應到已存在的 proxy 名稱或其它已宣告的策略組。拼字一改，整段會在重載時報錯或靜默退回舊組；Win11 上若以檔案同步工具編輯，特別容易出現全形符號或空白差異。

在 Clash Verge Rev 裡怎麼落地？建議照著做的流程

  1. 備份：複製目前使用中設定檔；若你使用遠端訂閱，記下更新頻率，避免等會兒被覆寫。
  2. 定位編輯入口：在 Verge Rev 打開對應設定檔的文字編輯／預覽，搜尋 proxy-groups:。
  3. 新增或修改一組 fallback：確認 name 與規則裡要引用的一致；proxies 由你最想優先使用的節點排到最後備援。
  4. 填探測與時間：設 url、interval、timeout（若模板有預設值，先小幅調整而非一次翻倍）。
  5. 把規則錨到這組：在 rules: 內將目標類別改為 MyFallback（或你實際命名），避免仍指向舊的 selector/url-test。
  6. 儲存並重載核心：看日誌是否乾淨；若報錯，先還原備份再分段貼回修改。
  7. 先跑延遲測試再看連線：在策略組面板對該組跑一次測試，確認前列節點狀態；再打開實際網頁或 App，於 Connections 觀察命中的節點是否與預期一致。

Windows 11 上容易踩雷的場景（與 fallback 無關卻像有關）

有些症狀看起來像「fallback 沒略過壞節點」，其實是流量沒進核心：系統 Proxy 沒套用、TUN 沒啟用、或特定程式自有 Proxy。請先用連線紀錄確認請求是否出現在 Verge Rev；若完全沒有，先回到系統代理與虛擬介面的設定，不要調一堆策略組。

其次是DNS 與規則次序：若域名在解析階段就被導到錯誤類別，後面的 fallback 再健康也只能在錯的出站類別裡選比較不壞的那個。這類問題請搭配 DNS 與規則文本一起看，而非單改策略組。

最後是訂閱合併與覆寫：Win11 使用者常以檔案總管或雲端碟多端修同一個片段，容易造成版本打架。建議固定「單一真相來源」：要嘛由遠端模板主導、要嘛由本機 merge 主導，不要在兩邊同時手改同名策略組。

自檢清單：怎麼確認「不健康會被略過」真的發生？

第一先看延遲面板：手動對該 fallback 組跑一次測試，記下哪幾個成員顯示失敗或極高延遲。若前列成員失敗而後列正常，理論上核心應偏好後列的健康成員。

第二看連線紀錄：在實際產生流量的當下，過濾目標域名，確認 Policy／RULE／節點名稱是否落在你預期的 fallback 成員上；若規則仍指向舊組名，代表規則文本沒換成功，不是 fallback 邏輯壞掉。

第三做刻意對照實驗（僅在你可承受短暫斷線時）：暫時把清單最前者換成已知不可用或錯誤密碼的占位名稱，然後觀察是否會在合理時間內切到第二順位——這是最直白的行為驗證；做完務必還原備份。

  • 探測全紅：先懷疑 URL 被擋或本機防火牆攔截出站，而不是節點全集覆滅。
  • 只有特定 App 不聽話：查是否繞過 TUN、或該 App 使用 QUIC/自有 DNS。
  • 延遲低但網站打不開：可能是規則匹配域名不完整；與 fallback 是否切換無直接因果。

常見問題（濃縮）

可以把 fallback 與 url-test 互相嵌套嗎？

技術上常見做法是讓 url-test 選出的「最快組」再餵給更大一層策略組；但嵌套越深，排查越辛苦。若你剛起步，建議扁平化：明確兩三組職責，再用規則分域名類別。

fallback 清單可以放 DIRECT 嗎？

可以，是否符合你的安全模型是另一回事。若你把 DIRECT 放在最前，代表只要直連探測正常就不會動用代理；這適合明確知道該規則只要回本機出口的情境，不適合需要全程走隧道的流量。

介面上延遲顏色與實際出站一定一致嗎？

顏色與數字是探測路徑的摘要；實際業務連線可能走到不同 SNI、不同埠或不同 IP 族。请以連線紀錄為準，顏色為輔。

合法合規：請在你的網路環境與服務條款允許範圍內設定代理與分流；本站僅提供技術說明，不協助規避適用法規或第三方政策。

結語

fallback 策略組在 Clash Verge Rev 裡不是神秘開關，而是把「我排的接棒順序」寫進核心的一種方式：搭配health-check URL與週期，它能在 Windows 11 日常網路抖動時減少你手動切節點的次數；理解了與 url-test 的差異，你就不會再期待它幫你「永遠自動選最快」，也不會把延遲面板當唯一真理。

相較之下，不少片段式教學只教你複製 proxies 清單或只談延遲排行，卻不解釋清單順序與健康檢查如何一齊決定出站，結果你在搜尋「fallback group」時得到答非所問的 url-test 流程，調到深夜仍在怪節點。Clash 官網把 Win11 桌面端語境、策略組類型與規則語意放在同一站內脈絡，讓你能用同一套「備份→單點修改→連線紀錄驗證」路徑收斂問題，而不是在社交平台東拼西湊 YAML。

若你希望先用可信的下發來源建立乾淨 baseline，再依本文完成 fallback 組與規則對接，不妨從本站整理的入口取得相容用戶端： 免費下載經整理的 Clash 官網 相容用戶端 ，接上訂閱後照著步驟重載與自檢，通常一個回合內就能把容錯語意對齊。