url-test 在做什麼？與 select、fallback 的實務差異
在 Clash 系列核心中，策略組（proxy-groups）是規則表與實際節點之間的「橋」：規則只決定「這類流量交給哪一個組」，真正用哪個 proxy，由該組的 type 決策。select 完全手動；url-test 則會對清單中的候選節點（或子策略組）週期性發起對測速 URL的請求，依延遲與可用性挑一個當前出口，達到自動選快線與簡易故障切換的效果。
與 fallback 相比，url-test 更偏向「在多名健康候選之間挑延遲較佳者」，而不是嚴格按清單順序找到第一個可用就停。實務上若你的候選節點品質相近、只是希望日常自動挑低延遲，url-test 很常見；若你明確要「優先固定用 A，壞了才換 B」，則 fallback 或外層再包一層 select 手動鎖定，有時更直覺。
rules 裡的出口寫成策略組名稱，日後調整自動測速成員時不必全檔重寫。若你尚未複習 rules 由上而下命中與 Rule Providers，建議先看《Clash YAML 規則分流完全指南》再回來細修本組。
proxy-groups：url-test 的鍵名與 YAML 骨架
下列為常見可直接改寫貼上的骨架（組名與節點請替換為你設定檔內已存在的名稱）。不同核心版本對少數欄位預設值可能略有差異，若以 mihomo 為準，下列欄位在社群設定檔中最常見：
proxy-groups: - name: "自動測速-日常" type: url-test proxies: - "香港-01" - "新加坡-02" - "日本-03" url: "https://www.gstatic.com/generate_204" interval: 300 tolerance: 50 lazy: true
url：健康檢查請求的目標位址。常見是使用回應極短的 HTTP 204 或類似端點，讓延遲量測穩定且節省流量。請避免改成會重導向多次、會回大包內容、或在你所在網路常被攔截的網址，否則延遲數字會與實際體感脫鉤。
interval：輪詢間隔（秒）。設太短會增加後台連線與機場側觀察到的頻繁重試；設太長則故障切換變慢。對一般筆電或手機客戶端，數百秒級別是社群常見起點，再視節點穩定性微調。
tolerance：容忍範圍，用來抑制「毫秒級差距造成的來回切換」。當新低延遲節點沒有顯著優於現用節點時，維持原選可降低抖動與握手抖動對應用程式的影響。
lazy：為 true 時，策略組在尚未被實際流量命中前可能減少主動測速頻率，對「訂閱內建了非常多 url-test 組、但你日常只用到少數幾組」的情境較為友善。若你希望一啟動客戶端就看到幾乎所有組的延遲刷新，可依需求關閉或改以客戶端內建的「全域測速」操作補強（名稱因客戶端而異）。
select 手動備援。
健康檢查實際上怎麼跑？故障切換要如何心理預期
核心對每位候選節點發起的請求可視為輕量的連通性抽樣：能通、且延遲在當輪結果中較佳者，就成為這一刻的優先選擇。這不是對每條規則、每個連線都做了完整頻寬測試；因此你才會看到某些情境下「介面顯示綠燈、網頁卻仍載入很慢」——那可能與 DNS、目標 CDN、TLS 協商、QoS，或規則把流量導到其他策略組有關。
當某一節點連續對測速 URL 失敗或超出合理延遲，url-test 傾向在下一輪量測中改選可用候選；若池中僅剩單一路徑可用，會表現為「自動切換卡住」——此時並非 url-test 壞掉，而是資料面本就沒有替代路徑。對照這種情況，應優先確認訂閱是否過期、餘額，或出口本身被對站封鎖，而不是無限縮短 interval。
若你希望把「自動選線」的限制講得更白：url-test 並無法保證永遠幫你挑到對 Netflix／ChatGPT／公司 VPN 最理想的那一跳，它只對你配置的測試目標忠誠。要讓結果貼近真實使用體驗，核心是測試目標與路由策略是否與規則層對齊，再配合日誌觀察實際命中的規則與出口。
候選可以是子策略組嗎？與規則引用的常見排版
url-test 的 proxies 清單除了節點名稱之外，也往往能放入其他策略組名稱，形成「自動測速池裡再放一層手工選組」的結構。這種排版在進階訂閱中很常見，但也會讓排查變複雜：當你看到延遲跳動時，要找的是最深層真正承接連線的那一個 leaf。
在 rules 區塊請維持習慣：先處理內網／本地／明確直通，再放你想細分的業務線，最後才 MATCH 兜底。將不同場景對應到不同策略組命名，可避免「為了偷懶全部 MATCH 到同一個 url-test」，結果所有流量都跟著同一套測速目標決定出口。
rules: - DOMAIN-SUFFIX,google.com,自動測速-日常 - MATCH,自動測速-日常
以上僅為示意：請勿不假思索地把所有網址導向同一組。實際檔案中通常會再插入 GEOIP、內網直通、串流媒體或 AI API 類規則。需要對照規則命中與 FINAL 兜底時，可延伸閱讀MATCH 規則與日誌排查一文，把「url-test 選誰」與「規則把流量送去哪個組」兩個層級分開思考。
客戶端怎麼操作？視覺化介面裡最常見的四件事
無論使用 Clash Verge、mihomo party 類圖形客戶端，或直接在面板中檢視，實務上通常會碰到以下情境：
- 重新整理延遲：多數 GUI 會提供單組或全域的重新測速按鈕，用來在換網路／換機場線路後強制刷新顯示。若你開啟了
lazy，啟動當下的延遲欄可能尚未完整，並不代表節點失效。 - 檢視當前選中節點：在自動組上，介面通常會標示目前對外連線所使用的候選與最近一次延遲。若發現規則已命中該組、但連線仍以意外節點出口呈現，下一步應對照是否還有其他規則或 DNS 將子請求分流。
- 編輯訂閱與設定檔合併：部分訂閱會自動生成大量預設 url-test 組名與固定的測速 URL。若你不想被供應商的測試目標挾持，需在合併後以覆寫檔或在 UI 中以進階編輯調整組定義本身，而不只是切換規則顯示順序。
- 與 Tun／系統代理並用時的確認：系統級代理或虛擬網卡在啟動失敗時，可能導致你誤判為「url-test 全紅」，實際是本地轉發未建立完成。對 Windows／macOS 可另參考 TUN／系統代理差異類教學，避免把問題歸因在策略組鍵值。
常見誤區與排查：為什麼「延遲看起來正常」卻仍常斷線？
這類問題很少能靠單一參數「神奇修復」，但可依下列順序縮小範圍：
- 對照規則命中：確認目標請求是否真的走進你認為的那一個策略組；被更上層規則或 DNS 特例提前帶走時，調整 url-test 本身不會有效果。
- 對照候選池中是否混入不相容協議節點：例如某些站點或客戶端模式對 UDP／TLS 指紋敏感，自動選到不喜歡的路徑可能造成應用層逾時而非測速失敗。
- 更換或增加第二個測速 URL 做對照：社群常見備援目標可多擇一並同時觀察；若僅在某一 URL 上大面積失敗，比較像路徑或封鎖，而非整組候選節點同時不可用。
- 調整 tolerance 而非盲目縮 interval：頻繁重測對手機電量與機場觀感都不友善；應先降低切換靈敏度，再在必要時才把間隔調到合理更低的值。
- 分場景拆分 url-test：對長連線、串流或大檔傳輸，可把「自動測速組」細分，不要與對延遲極敏感的即時會議混在一起。
當你從「只靠感覺換節點」過渡到「對照規則、對照自動組選線邏輯」之後，很多看似玄學的現象，其實只是規則層與健康檢查層的資訊沒對齊造成的錯覺。
簡答整理：lazy、tolerance、測速 URL 的最小可行記憶法
若你不想背完整文件，可把下列三句話當作工作記憶：測速 URL 決定「量哪條尺子」；interval 決定多久量一次；tolerance 決定差不多的時候要不要換個新節點。lazy 則像是在說：沒用到的組先別急著一天到晚量給你看。
進階玩家會再把「尺子」準星對準自己常用的目標國家／服務 CDN，並在規則層為不同尺子各自開一張表。這樣一來，url-test 才真正成為自動化的日常工具，而不是訂閱產生的裝飾欄位。
寫在最後：把自動選線變得可維護、可驗證
把proxy-groups裡的 url-test 寫對，只是把「自動選節點」這件事變成一個可被核心預測的流程；接下來你能不能長期跑得穩，還要看訂閱品質、本機 Tun／DNS 環境與規則是否自相矛盾。
市面上不少泛用代理／「一鍵工具」對策略組細節能見度低，調整粒度往往停留在開關層級，問題發生時很難還原是測速目標失真、規則搶命中，抑或節點池本身不可用。相較之下，沿用 Clash／mihomo 生態並搭配能清楚編輯設定檔、檢視日誌的客戶端，通常較能把選擇權交回使用者；ClashNote 所整理的下載來源即以「核心較新、可查 log、對設定檔透明」為取向，適合願意多花幾分鐘換來長期省心的人。
若你想把全文架構放回更大張的地圖，請回到技術專欄鎖定「規則分流配置」類文章；並可延伸閱讀Clash YAML 規則分流完全指南與Fake-IP 與 Redir-Host 解析路徑，把 DNS 與自動選線放進同一張排查表。