Clash Meta 策略組 url-test 與 fallback：自動測速、lazy、tolerance 與故障切換逐步配置
當訂閱已能連上、規則也能命中時，進階需求常集中在兩件事：一是別每次都手動挑節點，希望系統依延遲自動選較快、較穩的出口；二是主要中繼掛掉時能立刻換到備援，不要整台斷網。Clash Meta（Mihomo）裡，前者通常由 url-test 類型的策略組負責定期測速並選擇延遲較低者；後者則由 fallback 依您寫好的優先順序向下尋找第一個通過健康檢查的候選。再配合 lazy 與 tolerance，可在「啟動時別狂測一堆節點」與「切換別太敏感、避免一直換線」之間取得平衡。本篇以 YAML 逐步疊加的方式說明，並釐清健康檢查 URL與您實際瀏覽、串流行為的關係，以及為何DNS 區塊裡的 fallback與策略組的 fallback完全是兩回事。
先釐清三個角色：策略組在幫您做哪件事
在規則裡，您只會看到一個名字（例如 PROXY 或訂閱產生的「自動選擇」）；真正要連哪一個上游，由策略組內的型別決定。select 仰賴您或圖形介面選定的一個節點；url-test 會對清單中的候選依序／輪詢進行小型 HTTP 請求（指向您設定的 url），以量到的延遲挑「目前看起來最快」的一個。fallback 則不是比誰延遲最小，而是從清單由上而下找第一個判定可用的成員，典型用途是主備鏈、優先序冗餘。
兩種型別的候選清單裡都可以放另一個策略組的名稱，藉此分層：例如底下先有一組地區的 select，上層再用 url-test 比較各地區代表。實務上建議自訂一致的命名前綴，避免與訂閱每次更新後冒出的預設名稱衝突，並讓規則最後只指向單一一個對外策略組，日誌才追得動。
- url-test：偏「競速」——延遲較佳者上線；可用
tolerance降低因幾毫秒差距而頻繁換人。 - fallback：偏「排隊」——照您的優先順序找第一個活的；適合主節點／備用機場／最後一道
DIRECT安全網。 - lazy：若為
true，較不會在程式一啟動就對所有成員大舉探測，有助減輕大型訂閱的啟動負擔（與「何時才算用到該組」的實作細節依版本而異，請以目前核心說明為準）。
url-test：interval、tolerance、lazy 與 url
url 是健康檢查／測速的目標位址，常見為回應 204 或極小內容的 HTTPS URL（例如 Google、Cloudflare 的產生端點）。重點是：它量到的是到該 URL 的 RTT 表現，未必與您稍後實際造訪的網站、CDN 路徑一致。若某 URL 在您的出口環境常被擋、被限速或 DNS 異常，可能出現「全部節點看起來都不健康」的假象，這時應先換 url 或對照機場建議的測試位址。
interval 是測試週期（秒）。間隔愈短，愈跟得上節點品質變化，但也增加背景連線與日誌噪音；若池子裡節點延遲在幾毫秒間互有勝負，過短的間隔會放大「忽 A 忽 B」的體感。tolerance 可視為遲滯帶：新任延遲須比現任好超過約略該數值（毫秒），才值得換線，藉此減少閃跳。一般瀏覽可從數十秒級的 interval 搭配數十毫秒級的 tolerance 試起；長連線、VoIP、WebSocket、IDE 同步等情境，則更要避免過度敏感的切換，否則「換節點」本身會觸發重連。
lazy 該什麼時候開
節點很多時，lazy: true 常讓啟動第一段時間較不急躁；但您若希望一開程式就完成一輪測速、馬上得到可信的「自動選組」結果，可能會覺得首屏前幾秒較慢熱。兩者取捨依裝置性能與訂閱規模而定，沒有絕對答案。
fallback：故障切換與優先順序
fallback 會依清單由上而下評估，挑出第一個通過檢查的成員。因此排序本身就是政策：商業穩定線放最上、實驗性節點放後面，或「先走一組 url-test，失敗再換固定備援」，都透過順序表達。請勿與「延遲最低」混淆——那比較是 url-test 的工作。
若健康檢查持續失敗，別只怪節點：測試 URL 被專線出口列入異常、回傳 429、TLS 握手遭中間設備干擾，都會讓探針失敗與真的斷線長得很像。建議對照核心日誌，分辨是 url 連不到，還是實際代理鏈已斷。
勿與 DNS 區塊的 fallback 搞混
設定檔裡 dns: 底下也有一種稱作 fallback 的列表，那是域名解析路徑的備援與防污染設計，與「代理策略組型別＝fallback」無關。閱讀 YAML 請以區塊階層辨識。DNS／fake-ip 的實務可搭配 〈已連上卻無法上網？DNS 與 fake-ip 排查〉。
逐步撰寫：先測速組、再串故障切換組
實務上常見拼法為：先確認 proxies 名稱與訂閱一致 → 建立一個 url-test 專心「在數個節點中挑延遲低者」→ 如需主備，再包一層 fallback，把「自動測速組」當第一棒，後面接備援節點或 DIRECT（是否適合直連視您的家網與法遵情境而定）。規則中讓業務流量只指向最外層策略組，較利於維護。
# Illustrative proxy-groups — replace names with your subscription
proxy-groups:
- name: "AUTO-BEST"
type: url-test
proxies:
- NODE-A
- NODE-B
- NODE-C
url: "https://www.gstatic.com/generate_204"
interval: 30
tolerance: 50
lazy: false
- name: "AUTO-FAILOVER"
type: fallback
proxies:
- AUTO-BEST
- NODE-SPARE
- DIRECT
url: "https://www.gstatic.com/generate_204"
interval: 30
上例中，先以 url-test 在三個節點中自動擇優，再把該組輸出交給 fallback 的第一候選；若整組仍判定不可用，便落至備援，最後才直連。若您身處的網路不適合把流量直接暴露於境外直連，請將最後一格改為固定備用代理或依需求調整，而非盲從示例。
健康檢查 URL 要怎麼選
輕量、回應穩定的 URL 有利於量延遲，但與您真正造訪的網站路徑不一定相關——所以可能出現「測速很漂亮、看串流卻卡」或反之。可行做法包括：依用途拆成多個策略組（工作瀏覽／娛樂／開發下載），各組獨立 url 與 interval；或至少固定使用可信、長期可用的測試端點並定期檢視日誌。
| 考量 | 說明 |
|---|---|
| 可否穩定握手 | 出口若對特定網域 TLS 異常，該 URL 就不適合當全體公衛生檢查基準。 |
| 會不會被限速或擋機房 | 若探針常回非 2xx，節點池會輪流被判死，實為誤報。 |
| 與業務的相關性 | 需要較一致體驗時，可朝「行為接近」的測試目標調整，但要警覺維護成本。 |
節點一直切換（閃跳）時怎麼辦
徵兆包含：網頁週期性重載、聊天 WebSocket 頻繁重連、大檔下載反覆從頭。請先確認是否同一策略組在短時間內輪替兩顆以上節點。常見調整順序為：略為提高 tolerance、略為拉長 interval、縮小候選池只留下品質相近者，或乾脆依情境拆組。若您疊了遠端規則集，也要排除另一條規則把流量導去別組的情況；規則提供者路徑與更新節奏可參 〈Clash Meta 規則提供者：path 與更新間隔〉。
串流與長影音場景下，過於頻繁的自動切換可能讓播放器重新協商連線；此時「測速數字好看」不如「連線少中斷」——務必把 tolerance／interval 與實際體感一起調。
上線後檢查清單
- 規則與 UI 選用的策略組名稱是否一致，訂閱更新後有無改名。
- 健康檢查是否大量逾時——優先懷疑
url與出口相容性。 tolerance／interval是否對長連線場景過於敏感。- 啟動延遲與 lazy 的取捨是否合乎裝置與訂閱規模。
- 是否誤把 DNS 的 fallback 與策略組的 fallback 混讀。
結語
url-test 幫您在候選裡找延遲較佳者；fallback 幫您在優先順序裡找第一個可用者。兩者常一起用，但語意不同。lazy 與 tolerance 則是「別太躁進地測」與「別太敏感地換」的調節鈕。把策略組命名與分層整理好，長期維護會比不停堆新節點名單來得省力。