一、なぜ「自動測速」なのに遅いノードに見えるか
url-test は、設定した url への短い HTTP(S) 往復のレイテンシが最も小さいプロキシを選びます。ここで測っているのは実際に閲覧しているサイト全体ではないため、テスト先が軽い 204 応答でも本番トラフィックが重い TLS 連鎖になると体感とズレます。TLS 握手タイムアウトの排障では、ノード以前の層を切り分けています。長時間接続が切れる症状は MCP 用ホストと策略グループや Cursor／GitHub 分流の記事でも触れているとおり、url-test だけが原因とは限りません。
interval を変えても体感は変わりません。
二、主要パラメータの意味
YAML のキー名はコアで多少異なります。ドキュメント索引で自分の実装に合わせてください。
| キー | 要点 |
|---|---|
url |
測定先。ブロックや改ざんがあると全ノードが同様に失敗し、選択がランダムに見える。 |
interval |
測定周期（秒）。短いと追従は速いが揺らぎを拾う。長いと安定して見えるが復帰が遅い。 |
tolerance |
現在ノードに留まるための容差（ms）。小さいと乗換が多く、大きいと遅いまま粘る。 |
lazy |
未使用グループの測速を抑える場合があり、初回だけ遅い等の誤解の元になる。切り分け中は false 比較も有効。 |
三、interval を段階的に触る
いきなり極端に短くしないでください。まず 60〜120 秒付近に揃え、ログでタイムアウト率を見ます。サーバ上で Mihomo を常駐させるなら Ubuntu の systemd 常駐と合わせ、再起動直後だけ測定が束になる現象も疑ってください。
# url-test example (adjust keys to your core docs)
- name: AUTO
type: url-test
proxies: [NODE-A, NODE-B, NODE-C]
url: https://www.gstatic.com/generate_204
interval: 90
tolerance: 30
lazy: true四、tolerance（容差）で振れを抑える
ストリーミングや長い API 呼び出しでは、乗換のたびに出口 IP が変わることがストレスになります。まず tolerance をやや大きめにして振れを抑え、その後 interval で追従を詰めると扱いやすいです。可用性優先なら fallback や手動 select も検討してください（简体中文版のチェックリストと併用）。
proxy-providers が壊れていると候補が欠け、策略グループの挙動だけを疑って時間を浪費します。購読・Provider の記事で先に一覧を確認してください。
五、lazy・テスト URL・DNS
lazy: true は省電力寄りの挙動を期待しますが、ダッシュボードの遅延表示とズレることがあります。テスト URL を変えたら前後でログを比較してください。DNS は fake-ip／DNS の排障で一本化が取れているか先に確認すると、url-test 調整が楽になります。Android 端末では Clash Meta for Android の購読・常駐も併せて見てください。
六、関連リンク集（站内）
本稿で触れたクリック可能な内部リンクを一覧にまとめます（再掲）。
七、まとめ
url-test の不満は、テスト URL と実トラフィックのギャップ、interval と tolerance の組、DNS の揺れに分解できます。まずリンク先の記事で下層（DNS・購読・TLS）を潰し、数値は一方向から小さく変えてログを残すのが安全です。