為什麼要把「fallback」單獨拿出來講？
許多人在 Windows 上裝好 Clash Verge Rev、訂閱也能更新後，規則多半照模板跑，卻在「自動組」上踩到兩個極端：一種是覺得節點換太勤，影音或遠端桌面被切線打斷；另一種是想要主節點掛了自動換備援，卻發現遲遲不切、或一切就整組判死。這兩種困擾常常對應到不同的策略組類型——前者較常和url-test（自動挑快）參數太激進有關，後者則多半要回頭檢查fallback（依序主備）底下的健康檢查 URL與逾時（timeout）是否合理。
本文只聚焦 proxy-groups 裡 type: fallback：怎麼在圖形介面或YAML 覆寫（Patch）場景，把備援順序、健康檢查、interval、timeout、lazy，以及隱性影響判斷結果的 expected-status／max-failed-times 一次對齊。底層語意以社群常用的 mihomo（Clash Meta 系）文件為準，實際欄位若隨版本調整，請以你本機核心說明與日誌為準。型別的大圖仍建議併讀 規則分流詳解；若你要調的是「誰延遲低就選誰」而不是「誰先能用就先用誰」，請改讀姊妹篇 Clash Verge Rev url-test：interval、tolerance、lazy。日常按鈕、模式與日誌路徑則對照 Verge Rev Windows 用法教學。
fallback 是「照著清單順序找第一個健康可用」；url-test 是「在池子裡找當下延遲最好」。你要少跳線，通常先檢查有沒有把更需要黏著連線的場景誤塞進 url-test；要主備自動切，就把順序與健康檢查條件先寫對。
fallback 實際怎麼選節點？跟健康檢查的關係
在 mihomo 文件語意裡，fallback 會對 proxies: 清單成員做健康檢查，並以你寫入的先後順序作為備援邏輯：當目前使用中的節點在檢查語意下判定逾時或失效，核心會往後找「第一個可用的」成員。這和 url-test 那種「延遲變好就換最快」的競賽式切換不同——fallback 更像主備鏈：前面能撐住就繼續用，不行才交棒給下一個。
健康檢查 URL（url）指定探測請求要打去哪裡。它不替你保證「所有真實網站都通」，而是提供一個可重複、可比較的探針：若 URL 對某些節點常失敗、或回應型態和你設的判斷不一致，就會出現「其實還能上網，但組判定大家都紅燈」的錯位。相對地，若 URL 太寬鬆，又可能「檢查永遠綠燈、特定站點仍走不順」——這時要回到規則與實際連線域名，而不是只盯策略組。
另有一點實務上常被忽略：在通用欄位說明裡，健康檢查預設只針對該組的 proxies 成員；透過 use 引入的 proxy-providers 內節點，不會因為你在組上寫了 url 就自動整套替你測（語意上以文件為準）。若你的備援清單主要來自 provider，卻發現死節點沒被剔除，要先確認模板是否真的把節點展開進 proxies，以及 provider 自己有無內建健康檢查或過濾。
第一步：排好 proxies 順序——這就是「備援劇本」
在動任何數字之前，請先把 proxies: 看成劇本：最前面是你最想用的主線，後面依序是備援一、備援二、必要時再接 DIRECT 或某個手動 select子組。fallback 不會幫你「智慧排序」；它只會在健康檢查框架內尊重你給的順序。很多人抱怨「怎麼一直用慢線」，結果是清單第一個其實是舊的預設槽位，或訂閱更新後節點名稱改變導致引用錯位。
若你希望「平常手動挑國家／供應商，故障時才自動降級」，常見做法是外層 select 給人操作，內層再接 fallback 串具體節點或子組；或反過來由 fallback 包一個小的 url-test 池當自動備援——怎麼巢狀屬於架構選擇，重點仍是：每一層的順序與型別是否符合你想像中的故障轉移。圖形介面若能拖曳排序，記得確認儲存後寫回設定檔的順序是否如預期；若只改畫面沒進檔案，重載後會打回原形。
第二步：選對健康檢查 URL，避免「假紅燈／假綠燈」
實務上不少模板使用輕量、常見可直連的 HTTPS 端點作為探針；重點在於對你的節點池是否大多數都能穩定完成，且狀態碼或內容特徵符合你設定的判定。若站方偶爾回非預期狀態、或特定出口被干擾，就會讓 fallback 誤以為主線壞掉而往下切。此時可以調整 expected-status（若你確定要以狀態碼篩選），或更換更中性、較不易被區域政策扭曲的檢查位址。
也要刻意避免兩類極端：一類是過於嚴苛（例如檢查點只對某一雲或某一國特別友好），導致所有節點輪流被判不可用；另一類是過於寬鬆，請求總是成功但無法反映 TLS、DNS 或特定應用路徑問題——這不是 fallback 無用，而是探針與業務指標脫鉤。若你關心的是單一關鍵服務，偶爾仍需要以連線紀錄對照實際 SNI／目標 IP，而不是指望一個 generate 風格的 URL 代表整張網路地圖。
第三步：設定 timeout——毫秒級的「耐心」邊界
timeout 描述單次健康檢查請求願意等待多久（在 mihomo 通用欄位裡以毫秒為單位理解）。它與「你主觀覺得網页慢」不完全相同：健康檢查偏向短連線、可重試的探針；設太短時，節點在抖動或暫時壅塞下會被誤判，fallback 便頻繁交棒，體感像「一直換線」；設太長則真的故障後要等多一會才願意宣告失敗，切換落後。
調整策略可以這樣想：先以保守、略寬鬆的 timeout 換取較少誤判，觀察核心日誌與連線列表確認主線恢復後是否會回到順序頂端（行為也受健康檢查週期與失敗次數邏輯影響）。若你常在高延遲或不穩 Wi‑Fi 環境，過緊的 timeout 幾乎一定會放大雜訊。相對地，在內網或極度穩定的出口上，才可考慮略為收緊以更快剔除死線。任何調整都建議用同一套訂閱、固定時段對照，不要一邊大流量下載一邊結論參數失效。
第四步：interval 與 lazy——多久測一次、要不要拖著測
interval 決定非零時的週期檢查節奏（秒）。對 fallback 而言，它不是用來「每幾秒換最快線」，而是用來周期性確認目前鏈路是否仍健康、以及後備是否可得。間隔太短會增加探針流量與日誌噪音；間隔太長則可能在節點品質變化時反應偏慢。實務上可先用模板預設，若你觀察到不必要的頻繁判死，先回到 timeout 與 URL，再動 interval。
lazy 預設為 true：當策略組尚未被選用時，可能不進行完整測試，藉此降低閒置時的背景檢查。缺點是首次命中時，狀態或許仍在蒐集，對極在意首包延遲的主出口要評估是否改為 false，或接受較溫和的 interval。對很少命中的冷備組，保留 lazy 通常能省資源。
max-failed-times（若模板有開）與「連續失敗多少次才更積極重新評估」相關，能避免一次抖動就立刻放棄主線；實際門檻請以你所用版本文件為準。把它想成緩衝帶，搭配合理 timeout，通常比盲目縮短 interval 更不傷體感。
tolerance 跟 fallback 有什麼關係？
搜尋時常把 tolerance 與各種自動組混在一起，但在 mihomo 文件裡它是url-test的專用欄位，用來抑制「新最佳節點只比現用好一點點就切換」造成的來回搖擺。fallback 的主軌決策是順序＋可達性，不是延遲排位賽；因此你若在 fallback 上硬塞 tolerance，未必有預期效果，還可能讓人誤會參數沒生效。
若你的真實需求其實是「在池子裡找最快、又要防抖」，應該直接在 url-test 上調 interval／tolerance／lazy，而不是把 fallback 當 url-test 用。反過來，若你要「鎖定主線、只有壞了才換」，fallback 才是第一選擇。兩者可並存於巢狀結構：關鍵是別讓使用者規則最後在不對的型別上猜。
在 Clash Verge Rev 用覆寫穩定保存（Windows 實務）
直接在訂閱下发的主設定上改 proxy-groups，下次更新常被洗掉。Clash Verge Rev 通常提供覆寫、Patch、Merge（菜單名稱依版本）讓你只 patch 要動的那幾行。工作流程建議：先在腦中列出差異清單——哪個組要改 url、timeout、interval、lazy、或調整 proxies 順序——再寫进覆寫檔，讓訂閱專心管節點池與大規則。
寫 YAML 時務必注意縮排與鍵名層級；合併失敗時核心可能拒載。可對照 YAML 解析與縮排排查。完成後在規則模式下開啟常用站點，配合連線列表確認流量命中預期策略組，並刻意製造「主節點不可用」的情境（例如暫時停用主線或改壞上游）觀察 fallback 是否按順序移交，比只看 GUI 延遲數字更可靠。
什麼時候不要用 fallback 硬扛？
若你的場景需要長時間黏在同一出口 IP（風控、遊戲伺服器、某些企業 VPN 並行），任何自動健康檢查切換都可能帶來登入跳驗證或斷線；此時手動 select鎖節點或縮小候選池，往往比再多寫幾層 fallback 有效。又若問題根本在 DNS 或規則提前把流量送到錯組，fallback 調再漂亮也只是在錯的管道上做主備。
另外，對巢狀策略組要特別耐心：父組的健康檢查語意與子組狀態組合起來，偶爾會出現「子節點其實還好，但父層判定不佳」的 corner case（社群 issue 亦有討論）。遇到這類狀況，先把結構簡化——減少不必要的組中組——再逐步加回，比一次堆疊巨塔更容易定位。
常見問題
fallback 比 url-test 更適合直播或遠距嗎？
不一定，但若你痛恨為了幾十毫秒切線，fallback 通常更符合「除非壞了不換」的體感；url-test 則適合願意用延遲換取常常自動挑快的人。實務上也有直播主在外層用手動選線，內層才用 fallback 串備援，避免自動邏輯干預演出。
健康檢查顯示失敗，為什麼不切到下一個？
可能原因包含：清單下一個成員同樣不可用、引用名稱不存在、被規則導向別組、或 timeout／URL／expected-status 設定讓判定與你以為的不同。請以核心日誌與連線列表為準，確認當前命中策略組是否真是你修改的那個。
同一訂閱裡同時好多 fallback／url-test，從哪裡下手？
先找出規則最常命中、影響你體感的唯一出口組名稱，只對那一組做小步驗證；不要同時改十個組，否則觀察結論會互相污染。具體規則閱讀順序與策略組概念可回到 規則分流詳解。
總結
fallback 的設定其實是把三件事說清楚：備援順序、健康檢查怎麼判生死（url、狀態碼、timeout）、以及多久驗一次／要不要懶載入（interval、lazy、可能的失敗次數門檻）。把它和 url-test、tolerance 分清楚之後，很多「自動組不聽話」並不是 Clash Verge Rev 壞掉，而是型別與探針沒對上你的真實場景。尚未摸熟介面者，可從 Windows 安裝首跑把系統代理與 TUN 環境收斂好，再回來改策略組，會事半功倍。
相較部分封閉型 VPN把規則與健康檢查藏在黑箱內、只剩國旗圖示可點，使用者很難判斷故障是節點、探針還是被誤導的 UI 延遲；有時為了維持「看起來永遠連得上」，商用產品會吞掉關鍵錯誤細節或限制你可調參數。Clash 生態與 mihomo 系核心讓你能檢視 YAML、日誌與連線紀錄，並在 Verge Rev 這類仍活躍的前端裡用覆寫把 fallback 的行為收回手中——願意多懂一點設定，就能把主備切換從「玄學」變成可實驗、可回滾的工程問題。