本記事で押さえること
Clash Verge Rev を Windows に入れたあと、検索でよく出てくるのは「画面は動くがルールモード・グローバル・ダイレクトの意味が混ざる」「策略グループでノードを変えても期待どおりにならない」「接続ログとコア（mihomo）ログの見どころが分からない」「日常はシステムプロキシかTUNのどちらにすべきか」「プロファイルが複数あるときの切り替えで状態がリセットされる」といった運用の問いです。インストールと SmartScreen まわりは Windows 11 向けの導入記事 で整理しているので、本稿はインストール後の GUI とログを軸にした使い方に絞ります。
バックエンドは多くの場合 mihomo（旧称 Clash Meta）であり、YAML の proxies・proxy-groups・rules が実体です。用語の背景は ルール分流の詳解 と、従来 GUI に慣れている方は Clash for Windows 系チュートリアル と対応づけて読むと早いです。クライアントのメニュー名はビルドで変わり得るため、ここでは振る舞いの名前で説明します。
ルールモード・グローバル・ダイレクトを切り替える
代表的な三つのモードは次のイメージです。ルールモード（Rule）は rules の先頭から順に評価され、MATCH まで降りた結果が実際の経路になります。日本語記事やサブスク側の説明で「规则」や split と書かれているのがこれです。グローバル（Global）は「指定されたデフォルト出口にほぼすべてを載せる」近い挙動として理解すると運用が楽です（YAML 上はグローバル用の策略グループへ寄せる構成が一般的）。ダイレクト（Direct）はプロキシを使わず ISP 直下で疎通させ、ルールや DNS の切り分けに使う診断モードでもあります。
日常はルール、特定サービスだけ検証したいときに一時グローバル、「まずプロキシを疑いたくない」ときにダイレクト、という順で覚えると迷いにくいです。切り替えたのにブラウザが変わらない場合は、後述のシステムプロキシや別ツールによる上書きを疑ってください。
MATCH がプロキシ側に寄っている、または上位ルールが広いドメインを覆っていることがあります。接続ログで実際の宛先とCHAINを見ると腹落ちします。
策略グループでノードを選び、ワンクリックで遅延計測する
策略グループ（proxy-groups）は、GUI のドロップダウンやカードに並ぶ「自動選択」「手動」「フォールバック」などの単位です。select 型はユーザーがノードを明示的に選び、url-test は計測 URL に対する遅延が最小のノードへ自動で寄せます（間隔や許容幅は YAML で定義）。fallback は可用性優先で順に試すイメージです。サブスクによってグループ名が「プロキシ」「自動選択」「Apple」「Streaming」など様々ですが、中身はこの型の組み合わせです。
画面にある遅延計測（Latency / 测速）は、各ノードへ小さなチェックを飛ばして結果を並べ替える機能です。数値はあくまでその計測 URL とその時刻での参考であり、長時間の動画やゲームの体感とは一致しないことがあります。地域固定が必要なサービスでは、自動選択より select で国・ASN を固定したほうが安定することが多いです。
接続ログとコア（mihomo）ログでエラーを追う
接続ログ（Connections）には、現在・直近のフローごとに宛先ホスト、ポート、プロセスに近い情報、実際に通ったチェーン（CHAIN）などが並びます。「どのルールに載ったつもりか」を確認するうえで最初に見る場所です。一覧が空に近いのにブラウザだけ遅い場合、トラフィックがそもそも Clash に届いていない（システムプロキシオフや TUN 未適用）可能性があります。
コアログは mihomo 本体の標準出力に近いメッセージで、DNS の応答、証明書検証、拒否、タイムアウト、ルールプロバイダの取得失敗などが載ります。サブスク更新エラーや外部ルールセット取得の TLS 失敗もここに出やすいです。ログレベルを上げられるビルドでは、一時的に詳細へして再現操作を取ると原因が絞れます。ログが読めると、「GUI は正常でもバックエンドだけ死んでいる」ケースを短時間で切り分けられます。
日常利用でのシステムプロキシと TUN の切り替え
システムプロキシをオンにすると、Windows の「設定 → ネットワークとインターネット → プロキシ」に、クライアントが宣言する HTTP／HTTPS／PAC の情報が反映されます。Edge や多くの Win32 アプリはこれを参照するため、ブラウザ中心の作業ではまずここを安定運用にすると楽です。オフのままでは「クライアントのメーターは動くがブラウザだけ直結」のように見えるので、インストール記事のチェックリストとあわせて確認してください。
TUN モードは仮想アダプタ側でトラフィックを取り込み、プロキシ未対応のアプリでも迂回できる反面、管理者権限・サービスコンポーネント・他社 VPN との競合といった変数が増えます。概念と設計上の注意は TUN モード完全ガイド にまとめています。実務的には「ブラウザと開発ツールだけならシステムプロキシ」「ゲームや UDP、プロキシ無視アプリまで含めるなら TUN を検証」と段階を踏むとトラブルが減ります。
複数プロファイル（設定ファイル）の切り替え
仕事用・個人用・旅行用などで YAML を分けている場合、Verge Rev のプロファイル一覧からアクティブなものを切り替えます。プロファイルごとにノード一覧・策略グループの選択状態・ルール集合が変わるため、切り替え直後は「いつもの自動選択」が別のノードを指していることがあります。切り替えたあとにサブスク更新が必要か、システムプロキシ／TUNのトグルがプロファイル単位で記憶されるかはビルド差があるので、その都度ログで実経路を確認する癖をつけると安心です。
サブスク URL のローテーションやローカル編集の運用は サブスクリプション管理ガイド も参照してください。複数プロファイルを使うほど、「どのファイルが今アクティブか」を誤るリスクが上がるため、命名規則を揃えるのが効きます。
簡易チェックリスト（繋がらない／遅い）
次の順で見ると詰まりどころに当たりやすいです。(1) アクティブなプロファイルとサブスク更新の成否、(2) ルール／グローバル／ダイレクトの位置、(3) 策略グループで実際に選ばれているノード、(4) システムプロキシのオンオフと Windows 側表示の一致、(5) TUN 利用時は権限・サービス・競合 VPN、(6) 接続ログ→コアログで DNS／TLS／ルールのエラー。ゲームやボイスチャットで UDP が絡む場合は UDP と TUN の記事 も併用してください。
よくある質問
ルールモードなのに特定サイトだけ開けません。
そのサイト向けのルールがより上の広いルールに飲まれていないか、策略グループが意図しないノードを指していないかを接続ログで確認します。DNS が fake-ip の構成では、環境によっては redir-host 側が読みやすいことがあります。
グローバルでも繋がりません。
グローバルが参照するデフォルト出口がダウンしている、認証エラー、またはローカル側がそもそもプロキシ経由になっていない、の三线から見ます。コアログに TLS ハンドシェイク失敗が続くときはノード側またはローカル証明書検証まわりを疑います。
システムプロキシと TUN、どちらを常用すべきですか？
用途によります。ブラウザ・IDE・パッケージマネージャ中心ならシステムプロキシで十分なことが多く、ログも追いやすいです。プロキシ設定を持たないアプリまで含めて迂回路を統一したい場合は TUN の検証が向きますが、権限と競合の確認コストが上がります。
プロファイルを変えると選択が戻ります。
それは正常に近い挙動です。プロファイルは別 YAML なので、策略グループの選択や一部 GUI 状態は独立します。切り替え後に主要グループを再選択してください。
まとめ
Windows で Clash Verge Rev を日常的に使うコツは、「モード（ルール／グローバル／ダイレクト）がトラフィックの評価順と出口の大方針」「策略グループが実際のノード選択」「接続ログ→コアログが切り分けの二本柱」「システムプロキシと TUNは挟む場所が違う」「プロファイル切替は別世界線に入る」という五つの軸で整理することです。mihomo の YAML を意識すると GUI のちらつきに惑わされにくくなります。
単機能の商用 VPN アプリは設定項目が少なく手早い反面、細かな分流やログの見える化が弱く、仕事とプライベートで経路を分けにくい製品もあります。更新が止まったレガシークライアントは新しい OS のセキュリティ機能とも衝突しやすいです。Clash／mihomo とその GUI はオープンソースでルールや DNS、TUN を自分の回線に合わせて詰められるうえ、コミュニティの知見も蓄積されています。情報の閉じたプロprietary 製品より、設定の透明性と再利用のしやすさを取りにいく価値があるでしょう。