先釐清目標：要「測速最快」還是「主備容錯」？
兩種需求聽起來都像「自動換線」，但決策邏輯不同。url-test 適合：您有一批同角色的候選節點（例如同一機場的多個落地），希望核心定期對每個候選做 HTTP 探測，在延遲可接受的前提下偏向選較快的那個，並在波動時依 tolerance 避免頻繁跳來跳去。fallback 則適合：您心裡有明確優先序（主線、備援、最後才直連），只要前面的節點健康檢查失敗就往後退；它不以「誰延遲最低」當唯一目標，而是以「清單順序＋可用性」為主。
實務上常見組合是：對外給使用者一個 select（手動覆寫），其候選裡再放一個 url-test 或 fallback 當「自動池」；或讓 MATCH 指到自動組，再把少數網域規則寫在前面直連。無論哪種，請牢記：規則命中的是「策略組名稱」，不是訂閱裡的原始節點字串；若規則仍指向舊的 select，您改了 url-test 也不會被走到。
健康檢查在測什麼？url 與逾時
url-test 與 fallback 都會對清單內的候選節點發起輕量 HTTP(S) 請求（由 url 指定），以往返延遲與是否成功判斷健康。常見的檢查 URL 會選體積小、CDN 穩定的端點（例如各家教學常用的 http://www.gstatic.com/generate_204 或類似 204／極小回應的路徑）；重點是對您的節點池而言成功率夠高，且不要選會被機場或區網攔截的域名，否則會出現「其實能上網，但檢查全失敗」的假陰性。
若您把檢查間隔設得太短、同時候選節點很多，等於讓核心頻繁對外打探測流量；除了增加機場端負擔，也可能讓延遲統計抖動變大。一般會在可接受切換速度與探測頻率之間取捨：家用客戶端常見設定是數百秒級的 interval，再視情況調整；需要更快反應時再縮短，並觀察是否引發過度切換。
1url-test：參數怎麼配？
在 proxy-groups 新增一組，type 設為 url-test，proxies 填入已存在於 proxies 區塊（或訂閱合併結果）的節點名稱。url 為健康檢查位址；interval 為全輪詢週期的概念（實作細節依版本，請以您使用的 Mihomo 版本行為為準）。tolerance 是毫秒級的延遲容差，可視為延遲閾值外的緩衝帶：當目前選中的節點與測得最快節點差距在容差內時，可避免為了幾毫秒差異一直換節點；容差太小會變得敏感，太大則可能長期黏在次佳節點。
lazy: true 常見用途是：在該策略組尚未被任何連線實際使用前，先不做積極探測，以降低冷啟動時的背景流量。若您希望一載入設定就立刻完成首輪測速，可改為 false 或省略（依預設）。撰寫時請確認清單內沒有拼錯名稱，也不要把另一個策略組放進來卻造成循環引用（A 依賴 B、B 又依賴 A），否則載入會失敗。
# Snippet — url-test group; proxy names must exist
proxy-groups:
- name: AUTO-BEST
type: url-test
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: true
proxies:
- NODE-A
- NODE-B
- NODE-C小結：url-test 偏向「在候選裡挑延遲表現好的」，tolerance 用來抑制過度切換。
2fallback：主備順序怎麼寫？
type: fallback 同樣使用 url 與 interval 做健康檢查，但選路邏輯是：從清單最前面開始找第一個健康的節點。因此清單順序就是您的容錯優先級：可把「最希望長期使用的主線」放最前，「臨時備援」放中間，「再不行就換另一機場」放後面。當前排節點恢復健康時，是否立刻切回前排，與版本與健康狀態判定有關；實務上仍建議以日誌觀察實際切換是否符合預期。
# Snippet — fallback chain
proxy-groups:
- name: AUTO-FALLBACK
type: fallback
url: http://www.gstatic.com/generate_204
interval: 300
proxies:
- PRIMARY
- SECONDARY
- TERTIARY若您的主線是「高品質少跳點」、備援是「便宜大量節點」，fallback 通常比 url-test 更直覺：您不想只因為備援延遲稍低就整批換過去，而是主線掛了才退守。反之，若您在意的是晚高峰誰快，url-test 較合適。
3把規則接到策略組：否則永遠不會自動切
設定好 AUTO-BEST 或 AUTO-FALLBACK 之後，請在 rules 裡把需要自動選線的流量，策略欄位寫成這個策略組名。Clash 系規則是由上而下先命中先贏；若前面已有寬鬆規則把流量送去別的組，後面寫再多也不會生效。這與 GEOIP／GEOSITE 分流 一文強調的順序問題同源：先確認第一條命中是誰。
rules:
- DOMAIN-SUFFIX,corp.internal,DIRECT
- GEOIP,CN,DIRECT
- MATCH,AUTO-BEST
若您使用圖形客戶端（例如 Clash Verge 類），也要確認「目前選中的出站」是否仍指向舊的 GLOBAL／PROXY 手動組；介面上的選擇常會覆寫您以為已改好的預設行為。建議以連線日誌驗證：命中規則後，實際策略名稱是否為您的 url-test／fallback 組。
4驗證是否生效：從面板到日誌
完成 YAML 後建議用固定流程驗收，避免同時改 DNS、TUN、規則而無法歸因。第一步：重載設定，確認沒有「策略組循環」或「找不到節點名稱」類錯誤。第二步：在客戶端檢視該 proxy-groups，觀察各候選是否出現延遲數字或健康狀態（依 UI 而定）。第三步：刻意製造故障（例如暫停主節點所在機房、或改錯單一節點密碼僅作測試環境），觀察 fallback 是否往清單後方退；對 url-test 則觀察是否改選延遲較低且穩定的候選。
第四步：把 log-level 調到 info 或更高（短時間即可），搜尋與策略組、健康檢查相關的訊息，確認探測 URL 沒有被全數封鎖。若您同時啟用 tun 或複雜 DNS，請記得健康檢查也會走代理鏈路；少數情境下會與 FakeIP／DoH 政策 交互影響，這時更要一次只改一個變因。
常見坑與調參方向
- tolerance 過小：
url-test在晚高峰可能頻繁換節點，部分網站登入態或長連線會感覺不穩；可逐步加大並觀察。 - interval 過短：探測太密集，除了負擔，也可能讓延遲統計被偶發尖峰拉歪。
- 檢查 URL 不適合：全節點顯示失敗或延遲異常，優先懷疑URL 被封鎖或需要直連卻走了錯誤策略。
- 候選混進不同用途節點：例如把「僅 TCP 的線路」與「遊戲 UDP 節點」放在同一池自動選，可能導致選到快但不支援您實際協議的線；應按場景拆池。
- 與 relay 混用：若您使用 relay 雙跳，請確認自動組選到的是可支援鏈路與 UDP 需求的成員，不要把健康檢查當成萬能品質證明。
提醒：代理設定須符合所在地法規與服務條款；教學僅供合法合規的網路除錯與自用學習。
可合併進現有設定的最小範例
下列片段示範同時存在 url-test 與 fallback 兩個自動池，並讓最外層 select 可手動覆寫；註解使用英文以利部分解析器相容。請將節點名稱替換為您訂閱中實際存在的條目，並與既有 dns、tun 合併調整。
# Minimal pattern — merge with your proxies / dns / tun
mode: rule
log-level: info
proxy-groups:
- name: AUTO-BEST
type: url-test
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: true
proxies:
- REPLACE-A
- REPLACE-B
- name: AUTO-FALLBACK
type: fallback
url: http://www.gstatic.com/generate_204
interval: 300
proxies:
- REPLACE-PRIMARY
- REPLACE-BACKUP
- name: PROXY
type: select
proxies:
- AUTO-BEST
- AUTO-FALLBACK
- DIRECT
rules:
- MATCH,PROXY
上例將決策收斂在 PROXY 這個手動組：日常可選 AUTO-BEST 追求體感速度，出國或特殊時段改選 AUTO-FALLBACK 強調主備穩定。您也可以把 MATCH 直接指到其中一個自動組，但會降低臨時手動介入的彈性。
開源資訊與安裝包取得方式
Mihomo 上游以開源方式維護，需要查核版本行為或提交 Issue 時適合前往公開程式庫。日常下載或更新圖形客戶端，建議優先使用 本站 Clash 下載頁，並搭配 設定說明文件；將「取得安裝包」與「閱讀原始碼」分開，可避免誤以為必須自行從 Release 頁拼裝環境。
結語
url-test 與 fallback 都是透過 proxy-groups 把「自動換線」變成可讀、可維護的設定：前者偏延遲最佳化，後者偏主備容錯。兩者都仰賴合理的健康檢查 URL、interval 與（在 url-test 情況下的）tolerance，並且一定要讓 rules 真的命中到對應策略組，才算完成閉環。把驗收固定成「重載無錯誤 → 面板狀態合理 → 日誌確認命中與切換」，通常比盲目堆節點更有效。
相較於只靠手動切換或依賴訂閱預設排序，在 Clash Meta／Mihomo 裡顯式寫出 url-test／fallback，長期更容易與 relay、GEOIP、DNS 政策並存而不互相打架。若您接下來要處理 HTTPS 只有 IP、域名規則不觸發的問題，可再串接 Sniffer 與 DNS 相關文章，但自動策略組本身仍應先確認名稱與命中順序無誤。
相較於其他同類工具，Clash 系在「規則、策略組、日誌」三者之間的對照關係較一致，對需要延遲閾值與自動切換的使用者較友善。完成上述設定後，建議保留一段時間的觀察期，再微調 interval 與 tolerance，以符合您實際網路環境與使用時段。