Windows 11 の Clash Verge Rev でプロキシグループと測速を使いこなす実践ガイド

この記事で押さえること(検索の意図)

Clash Verge Revを Windows 11 にインストールし、購読(サブスクリプション)URLまで取り込めた状態から先が本稿の出発点です。いま読者が多く検索しているのは、「画面上のプロキシグループの意味」「URL テスト(あるいは url-test 型グループ)で自動的にノードが選ばれる流れ」「ワンクリックに近い形で並ぶレイテンシ(遅延)の色」「手で出口を決め続けたいときの手動選択まわり」といった日常的な運用チェーンです。総合インストール・設定ガイドでは OS 共通の全貌を説明しましたが、この記事はWindows とプロキシグループ+内蔵測速にレンズを絞って、総覧と題材がかぶらないように書きます。

文言はクライアントの細かな版差によってメニュー名が多少揺れることがありますが、設定の論理モデル(YAML の proxy-groupsは変わらないので、画面上の同名・近い名前の項目に読み替えてください。また「戦略グループ」「策略组」「policy group」と呼ばれる概念は、すべてここではプロキシグループに統一して説明します。購読の入れ方だけ苦労した人ほど、この段から先が体感の決め手になります。

グループとは何か:YAML と画面の対応

バックエンドの Mihomo(旧 Clash Meta) は、実際には購読で落ちてきた proxies の一覧へ、名前付きで出口を選ぶレイヤーを重ねています。そのレイヤーの典型が proxy-groups です。Select 型は常に自分でリストから一つ選び、URL Test 型は url に書かれたチェック先に対して往復レイテンシを試し続け、その中から条件に合った「いま優秀なひとつ」を自動維持します。さらに Fallback(障害検知での切替)や複数選択系(アプリ側の意味づけに依存)など、サービス側のYAMLが増やしているタイプがありますが、家庭・小規模オフィスの Windows 環境では SelectURL Test の二つの理解がほとんどを占めます。

Verge のメインウィンドウやトレイのメニューから開ける一覧は、この YAML のビューを GUI に写したものだと捉えると混乱が減ります。「GLOBAL」を触るか「ルール側で参照されている名前」を触るかの違いは、単に自分がどの上流グループへ命令を送っているかだけの話です。共通の設定用語を押さえるとログを読むのも楽になります。

慣れたら:rules の先頭側で、アプリ単位やドメイン単位で「この通信はこのグループへ」という行が増えている場合があります。画面上で選んだグループだけがすべてを支配するわけではないので、混線しているときはいったんログで「評価に使われたグループ名」を確認すると早いです。

Windows でグループ一覧を開くまでの共通手順

実行中の状態を前提に、アプリのアイコン(タスクバーまたは通知領域)から本体を開き、プロキシ一覧/プロフィール一覧に相当するビューへ移動します。利用版によってはサイドナビやトップタブが分かれていますが、目的は一つです。「いま適用されているプロファイルの下で動いている proxy-groups を一覧し、名前の横に並ぶ出口候補に触れる」ことです。TUN をオンにしているときブラウザ向けシステムプロキシのみでは表に出る接続状態が分かりにくく感じることがあります。TUN の基本概念を押さえると、このあとの「体感と数値がズレる」現象も説明しやすくなります。

Windows 固有のひっかかりとして、ユーザーアカウント制御により管理者昇格ダイアログが出てから初めて仮想アダプタまわりが安定する構成もあります。グループだけ触りたい場面でも、背後ではカーネルが起動して初めて遅延テストのパケットが飛ぶため、先にサービス/コア側の緑点灯に相当する状態を確認するクセが有用です。

手動ノード運用:Select 型グループでの切り替え

  1. 一覧から Select と表示されている、または自分で名前を認識している「手動グループ」(例:🇸🇬 シンガポール手動選択 などサービス側のネーミング)をクリックします。
  2. ノードまたは子グループの名前を選び、反映を待ちます(多くは即時、その後の接続が新経路になります)。
  3. ブラウザで検索サイトを開いたり ipinfo.io 系のサイトを開いたりして、地域表示が自分の狙いとおおむね一致するかざっと確認します(厳密な判定には限界があります)。
  4. サービス側が「ロック」しない限り、この選択は自分のユーザー設定として保持されます。別プロファイルへ切り替えると記憶はプロファイル単位になります。

手動の利点は、ストリーミングやオンライン会議などレイテンシよりも安定した同一出口を維持したいときに、自動ローテーションに振り回されないことです。欠点は、ノード側の朝夕の混雑に自分で気づくまで体感が変わっても出口が自動では追従しないことです。そのバランスを見て、並行して URL テスト系の自動グループへ切り替える時間帯も決めると運用がラクになります。

自動測速側:url-test と画面上のレイテンシチェック

  1. グループ一覧で URL TestAUTO、サービス側が付けた「自動/最適」などのラベルを探します(YAML の type: url-test)。
  2. 一括チェック/全ノードチェック/同じ名前のボタンがある版では、それをクリックすると各ノードについてチェック URL への往復結果が並びます。ない版ではグループ単位での更新アイコンに相当する操作だけのこともあります。
  3. interval が短すぎる購読はレート制限やログノイズの原因になるため、体感が悪いときは自動更新間隔や tolerance(閾値)の設計次第で「すぐ別ノードへ跳ぶ」問題が出ます。これはサービス側の YAML 側の調整になります。
  4. 並んだミリ秒数と色を見ながら、必要なら一時的に別の自動グループ、または上位の Select で「この自動グループを出口に」を固定します。

url-test の意味:テスト対象 URL はサービス側が購読内で指定しているのが一般的で、自分の環境だけで変更できないことが多いです。Google サイトや Cloudflare に近いチェックポイントを使っている例もあり、地域ブロックとのミスマッチがあるとレイテンシが極端に悪く見えるだけ、ということがありえます。その場合はチェックだけでなく実アプリでの疎通を必ずセットで確認してください。

レイテンシの色と数値の読みかた(体感とのズレ)

画面上の緑・黄・オレンジ・赤・灰は、単純なしきい値で HTTP チェック結果をランクしていることが多く、ICMP ping とは一致しません。そのため体感でサクサクなのに数値だけ悪いなどの逆転が起きるのは異常というより統計対象が違うだけです。また Jitter が大きい回線では、その瞬間のサンプルで色だけ見て過剰に切り替えると UX が逆に不安定になります。

Windows 側の Wi‑Fi の省電モード設定、または同時に別の VPN を常駐させているときは、チェックだけが失敗しているというより名前解決または TLS レイヤーでの失敗が混じることもあります。ここまで来たら、ノード一覧が総じてタイムアウトに見えるときの総まとめの章立てに沿って、DNS・UDP・STUN・ログの順に広げていくと早いです。

過信しない:ワンクリック測速は「今このチェック線路が応答したか」の指標であり、BGP 収束後の恒久品質や、特定ストリームのCDN最適選択までは約束できません。「速いゲートに乗れたか」の一次判定として使うのが適切です。

RULE・GLOBAL とグループ選択の連動イメージ

多くの購読は RULE(ルール) モードを既定にしています。そのとき画面上で触るのが「最終的出口に近い層」のグループだけか、上流のGLOBAL に相当する名前かは購読の設計次第です。Globe に近い操作をすると広い経路変更がぶら下がる一方、RULE 側でアプリ単位や国別グループへ振り分けられているときは、その下流の名前を触って初めて目的のサービスだけが別出口へ向かいます。この差はトラブル報告でもっとも誤認されやすいので、自分のYAMLで RULE -> の行がどの名前を参照しているか、アプリまたはテキストで一度だけ眺める価値があります。

ゲーム実況視聴やオンライン会議だけ海外出口へ寄せたい、といった要望があるなら、そのドメイン束をひもづけるサービス側の名前付きグループを探します。名前が増えすぎて迷うときは、まず手元で困っているサイトのFQDN をログから拾って、それがどのルール行とどのグループに当たっているか逆引きすると理解が進みやすくなります。

よくある質問(画面とYAMLのギャップ)

レイテンシは良く見えるのに、特定サイトだけ遅い

A. そのサイトの静的アセットCDNが別リージョンにあり、またはブラウザ拡張と競合している典型です。また fake-ip と実接続経路が食い違うケースでも起きえます。DOMAIN ルールの優先順位と DNS 設定を、目的のサイトにだけ当てているかログで確認すると切り分けが進みます。

自動選択と手動、どちらを常用すべきですか

A. 迷ったら日中は自動(URL テスト系)、安定重視のアプリだけ手動グループ側で固定という二段張りが扱いやすいです。ストリームのロックや銀行系の異常検知がある場合は、プロバイダーのFAQに出口固定の話がないか先に読むと安全側に倒せます。

グループは見えるが候補が空、名前だけ増えて動かない

A. 購読の取得は成功しているが proxies: 側の名前参照が欠けている、プロバイダー側メンテの途中、または手元でプロファイル編集ミスによるコメントアウト等が典型です。Verge で購読の手動更新をかけつつログの HTTP 結果を読み、アウトソースの状態ページがあれば併読してください。購読追加ガイド末尾のチェックリストも再利用できます。

それでも読めないときの短いチェックリスト

  • 時刻:Windows の「設定 → 時刻と言語」で自動同期オン、大きくズレていないか。
  • 競合製品:別ブランドのフィルタ型VPNや広告ブロックの仮想ドライバをいったん停止して再チェック。
  • DPI/企業ゲートウェイ:HTTPS検査環境では証明書ストアへの信頼が必要なときがあり、チェックだけ失敗することがある。
  • ログの英語:diali/o timeoutreject など単語単位で絞って Issue 検索すると似た経緯へ辿れる。
  • Verge とカーネルの版:REALITY/Hysteria2 など新方式はカーネル側の世代差で名前が並んでも実行に失敗するため、総合ガイドの更新節どおり適宜揃える。

まとめ:日常運用に落とす最低限の型

Windows 11 で Clash Verge Rev を使ううえでのプロキシグループ周りは、本質的には「yaml の名前付きレイヤーを画面から触っているだけ」であり、Select で自分の決めた出口を維持するか、URL テストで自動的にチェック結果の良い出口に寄せ続けるか、用途で使い分ければよいだけの話です。Mihomo カーネル側の共通挙動を理解すると、細かなUI変更があっても素早く自分のワークフローを再構成できます。この型を身体に覚えさせてしまえば、あとはルール側の名前を増やしていくだけでも対応半径がぐっと広がります。

一方で、この手のクローズドな単体製品には、画面上は簡素でもルール YAML のバックグラウンド解説や版差し替えガイドが薄いまま売りきりになっているものもあり、ウィンドウだけ追うとグループ命名とログの読みどころに迷い込みやすくなります。オープンな Clash/Mihomo 系ツールチェーンには逆にユーザーが増え、その分だけノード一覧が総じて赤になる原因やRULE連動までを掘る記事が揃っているのが強みです。ClashSourceではクライアント別の読み進め順と共通ドキュメントを噛み合わせて整理しているので、この記事どおりグループ運用を試したあとにも迷子になりにくいです。まだ入口を決めていない方はClashSource のダウンロードページから自分の環境向けビルドを選び、そのまま本稿の手順でグループ一覧とレイテンシを触ってください。Clash/Mihomo 互換クライアントを無料ダウンロードして試すだけでも、画面上の自動/手動切替がはるかに腹落ちしやすくなります。