為什麼「自動測速」反而讓節點像喝醉一樣換來換去？
很多人在 Windows 上把 Clash Verge Rev 裝好、訂閱也能更新，接著就交給模板裡的「自動選擇」「自動測速」類策略組。結果實際使用時卻出現兩種典型困擾：一是節點明明沒斷線，卻每隔一段時間就換出口，視訊緩衝重新計算、語音通話瞬斷；二是介面上延遲數字很漂亮，但遊戲或直播仍然卡。這並不一定是客戶端壞掉，而常與 proxy-groups 裡 url-test 這類「依延遲自動挑選成員」的邏輯有關——它會週期性對候選節點打健康檢查（health-check）請求，並在量測結果變動時改選當下延遲最佳者。若測試太密、門檻太敏、或測試 URL 與你真實流量路徑差太遠，就會出現策略組抖動：看起來像「亂跳」，其實是演算法在噪音裡做決策。
本文只做一件事：把 url-test 相關旋鈕——interval、tolerance、lazy，以及常見的 url（測速／健康檢查網址）——拆成可依序調整的步驟，並說明在 YAML 與 Verge Rev 覆寫（Patch）裡如何分步落地。它刻意不複述整份規則教材：策略類型的大圖仍建議併讀 規則分流詳解；主介面按鈕、模式切換與連線日誌路徑則對照 Verge Rev Windows 用法教學。底層核心以社群常見的 mihomo（Clash Meta 系）語意為主，實際欄位名稱若隨版本微調，請以官方文件與你本機核心日誌為準。
url-test 參數或測速 URL 需要調整；若手動鎖定仍會斷線，則要先回到節點品質、DNS、規則命中與是否走 DIRECT／REJECT 來排查，而不是盲目加快測速頻率。
url-test 在做什麼？跟介面上的「測速」有何關係？
在設定檔中，proxy-groups 其中一組可以宣告 type: url-test，並列出候選 proxies:。核心會對這份清單週期性或依事件觸發進行延遲量測：對每個候選節點試著完成對 url 所指定地址的請求（語意上屬於健康檢查／測速用途），再比較結果挑選當前「最佳」節點作為該策略組的出口。當其他規則把流量導向這一組時，你感受到的就是自動換線。
圖形介面裡的一鍵測速，常常是在同一套概念上再加一層 UI：有時等同手動觸發量測，讀到的仍是「對特定 URL 的請求是否順利與大致延遲」。因此測速再低，也不保證你實際造訪的網站會走同等路由品質——這也是許多人誤會「客戶端騙人」的來源。要把體感做穩，重點反而是：讓 url-test 的決策不要過度敏感，並讓測試 URL不要與你關心的場景完全脫鉤。
第一步：調整 interval（多久測一次）
interval 決定健康檢查的時間間隔（通常以秒為單位理解）。設得太短，節點池會一直被打探針，除了增加無謂負載，也可能讓延遲樣本在短時間內看起來差異擴大——尤其當你同時在下載、雲端硬碟同步或 Wi‑Fi 訊號邊緣工作時。設得太長，自動選線對「真的掛掉」的節點反應會變慢，但在節點品質尚可的環境裡，較長間隔往往換來較少的主觀抖動。
實務上建議先保守後激進：先拉到不那麼激進的值，觀察一小時內是否還會頻繁換線，再決定是否縮短。若你的訂閱模板把 interval 設成極端短的預設值，而你主要用途是長時間視訊或遊戲，第一件事往往是放慢測速節奏，而不是把 tolerance 降到更苛刻。調整後請養成習慣看連線列表：若策略組名稱對應的實際出口仍不斷變更，代表 interval 可能仍太密，或下一步要動 tolerance。
第二步：調整 tolerance（防抖門檻，別為了幾毫秒換線）
tolerance（容差）處理的是「新最佳節點比目前使用中節點好多少才算值得切換」。在延遲量測有雜訊的前提下，若門檻設得太小，系統會在幾十毫秒級的起伏間來回切換——對需要長連線的應用來說，這種切換比「維持在略慢一點但穩定的節點」更糟。把門檻略為放寬，等於告訴核心：除非新節點真的顯著改善，否則別急著動。
直播與線上遊戲情境常常需要更寬鬆的 tolerance：觀眾端感知的卡頓，很多時候來自路徑切換而非單純的平均延遲。相對地，如果你只做偶爾瀏覽、可以接受頻繁挑最快的線，門檻可以較窄——但仍不建議窄到與 jitter 同量級。要替自己的網路找到折衷，可以記錄「連線列表裡出口切換頻率」當成主觀指標：若仍太勤，就再寬一點；若經常卡在明顯慢線不肯換，再略收。
第三步：lazy（延後完整輪詢，減少背景測速）
lazy 的語意可理解成：對某些 url-test 組，在尚未被實際使用前，不要急著對所有候選節點做完整輪詢——等到該策略組真的被規則命中、流量要經過時，再補齊量測。 這能減少「你根本沒在用這條出口，它卻在背景狂測」的狀況，對多組巢狀 proxy-groups 的模板特別有感。
代價是首次命中時可能還在收集延遲樣本：若該組是你最常用的主出口，而你非常在意連線建立當下的首包時間，就要評估是否關閉 lazy，或改以較長 interval 搭配較寬 tolerance 來換取穩定。較不常用、只在特定域名才會走到的備援組，則較常適合開啟 lazy，讓系統把測速預算花在真正會用到的路徑上。
第四步：檢查 url（測速／健康檢查網址）是否「騙了你」
url 指定 health-check 請求要造訪的目標。理想上它應該對大多數候選節點都可達、回應穩定，且不要太容易被單一 CDN 或地理封鎖扭曲成「只有特定節點特別漂亮」。實務上若 URL 與你的主力場景差異太大，會出現「測試永遠綠燈、實際網站卻紅燈」的錯配：這不是自動測速無用，而是指標與目標不一致。
當你發現怎麼調 interval／tolerance 仍覺得體感不對，下一步常是更換測試 URL：選擇更接近你常訪問服務特性的 HTTPS 端點，或改用更中性的檢查位址。要避免使用過於笨重、會被速率限制，或在你所在網路環境頻繁被劫持的位址。若你不確定該用哪一個，可先用保守、通用的位址穩定自動選線，再在「真的只看某一國／某一家影音」時改以手動 select鎖出口，不要為了自動而自動。
在 Clash Verge Rev 用覆寫保存修改（Windows 實務）
直接改訂閱拉下來的主檔，往往在下次更新時被覆蓋。Clash Verge Rev 這類前端通常提供覆寫、Patch、Merge 之類的能力（實際菜單名稱依版本而定），讓你把「只想改幾行 proxy-groups」的需求，獨立保存在本機。工作流程可以想成：訂閱負責節點池與大部份規則，覆寫負責把你認為不穩的 url-test 參數聽你的。
操作時請維持 YAML 縮排正確，且只改你理解的那幾鍵；若合併後設定檔無法載入，核心會拒絕啟動或退回上一版。遇到語法錯誤可對照站內 YAML 解析與縮排排查。完成後建議在規則模式下開啟你常卡頓的網站，搭配連線列表確認流量仍命中預期策略組與節點，而不是誤闖 DIRECT 或被其他規則提前攔走。
什麼時候別再堅持 url-test，改用手動 select？
url-test 適合在「候選節點多、品質時好時壞、你希望大致自動挑快的」情境。但若你的場景有下列任一項，強行自動可能永遠不滿意：一是服務對出口 IP 跳動極度敏感（頻繁驗證、風控，或遊戲伺服器黏著連線）；二是你必須長時間鎖定單一地區觀看內容；三是你已經小到只需要兩三顆穩線，手動選一次即可整天使用。此時把外層規則指向一個 type: select 的策略組，或在內層用手動鎖節點，往往比繼續微調 health-check 更省時。
也可以採混合式：用 url-test 在維護較大的池子時做粗篩，再把出口接到一個 select 讓你自己決定最終落地——自動測速不再「直接掌控最後一跳」，而是幫你縮小候選集合，降低操作負擔。這種拆法在大模板裡很常見，關鍵仍是：讓自動邏輯服務於你的真實場景，而不是被預設模板綁死。
常見問題（對照搜尋意圖）
測速結果上下跳的時候，interval 與 tolerance 先動哪個？
多數家庭的網路延遲本來就會抖動，若你觀察到出口頻繁切換，通常先寬鬆 tolerance，必要時再略為拉大 interval。只有當節點真的經常失效、需要更快剔除壞線時，才優先考慮縮短間隔——但仍要接受更高的切換頻率風險。
那 fallback 組是不是比 url-test 更不會跳？
fallback 類型偏向「先試第一個，壞了才換」，並不是所有版本都與 url-test 的量測邏輯完全一致；是否較穩取決於模板如何寫、以及健康檢查怎麼配置。概念上若你更受不了一直挑最快的線，而比較能接受「除非壞掉不換」，fallback 確實可能更適合某些場景——但仍需搭配合理的檢查 URL 與閾值，見 規則詳解 中的類型比較。
介面測速與設定檔裡的 url-test 會不會打架？
不同前端實作各異：有些 UI 測速使用獨立 URL，有些則讀取組內欄位。若你發現手動測速與自動選線結果長期不一致，請以設定檔與核心日誌為準，確認實際生效的是哪一組參數，並避免同時存在兩份互相覆蓋的 patch。
總結
把 url-test 想成「自動選線器」，你就能有理路地調它：interval 控制多常做健康檢查、tolerance 決定要不要為了微小的延遲變化換路、lazy 讓較少使用的組別別在背景白白測速，而 url 則決定量測到底在量什麼。當這四件事對齊你的實際場景，很多「節點亂跳」其實只是參數與指標沒對齊，而不是 mihomo 或 Clash Verge Rev 本體故障。尚未摸熟介面者，可依序把手順接回 Windows 安裝首跑 與前面提到的日常用法文章，建立「規則—策略組—連線列表」的對照習慣。
相較市面上不少封閉型 VPN只能選國旗、無法核對規則與實際出口，Clash 生態的價值在於你可以審計自己的分流與健康檢查邏輯；一些商用產品為了把體驗包得更「傻瓜」，往往把 DNS、出口與紀錄政策藏在黑箱裡，線路一旦抖動就只能反覆重連，難以判斷是節點問題還是指標被誤導。開放規則與多前端選擇（在 Windows 上便是 Verge Rev 這類仍活躍的圖形客戶端）讓「自動測速」變成可調參數，而不是被迫接受廠商預設——這也是願意多懂一點設定的人能換回的掌控感。