Clash Verge Rev 在 Windows 11 上設好 url-test 策略組：健康檢查間隔與容差逐步拆解

本篇適合誰：準備細調自動選線，而不是再找安裝圖文教學的你

若你已經在Windows 11裝好Clash Verge Rev，也確認Mihomo（Clash Meta）能載入訂閱、規則，甚至用過本站另一篇偏重「點到哪裡、怎麼看延遲顏色」的策略組與批次測速內容，下一步往往會撞上更棘手的體感問題：明明按了測速有綠燈，實際上網時卻出站節點一直換，或是應該自動挑最低延遲的策略組卡住不動、直到你手動去點別條伺服器才真正變順。

這類現象最常與proxy-groups裡類型為 url-test 的策略組有關：它不靠你每次手動決定，而是由核心週期性對底下的候選項目做小型 HTTP 類健康檢查，再用最近一次量到的延遲與tolerance（容差）共同決定要不要換人出站。你已經有泛用的 Win11 策略組與測速總覽、以及 TUN／接管語境補強；本篇只做單點對焦：url、interval、tolerance（並帶到你可能看到的lazy）要如何對齊你的網路型態與對「穩定」的定義。DNS、fake-ip、Sniffer等更大拼圖若仍卡住，請搭配 Verge Rev Windows DNS 專文與本站其他 DNS／UDP 類排障頁並行閱讀。

術語對齊：文末與對話常以「策略組」「Proxy Group」「proxy-groups 條目」混用；在設定檔裡一律以 YAML 區塊 proxy-groups: 為準。規則只會引用其名稱，不會自動幫你把 url-test 換成你想要的探測參數。

為什麼規則寫得很好，自動選線卻像在猜拳？先看 url-test 做了什麼

在 Mihomo／Meta 家族的語意裡，url-test是proxy-groups 的一種 type，底下會列出一組可被選來當出站的成員：可能是直接的伺服器 (proxies:)，也可能是別的策略組。群組對外只看起來是一個出站點名稱（例如自動選）；背後核心則為每個候選維護一份量測延遲並依規則定期或惰性更新。

與你在介面上批次點燃測速按鈕不同，background 這條自動健康檢查鏈條完全由設定檔主導：探測要連哪個 url、每隔幾秒 interval、好到什麼程度才值得你從現在選中的人換過去（tolerance）。若任一項與你家網際網路的實際抖動／封鎖對不起來，你看到的就是要嘛永遠黏在過期的好節點名單裡，要嘛視覺上延遲差沒有很大卻一天到晚換出站。

lazy（懶載入）在部分發行版會出現在群組級設定：語意上可以想成「群組不忙時就少打擾探測」，把背景請求集中到真的有流量進來或較長時間未更新時。實際支援與鍵名以你當前核心版本對照官方文件為準；若發現調了數值表象沒差，很可能是訂閱重新合併時又蓋過或鍵被你放在錯的縮排位階——這時請回到合併後完整 YAML搜尋關鍵字確認。

心智模型：把 url-test 想成「用低成本 ping-pong HTTP 探針來猜哪條對外快」，而不是替你驗證「YouTube／Netflix 今天是否順」。若你的痛點是影音串流的實際串流 CDN，仍要規則層級對域名分流正確；url-test只管哪個 SOCKS／HTTP outbound 對探針來說毫秒較友好。

url、interval、tolerance 各自吃什麼設定？會怎麼影響行為

url：對候選出站逐一發出小量請求並量端到端時間。常見要求是對任何節點都能順利走完 TCP＋TLS＋很小的 HTTP payload。常見地雷包括：站台對資料中心 ASN 過敏、只允許特定 User‑Agent／地區 CDN、或對高頻 probe 回傳非典型狀態碼。不是越「國際級大牌」就一定適合拿來給每台機房做自動健康檢查；你要的是在你的節點池裡方差較小的量尺。

interval：兩輪對同一群組自動探測之間下限間隔語意（秒）。設太短：頻繁 Wi‑Fi 切換／筆電省電調頻／Windows Defender 首次掃描都會放大抖動數據。設太長：實際上節點已經變慢許久你才慢慢跟上，體感像自動選是假的。實務上多數環境會從一分鐘到數分鐘級起步，再配合下面的容差細調；請別把這個數字誤會成「我上網也會這麼頻繁被重導線路」——那是在tolerance 許可下才可能換。

tolerance：最常被新手忽略、卻對「會不會一直跳自動選伺服器群組底下那條細線名稱」最直接的旋鈕。可以把它視為：新候選比你現在出站好的程度，要大於這個毫秒門檻，才值得自動切換。設小等於對延遲變化非常敏感：KPI 上好看，但觀察列表裡出站名會像跑馬燈；設大則傾向黏在原選中的人，體感穩但對「這條其實已經比別人慢一截」反應遲鈍。

以下為示意結構，請依你實際 profile 合併結果調整，勿把註解符號原封不動貼進正式 YAML：

proxy-groups:
  - name: AUTO-SELECT
    type: url-test
    proxies:
      - node-A
      - node-B
      - node-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

像 https://www.gstatic.com/generate_204 這類體積極小、全球邊緣多的端點常見於教學與發行範本，但並非放諸每家節點商都無爭議：極少部分環境對 Google 資產有政策或 DPI 介入，此時你看到的就是全池 timeout與自動選形同崩潰。正解是換成你確認所有節點都能順利達到的替代 probe，並在改動後用連線紀錄與規則命中對照出站是否仍合理。

訂閱覆寫風險：若你的「單機覆寫」只做在會被下一次遠端更新洗掉的位置，本篇教的微調會看起來像鬼打牆回溯。長期可用的作法通常是：可版本控管的本地 merge 檔、或由你明確掌握的 patch 編排，細節取決於你如何託管規則；本文不重複講每家託管工具的 UI。

在 Windows 11／Clash Verge Rev 上怎麼改到這三段參數？

  1. 動手前先備份：對使用中設定檔做檔案層級複製。若你也要改訂閱以外的大型規則，請維持單輪只有一類變更以利除錯。
  2. 打開對的編輯器：在 Verge Rev 裡進入設定檔編輯或你慣用的外部編輯器銜接流程，目標是看到合併後完整 YAML（至少包含 proxy-groups: 區塊），而不是只看到某個遠端片語。
  3. 精準搜尋名稱：對照規則裡對外引用名稱，例如 PROXY、♻️ 自動選擇 或服務商自訂英文字串，再在檔案中搜尋 type: url-test 對應的那一段。
  4. 先動 url 再動時間參數：如果你懷疑探測目標對節點池不公平，請優先確認 url，再調 interval／tolerance。否則你只是在對壞的量尺做細膩刻度。
  5. 儲存後重載核心的儀式感要有：改完請用 Verge Rev 提供的重載／重啟核心確定記憶體態樣已不是舊的快取；並在接下來數分鐘少用「馬上連點十次測速」干擾你對自動行為的觀察。
  6. 用連線紀錄對照出站：找一個會走該自動策略組的對照域名或應程式（必要時短暫 Global 或規則診斷模式），確認實際選中的細項名與體感一致；若對 DNS 類副作用有疑慮，並行閱讀 節點全紅與 DNS／UDP 排查。

實戰調參劇本：先判斷你是「太愛換」還是「太不換」

情境 A：出站名稱一直跳、某些網站握手階段卡一下又恢復。
先把tolerance溫和上調（例如數十毫秒一階試），並檢視interval是否太短導致你量到的是環境嘈雜而不是伺服器品質排序。若你已經把 tolerance 拉大仍跳，請質疑 probe url對某些節點是否會週期性失敗：失敗條目在演算法語意上等於被懲罰成延遲極糟，會逼得核心不停重排。

情境 B：明明隔壁朋友同訂閱更快，你自動選卻死守單一路由。
請反向檢視tolerance是不是過大、或是interval過長讓資料老化。第二層猜疑是：lazy／使用節奏讓你看到舊結果；第三層則是你根本規則沒有如你想像那樣走這個自動群組——請用連線紀錄對齊規則命中順序與 GEOIP／DOMAIN‑SUFFIX ，而不是只調延遲參數。

情境 C：測速全綠、但實際串流 CDN 載入很慢。
請離開本篇單點，往域名分流規則、規則優先級、是否在錯的策略組上做 url-test 那條問題鍊條上游移動。Mihomo 能做的是在既有規則命中的出站池裡幫你挑看起來快的一條線，不是幫你用魔法把對某影片 CDN 的地域路由單獨修好。

為什麼我提 Windows 11 而不是抽象講桌面？因為此版本常與Wi‑Fi 省電、快速切換基地台、背景 Windows Update、以及與 WSL2／Docker Hyper‑V 虛擬介面共存一起出現；這些都會讓短期 RTT 波動比有線固定網更戲劇化。tolerance在筆電上通常要稍微寬鬆一點才不會對每一格訊號變化作過度反應。

Windows 11 桌面上容易被誤會成「自動選壞掉了」的外在因素

系統電源與網卡驅動省電：若你在拔除電供時才特別會跳線路，可把現象並行記錄，必要時對網卡在裝置管理員裡調整省電管理模式（不同機型詞彙略異）；這不是 Mihomo Bug，但在tolerance 偏小時會被你誤讀為節點商不穩。

競爭性代理／VPN：當另一家 VPN 或聲稱強化遊戲連線的工具同時劫持路由或 Winsock LSP，TUN 視角下你看到的延遲量測可能對任何節點都不具判讀價值。建議對照環境下先只留下一種接管機制再調 url-test。

防火牆與 SmartScreen：若你是在儲存檔案環節受阻而不是連線異常，那是另一種流程；對於 outbound probe，企業級防火牆有時會針對高頻小 HEAD 發特徵告警，此時你看到的就是間歇 timeout，應換 url 或請網路管理員對檢查放行策略。

若想先把RULE／GLOBAL 對照心法補強，可看 瀏覽器與系統接管差異梳理；若對端口占用／mixed‑port 導致的「載入 YAML 但其實沒全起來」，本站另有對應專文可依關鍵字索引。

常見問題（濃縮）

我可以替每個節點各自給獨立的健康檢查網址嗎？

在url-test群組級這一層，一般語意上是全池共用一支量尺 URL；若你希望對不同國家出站用不同 CDN 探針語意，往往需要拆成複數策略組再在規則上分流，或回到fallback／load-balance等其它類型設計。Mihomo 文件會是最終依據，請以現行鍵支援表為準。

我找不到 type: url-test ，只看到 selector，怎麼辦？

selector是手動類，不會幫你做背景自動對齊：它不讀本篇這三鍵的背景節奏。要嘛請上游範本提供自動群組，要嘛你在自己可控的 YAML中複製範本語意並承擔風險地新增一組 url-test，再把規則引用對過去。改壞規則請永遠有離線可用的備援檔案。

這跟 UDP／遊戲語音 jitter 是同一件事嗎？

不完全是。url-test 探測多數走TCP‑上的 HTTP／HTTPS語意。FPS／語音對 UDP jitter 敏感的場景可能會出現：TCP probe 很好看但 UDP RTT／掉包不好看。此時本篇參數只能讓你不用手動換 TCP 出站，要處 UDP 品質問題仍要回到節點供應、線路品質或規則是否對遊戲流量走對策略組。

合法合規：請在您所在地與服務條款允許的情境下使用代理人工具與測試流量；本站僅就Mihomo 設定語意與桌面操作做技術向說明。

結語

Clash Verge Rev把mihomo 核心包成桌面視窗後，你仍然要面對同一套資料結構的真相：url-test不是神奇的最佳化 wizard，而是把「對探針來說看起來不錯的出站」在背景維護好；tolerance則決定你能不能在 RTT jitter 充斥的現實世界裡換得一份心理與體感上的安定。

相較市面不少速成貼會把tolerance說成一個冷冰冰數字複製大法，卻不重視url是否對你整池節點公平，結果讀者把所有現象統稱為「自動選弱智」。ClashSource將安裝、訂閱、策略組介面總覽與本篇單點 YAML 對照拆開來寫，讓你可以在不混淆問題層級的前提下，先對齊量尺，再細調間隔與容差。

若你希望先有透過本站整理的可信用戶端入口，再沿用本文順序重做一輪 url-test 微調，不妨到 免費下載經整理的 ClashSource 相容用戶端 ，將健康檢查網址、interval、tolerance對齊自己的網際網路型態後，再回來用連線紀錄驗收成站穩定性。