狙いと前提

Clash Verge Rev にサブスクを入れたあと、GUI の「自動選択」や類似名前の策略グループが数分おき／数十秒おきにアイコンやラベルを切り替え、視聴中のライブ配信でリバッファリングが走ったり、ゲームでだけルートが揺れたりすることがあります。原因の多くは「出口そのものより、url-test による計測と切り替えの設計」にあります。本稿は mihomo／Clash Meta 系バックエンドで一般的な proxy-groups のうち型が url-test のブロックだけにフォーカスし、interval・tolerance・lazy とヘルスチェック用 URL を、YAML 直編集またはMerge／Patch（覆い書き）でいじって安定側へ寄せる手順です。画面上の総合ガイドは Windows での Verge Rev 活用ガイド、ルールの背景は ルール分流の深掘り記事 に譲り、ここでは一点突破で書きます。

なおすべてのチェックリストと数値が万能ではなく、提供者のサーバ一覧・あなたの回線・アプリの転送モードまで含めた総合問題であることは明示しておきます。とはいえ「まず自動選択グループだけ静かにする」フェーズとして、本稿のレバーだけで体感が変わるケースは多いです。Windows 向け GUI だと理解しやすいので説明はそこへ寄せますが、YAML の項目名はプラットフォーム共通です。

proxy-groups の url-test がやっていること

url-test 型のグループは、列挙したプロキシ候補に対して定期的に小さな到達チェックを実行し、その結果にもとづいて「いま勝ち」のノードを選びます。GUI の「自動」「自動選択」「自動 URL テスト」などの名前は実装によりますが、アクティブな設定の YAML で type: url-test を探すと、思想は一本化されています。url（または環境により別名へ写る）はすべてのメンバーで共通の計測先として使われ、ここへの往復レイテンシが比較軸になります。

interval はその計測の周期（秒単位）、tolerance は「現在採用中のノードから、ほんのわずか速いだけの別ノードへすぐ鞍替えしない」ためのゆらぎ抑制（ミリ秒差の解釈に使われる想定）、lazy が true のときは、そのグループが実際にトラフィックで触られるまでヘルスチェックを強く進めない、というニュアンスとして覚えると運用ミスが減ります。仕様細部はコアバージョン差があり得るため、迷ったら同一バージョンのドキュメントを併読してくださいが、体感調整としての読みはこの順で問題ありません。

画面上の一覧遅延（Latency）とは別物です。一覧の計測が Google でも、グループ本体の url-test が社内CDNでも、両者が食い違えば自動選択だけ妙に踊ります。url の文字列が何を見ているか、必ずグループ単位で確認してください。

interval と tolerance の詰め方

interval を短くしすぎると、「わずかに速い」を拾いにいく試行が頻発しやすく、結果としてグループが視覚的にも実経路ともに細かく揺れます。まず現状より長めへ引き伸ばすことから始めると、ライブ視聴のように長めのTCPセッションが主体の用途では効きやすいです。逆に異常検知までが遅いと感じたら段階的に短くし、接続ログで「ほんとうにリンクが途切れたのか」「計測失敗だけなのか」を切り分けます。tolerance は複数ノードが同じ URL にほぼ同タイで返っている環境ほど効きます。極端に狭い許容しかないと、「最速」が入れ替わるたびにスイッチ、「少し広げるだけで急に安定」という崖が出るので、開始値は広めへ置き、配信・アプリ両方で滑らかさを確認してから締めるのが安全です。

両方まとめて触るときのおすすめ順序は、(1) interval で切り替え頻度の上限を下げる、(2) まだ細かければtolerance で「鞍替えに必要な差」を上げる、の二段です。どちらも上げ過ぎるとダウンしたノードへ留まり続ける時間が長くなるトレードオフがあるので、異常検知より安定優先／可用性優先のどちらを取るか、用途ごとに分けられれば理想です。

lazy の意味とオンオフ判断

lazy: true は、アイドルに近いproxy-groupsに対して、クラスタ全体の並列チェックを減らす方向に働きます。ノートPCやモバイル回線など細い出口では、チェックだけで帯域を食う問題を軽くできます。反面、初めてそのグループにトラフィックが乗ったタイミングで計測が走るため、「最初の一発だけ遅れる」体感が増えることがあります。ゲームのアプリ側が短いタイムアウトを持っている場合、その一度目をどう許容するかはケース次第です。false にしておけばグループ単位での先回り計測は進みやすく、体感の用意は良くなりがちですが、候補の多いプロファイルほど電源／CPU／回線ログのコストも上がります。入口となるメイングループだけ false、奥のグループは true、と階層で分けるのが現実的です。

ヘルスチェック URL がズレているサイン

計測先がクラウド事業者の「軽い到達チェックページ」だけだと東京リージョンしか見えず、視聴するCDNは別ASNへ振られている──といったとき、url-test の勝者と実コンテンツの勝者が食い違います。その場合は、tolerance と interval をいじっても統計ゆらぎだけが残ります。url は HTTPS で小さめの応答が返り、すべてのノードから到達できることを前提にしてください。視聴品質との相関を上げたいなら、そのサービスの実ドメイン系へ寄せがちですが、アクセス規約やエッジ側の応答コードの変化にも注意してください。ログに短時間だけ 403 や証明書まわりの失敗が出るなら、その URL は避けます。

計測用 URL を業務で禁じられたドメインへ置くのは組織ルール次第です。自前のオブジェクトストレージ上の既定ファイルや、許可リスト内の軽いエンドポイントなどへ置くと運用が楽です。

Verge Rev で YAML／Patch に反映する要点

アクティブな設定が単一YAML直編集だけで済むときは、アクティブプロファイル本文の proxy-groups: 以下で該当ブロックへ interval／tolerance／lazy／url を足すか値を書き換えます。しかしサブスク更新が上書きする構成では、そのまま保存しても二度目の取得で潰れることがあります。Clash Verge Rev は設定の統合レイヤーを持つビルドが多く、提供者の離れた断片へローカルの差分だけを載せるPatch／Merge／プリペンド的な機能を利用してください。画面上の名前は開発ラインによりますが、「最終的にコアへ渡るYAMLにこのキーがあるか」をエディタのプレビューまたは生成結果で確認することが重要です。Patch は JSON Pointer ／マージの方言差があるので、一度小さく当てて反映→再起動またはリロードで実体を読み、その後に_tolerance や_lazy を増やしてください。

変更を入れたあとは、ダッシュボード上の自動選択グループだけでなく、コアログ側に計測失敗やTLSエラーが出ていないかを短時間ウォッチします。ウィンドウ操作の全貌は前述の Windows 活用記事 のログ章とセットで読むと手戻りが減ります。 

# Example proxy-group block (YAML). Adjust paths and names for your profile.
proxy-groups:
  - name: "AUTO-JP"
    type: url-test
    proxies:
      - "node-a"
      - "node-b"
    url: "https://www.gstatic.com/generate_204"
    interval: 120
    tolerance: 120
    lazy: true

自動が向かないときは select へ退避する

url-test は平均的には便利ですが、次のときはselect 型グループへの置き換えや、親グループ側で上流から手動固定するほうが早いです。(1) 実トラフィックがUDP中心で、ICMPや小さめHTTPチェックとの相関が薄いオンラインゲーム。(2)SNI別ルーティングにより、チェックより本番ドメインのほうが往復が異なるサービス業務。(3) 複数CDNが時間帯ごとに最適解が入れ替わり、自動追随がユーザー体験としてはノイズになるケース。その場合でもルールセット全体は複雑のままでよく、問題のグループだけ select を挟むだけで頭打ちすることがあります。親子のグループチェーンを頭に描きつつ、`rules` がどこでその親を叩いているかを 分流の詳解 で追うと、迷子になりにくくなります。

よくある質問

tolerance を上げても細かく切り替わる

interval がまだ短い、またはチェック対象 URL が不安定／ブロック／リダイレクト多発で結果がガタついているときに典型的です。tolerance と interval を両方いじっても片方だけでは足りない状態か、URLを替えるべきかをログで確認します。

lazy は常時オンで無難か

「省エネ側に倒す」のが基本トーンですが、最初の体感を重視する入口グループはオフ側も検討してください。オンにしたときの「一度目だけ遅い」を許容できるアプリだけをその親にぶら下げます。

YAML を直接いじったらサブスクで消える

アップロード元の自動生成結果へ直書きしていると再現します。Patch かローカルの重ね置きへ運用変更し、アクティブ合成のソースを一覧で把握してください。

ゲームだけルートが揺れる

url-test とUDPゲームとは設計上好きに相関しないことがあります。TUN とルール、DNS、fallback を別問題として切り、必要なら UDP・ゲーム関連の記事 と併読してください。この記事だけでUDPロスまで完治するわけではありませんが、「自動グループだけ静かにする」のは十分射程に入ります。

まとめ

Clash Verge Rev におけるurl-test 型グループは、mihomo が解釈する interval・tolerance・lazy と共通のヘルスチェックURLの設計により、体感のノードぶれを大きく左右します。proxy-groups の単一ブロックにレバーを集約して順に広げれば、視聴・業務ともにログで追える形に寄せられます。配信／ゲームの実トラフィックと計測先が離れ過ぎているときは、この記事だけでは限界があるためselect や別レイヤーを検討してください。

V2Ray系のオールインワンGUI商用クライアントの一部は自動ノード評価の中身がブラックボックスで、ユーザーがチェック間隔やしきい値をYAMLレベルで固定しづらい製品もあります。更新が細く、機能追加より課金導線が先行するクローズドソースのサービスでも、体感は日々変わりにくいものです。Clash／mihomo とオープンなGUI は、ルールとDNS、グループ構成を自分の環境へ寄せられるうえ、コミュニティの知見と検証ログを蓄積しやすく、機能の説明可能性という意味でも長期運用に向くことが多いでしょう。閉じたプロダクトに振り回されるより、透明性と再現可能なYAMLへ寄せていくほうが、回線調整という面倒ごとにもつながります。

→ Clash を無料でダウンロードして、快適なネット環境を手に入れよう