一、現象與你真正想解的問題
典型抱怨包括：策略組顯示已切到「延遲最低」的節點，實際瀏覽卻卡頓；每隔幾十秒就換線，串流或長下載被切斷；以及「測速 URL 很快，上特定網站卻很慢」。這些多半不是單一參數能一次修好，而是探測流量與實際業務流量路徑不一致，再加上 interval、tolerance 的取捨，讓 url-test 看起來「不聰明」。若你同時遇到 TLS 握手長時間卡住，請先並行閱讀 《TLS Handshake 與節點排查》。
三、url-test 在選什麼（與常見誤解）
url-test 會週期性對候選節點向 url 發小型請求，以延遲為主要指標挑出口。它不「知道」你正在上哪個站；因此「探測很快」不等於「所有網站都快」。撰寫 proxy-groups 前請先核對 設定說明 與 訂閱解析，避免名稱對不起來。
四、interval：測速節奏
interval 太短會增加切換與日誌噪音；太長則劣化節點晚才被發現。若你懷疑「首次連線很慢」，請一併檢查 lazy 是否延後第一次測試，並用 TUN／路由文 確認流量真的進核心。
五、tolerance：切換容差
tolerance 太小會在兩三個節點間抖動；太大則可能長時間卡在較差節點。建議搭配日誌一次只調一個參數。長串流場景可參考 YouTube 分流文 的節點固定思路。
六、lazy：何時開始測
lazy: true 常見效果是策略組在被規則使用到之前，不主動輪詢所有成員，可省資源，但也可能讓「剛連上」體感變差。若 DNS／fake-ip 讓命中行為難以解讀，請讀 fake-ip 排查 再回頭調 lazy。
七、測試網址 url：測到的不等於你上的網站
若探測 URL 被攔截或與業務流量路由不同，面板延遲會誤導選線。TLS 異常時請交叉查看 TLS 文，不要只調短 interval。
八、為何最低延遲仍體感差
小請求延遲無法代表頻寬、掉封包或長連線品質。開發者工具鏈可讀 Cursor／GitHub 分流文，理解何時應改 select 固定出口。
九、用日誌對照切換
調 url-test 前，務必用日誌確認規則命中的策略組名稱是否就是你在 YAML 裡改的那個。若節點列表異常，回到 訂閱與 Provider 收斂。
十、建議調參順序
- 確認規則命中與策略組名稱（必要時對照 設定說明）。
- 清理候選節點集合（見 訂閱解析）。
- 檢查探測 URL 是否穩定回應。
- 先調
tolerance抑制抖動，再微調interval。 - 最後檢視
lazy與首次連線體感。
十一、何時改 fallback／select／拆組
需要出口 IP 穩定、長下載或串流不想被切斷時，url-test 可能不是最佳選擇；可改 select 手動固定，或拆組並對敏感業務走獨立策略。串流範例仍推薦讀 YouTube 文。
十二、自查清單
- 日誌中的策略組名稱與 YAML 一致。
proxies:內節點名稱有效（見 Provider 排查）。- fake-ip／DNS 無打架（fake-ip 文）。
- TLS 問題已排除（TLS 文）。
十三、合規聲明
請遵守各站服務條款與所在地法規；本文僅為技術說明，不提供違法用途指引。
十四、小結
url-test 只在探測 URL 上優化延遲；interval、tolerance、lazy 決定「多常測」與「多穩才換」。請善用本文第二節的站內連結清單，搭配 設定說明 與 下載頁 完成實機驗證。