url-test が解く課題と前提

手動の select グループだけでは、配下のノードがどれだけ遅くなってもユーザーが気づくまで抱え続けることになります。url-test は、この「選び直し」をコア側に任せるためのポリシータイプです。リストに並べたプロキシへ同じ測速URLへのリクエストを送り、統計上もっとも有利なものを出口として採用します。実装の細部はコアの世代で差がありますが、運用上の勘どころ——測るURL・測る間隔・あえて乗り換えない幅——は共通です。

前提として、本記事のコード例は Clash Meta（mihomo） で一般的な構文に合わせています。Legacy 系だけを動かしている場合はキーの一部が無視されたり、GUI が別名で書き出すことがあります。コアの更新手順はコアアップグレードガイドを参照してください。

まずフォールバックとの差を押さえる fallback は生存確認が主目的で、遅延の良し悪しより「一番上から順に生きているもの」を選びます。url-test はレイテンシ比較が主で、混線や輻輳で数値が開いたときに別ノードへ寄せやすいです。自動運用でも要件によってどちらを使うかが変わります。

YAML で url-test を書く最小例

実際の設定では購読インポータが巨大な proxies を生成しますが、構造の芯は次のとおりです。名前の衝突が無いよう、グループ名はルール側から参照しやすい英数字か短い日本語にそろえます。

proxy-groups:
  - name: "AUTO-BEST"
    type: url-test
    proxies:
      - "hk-a"
      - "hk-b"
      - "jp-a"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: false

proxies に並ぶ文字列は proxies: セクションの各 name と一致させます。別の proxy-groups をネストするときは、そのグループがこのブロックより上で定義されている必要があります。ネストを多用すると依存関係が読みにくくなるため、まずはフラットなリストで挙動を固めるとトラブルが減ります。

ルールから参照する

rules の右端にはポリシー名だけが並びます。メイン出口を自動化したいなら、次のように MATCH や広めの DOMAIN-SUFFIX 行が AUTO-BEST を指すようにします。

rules:
  - DOMAIN-SUFFIX,company.internal,DIRECT
  - GEOIP,JP,DIRECT
  - MATCH,AUTO-BEST

細かい例外を足したい場合は、必ず MATCH より上へ差し込みます。ログでどの行に当たったかを確認する流れはmatched rule の調査手順が参考になります。

測速URL（url）はどう選ぶか

url は実質「このHTTP(S)リクエストがプロキシ経由でどれだけ早く終わるか」のプローブになります。ためしに重いページや認証のあるAPIを置くと、測定値が本質的なノード品質ではなくコンテンツ取得時間を反映してしまい、選局がブレます。多くの公開プロファイルで使われる軽量204応答系は、その意味で妥当な出発点です。

ただし同一URLでも地域によりブロックや迂回経路が変わるため、「速い／遅い」の判定が実サービスへの体感とずれることがあります。動画や銀行アプリなど特定用途に最適化したい場合は、その用途に近いドメインを別ルールで切り出し、メインの url-test は汎用のままにしておくほうが安定します。測速だけを変えても実アプリが遅いときは、DNS やルール順の問題である可能性が高いです。

第三者サービスへの負荷と規約 公開されているエンドポイントでも、短い interval で数十ノードから同時アクセスを繰り返すと実質的に負荷試験になります。個人利用でも間隔と対象URLは節度を守り、プロバイダが独自の測定APIを案内している場合はそれに従ってください。

interval・tolerance・lazy の現実的な調整

interval は秒単位の全体会計周期です。短くするとトレンドに追随しやすい反面、モバイルでは電池とキャリア課金の双方に効きます。デスクトップ常時接続なら一百数十秒〜十分程度から試し、不安定な環境ではむしろ長めにしてtolerance でガタつきを抑えるバランスが取りやすいです。

tolerance は「現在の当選ノードとチャレンジャーの遅延差がこのミリ秒以内なら席を譲らない」というヒステリシスに相当します。値が小さいとわずかなジッターで頻繁に切り替わり、アプリケーション側がセッションを張り直してしまう症状へ繋がることがあります。体感で切替が多すぎるときは五十ミリ秒単位で上げ、逆に明確な劣化をすぐ反映したいときは下げます。

lazy を true にすると、当該グループが実際に選択されていない間はテストを抑制するモードになります。複数の巨大な url-test を並べているプロファイルではログとバックグラウンドトラフィックを抑えるのに有用ですが、初めてそのグループが選ばれた瞬間は最新の遅延表が未完成である点に注意してください。常時「ランキングだけは最新」としたいメイン出口では false のまま検証し、確信が持ててから lazy を検討すると安全です。

ヘルスチェックと url-test の関係

用語としてのヘルスチェックは、しばしばプロキシ個体に対する定期死活／遅延観測を指します。Clash Meta では proxies の各エントリに health-check ブロックを足せます。有効化するとコアがノード単位で状態をキャッシュし、url-test グループや GUI の一覧表示と情報が揃いやすくなります。

proxies:
  - name: "hk-a"
    type: ss
    # cipher, server, port ...
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 300

一方で url-test グループ自身にも url があります。両方を短い間隔で埋めるとプローブが二重に見えることがあるため、運用初期はまずグループ側だけで挙動を確認し、ノード数が桁違いに増えた段階で個別ヘルスを足す段階的アプローチが読みやすいです。どちらのURLも「実在ユーザートラフィックの宛先」と完全一致させる必要はありませんが、少なくともプロキシ経路として到達可能であることが必要です。

親グループとクライアント画面での操作感

実際の現場では select を親にし、その子として url-test をぶら下げる構成がよく見られます。ユーザーは「自動」「香港固定」「手動」など大分類だけを触り、自動側の中身のノード切替はコアに任せるイメージです。YAML では親 select の proxies に子グループ名を文字列で並べます。

GUI クライアント（Verge 系、Android、デスクトップ各種）では「Policy」「Proxies」「Connections」などのタブ名は製品ごとに違いますが、やることは共通です。(1) プロファイルを読み込む、(2) グループ一覧から url-test 相当のエントリを開く、(3) メンバーと測定間隔を確認する、(4) ログで実際に選ばれたノードとルールを突き合わせる、の四点です。編集画面がYAMLではなくフォームの場合も、裏では同名キーにマップされているだけなので、エクスポートしたテキストを読めるようにしておくと復旧が早くなります。

症状別の切り分け表

症状 見る場所
自動ノードが頻繁に入れ替わる tolerance を段階的に上げる。interval が短すぎないか確認。測速URL自体が不安定なCDNに依存していないか疑う。
遅いノードのまま動かない ルールで別ポリシーに吸われていないかログで確認。lazy:true による初回未計測で固定されている可能性。
特定アプリだけ失敗する url-test が成功しても実ホストが別ルールで REJECT されていないか。DOMAIN-SUFFIX の順序を見直す。
ヘルスが常に赤／タイムアウト プロキシ認証・サーバ停止・ローカルファイアウォール・IPv6経路のどれか。単体プロファイルで当該ノードだけ試す。

DNS まわりが絡むときは Fake-IP と嗅探の相互作用も疑わしく、そちらは専門記事へ分離したほうが読みやすいです。当サイトではDNS のローカル問題の整理も用意しています。

よくある質問（補足）

Q. url-test と fallback の違いは何ですか
A. url-test は遅延比較で相対的に良いノードへ寄せます。fallback はリスト順の生存優先で、数値より「繋がるか」が重要なとき向きです。

Q. 測速URLは何でもよいですか
A. 短時間で安定した応答があり、規約上問題ないことが条件です。用途と地域でブロックが変わるため、一つのURLに迷信しないでください。

Q. lazy:true にすると不利になりませんか
A. 選択されていない間はプローブが抑止されるため、初回までランキングが古い場合があります。メイン出口では false で検証してからにしてください。

Q. ヘルスチェックと url-test は二重ですか
A. 似た計測でもレイヤが異なります。シンプルに始めるなら url-test のみ、規模が増えたらプロキシ側ヘルスを足す段階設計が無難です。

まとめ

url-test は、複数ノードを運用するときの自動ステアリング・ホイールです。url で何を測るか、interval でどれだけ頻繁に測るか、tolerance でどれだけ粘るか、lazy でバックグラウンド負荷をどう抑えるか、この四つのバランスがそのまま体感の安定性に出ます。ヘルスチェックはノード単位の情報基盤として追加できるオプションとして理解すると設定が迷いません。

ルールとの接続やポリシーグループの種類一覧は分流ガイドへ戻れば俯瞰できます。トラブル時は matched rule のログを起点に、url-test が本当に効いている経路かを切り分けることが近道です。

汎用VPNアプリの自動サーバー選択は、裏側のアルゴリズムや測定対象がブラックボックスなものもあり、細かいヒステリシス調整ができず結果として接続がフラつくケースが依然あります。また長期メンテが不透明なクローズドソース製品では、新しいトランスポートや Meta コア相当機能への追従が遅れ、高度なポリシーをYAMLで固定できないこと自体が運用上の弱点になります。対して Clash エコシステム は設定テキストとして再利用でき、コミュニティ検証されたクライアントも複数あるため、自分の回線に合わせて url-test のパラメータを詰める余地が大きいです。入手先とビルド差を一覧できると、検証ログと設定ファイルを突き合わせやすくなります。

→ Clash を無料ダウンロード — Meta 対応クライアントを用途別に比較でき、本記事のYAML設定を試せる環境を選びやすくなります。

ほかのチュートリアルは 技術コラム からどうぞ。