Clash Verge Rev を Windows に入れたあとで挫折しやすいのは、「ダウンロードまでは終わったのに、購読の取り込み・更新がよく分からない」「一覧にはノードがあるのに、体感が変わらない」「プロキシグループ（ポリシーグループ）が複数あって、どこを触ればいいか迷う」といった日常運用の入口です。本記事はインストール手順そのものではなく、購読インポート→プロファイル更新→グループからノードを選択して固定・切り替えまでを、検索しやすい語彙で一枚にまとめます。Windows 11 を例にしますが、同クライアントが動く一般的な Windows でも考え方は共通です。利用はプロバイダー規約と法令を守った範囲に限ってください。
インストール後にやることの全体像
実務的には次の順番が安定しやすいです。(1) 購読 URL を登録してプロファイルを取得する。(2) そのプロファイルをアクティブにする。(3) プロキシグループから実際に使う出口（ノード／チェーン）を選ぶ。(4) システムプロキシやモードを合わせて疎通確認する。(5) 運用に合わせて更新間隔や手動更新の癖を決める。
ここでいう「ノード切り替え」は、単にアプリのどこかをクリックする行為ではなく、設定ファイル（YAML）上で定義されたプロキシグループの選択肢を GUI が投影しているという理解が鍵です。ラベル名はプロバイダーごとに違いますが、考え方は「どのグループが実際の通信経路を握っているか」をログとセットで追うとブレません。
購読・プロファイル・プロキシグループを言い換える
購読（サブスクリプション）は、HTTPS で取得できるノード定義の束です。Clash／Mihomo が読める形へクライアント側で展開され、プロファイルにマージされます。プロファイル更新とは、この購読を再 GET してローカルのキャッシュを差し替える動きを指すことが多いです。
プロキシグループは、複数のプロキシ候補から今どれを使うかを決める単位です。代表的には次のようなタイプがあります（名称は設定側の書き方によります）。
- Selector（選択型）：ユーザーが明示的に選ぶ。固定運用に向く。
- URL-Test（自動選択）：遅延計測などで勝手に切り替わる。体感が「勝手に変わる」原因にもなる。
- Fallback（フェイルオーバー）：生存確認で順番に落ちる。安定志向。
- Relay（チェーン）：多段の経路。レイテンシやログが複雑になりやすい。
初心者がつまずきやすいのは、「画面上 GLOBAL を触っているつもりが、実際には RULE 配下の別グループが効いている」というズレです。後半ではログでの確認も触れます。
ステップ1：購読 URL を追加してプロファイルを取り込む
プロバイダーのダッシュボードから購読リンク（HTTPS）をコピーし、Clash Verge Rev のプロファイル／購読まわりの画面へ貼り付けます。名前は後から探しやすいように日付やプロバイダー識別子を残すとよいです。追加後は取得／ダウンロード／更新相当の操作を一回実行し、エラーが無いことを確認します。
成功すると、設定ツリーに proxies: 由来の候補が増え、プロキシグループの選択肢も実体を持ちます。ここで失敗すると後続のノード選択がすべてガワだけになりやすいので、最初の取得エラーは放置しないのがコツです。
ステップ2：アクティブなプロファイルを確定する
複数プロファイルを試していると、見ている GUI と実際に動いている設定が別になりがちです。一覧でアクティブ（使用中）になっているものが、いまシステムプロキシや TUN が参照している定義です。購読を増やした直後に反映されないときは、(1) アクティブの付け替え (2) アプリの再起動、(3) プロファイルの再選択、の順で確認すると早いです。
ローカル YAML を直接読み込む運用に寄せる場合でも、購読由来の差分をどうマージするかは人手前提になります。基本は購読 URL の一本化か、プロバイダー側のルールセット更新に追従する運用が楽です。
ステップ3：購読・プロファイルを更新する（手動と確認）
購読更新は、ノードの入れ替えやエンドポイント変更を追いかけるためのルーティンです。UI に全体更新や個別更新がある場合は、トラブル時は個別に絞ると原因が見えやすいです。更新後にだけ不安定になるときは、DNS のキャッシュや古いプロセスが残っているケースがあるため、ブラウザより先にアプリの完全終了→再起動を試します。
403／401／タイムアウトなどは、URL の失効やプロバイダー側メンテが典型です。購読 URL は秘密情報なので、貼り付け検証のときもチャットやスクショに載せない運用を徹底してください。
ステップ4：プロキシグループからノードを切り替える
ノードを変えたいときは、まずどのグループが実経路を決めているかを見ます。多くの公開プロファイルでは PROXY／🔰 プロキシ／手动切换 のような名前の Selector がハブになっていますが、名称は固定ではありません。
操作はシンプルで、(1) グループを開く (2) 候補からノードを選ぶ (3) 反映を待つ、です。体感が変わらない場合は、(a) アクティブプロファイル違い (b) URL‑Test がすぐ別ノードへ戻す (c) RULE が別グループを参照している、の三段を疑います。ログ画面で実際に選ばれたポリシーとチェーンを見ると早く戻れます。
ステップ5：ノードを「固定」したいときの運用
固定には二つの意味があります。ひとつは Selector で手動選択し続ける運用、もうひとつは設定側でデフォルトや並びを規定して勝手に動かないようにすることです。後者は YAML の編集が絡むため、GUI だけで完結させたいなら前者が現実的です。
自動系グループ（URL‑Test／Fallback）を挟むプロファイルでは、「昨日選んだノードが翌朝別物になる」ことがあります。安定志向なら、特定用途だけ Selector に寄せる、または計測間隔と許容差を理解したうえで自動群を受け入れる、のどちらかに寄せるとストレスが減ります。
システムプロキシ・モードと切り替えの関係（おさらい）
ノードを上手く切り替えても、OS がプロキシを見ていなければブラウザ以外が変わりません。システムプロキシをオンにしたうえで、モードは通常 RULE を軸にします。GLOBAL は切り分け用途に限定し、普段から常時オンにしない方が安全です。
ゲームや独自スタックのアプリはプロキシ参照がズレやすく、その場合は別記事で触れた TUN を検討します。本記事の要点は、「グループ選択」と「OS がその設定を実際に使っているか」をセットで見ることです。
うまくいかないときのチェックリスト
- 更新後だけノードが消える：購読側で名前規則が変わった、または競合でマージに失敗。ログの YAML エラーを優先して読む。
- 速いノードを選んでも遅い：実経路は別グループ。RULE のヒット先をログで追う。
- ブラウザだけ適切／特定アプリだけ不正：システムプロキシ非対応。TUN かアプリ個別設定。
- 単一支払い VPN と体感が違う：ルール分流により通信ごとに出口が分かれるのが普通。ログで説明がつくか確認。
感覚値を増やす前に、アクティブプロファイル・購読更新結果・実際にヒットしたルール名の三点セットで切り分けると原因がかぶりにくいです。
よくある質問
Q. 購読を更新してもノード一覧が空のままです
A. アクティブプロファイルと取得エラーを見直してください。別プロファイルへ切り替わっている、購読 URL が期限切れ、プロバイダー側で購読が停止している、といったケースが多いです。
Q. グループで選んでも速度や所在地が変わりません
A. 実際に効いているグループが別にあることがあります。RULE に沿ってどのポリシーが選ばれたかログで確認し、ハブになっている Selector を特定してください。
Q. Chrome は速いのに特定アプリだけ遅いです
A. そのアプリがシステムプロキシを読んでいない可能性があります。TUN を試すか、アプリ側でローカル HTTP／SOCKS ポートを明示します。
Q. GLOBAL と RULE はどう使い分けますか
A. 日常は RULE、短時間の切り分けに GLOBAL が無難です。GLOBAL の常時運用は意図しない経路へ寄せやすいので避けてください。
サブスク運用で Clash 系 GUI が向く理由
ワンタップ型の商業 VPN は開始が速い一方で、ドメイン単位の細かな経路制御や複数購読の共存、ログによる説明責任が薄くなりがちです。プロバイダーを変えた瞬間にアプリ側プリセットだけでは届かない要件が出ると、結局 OS 全体設定や別ツールの併用が増えて複雑化します。
Clash Verge Rev のような Mihomo 対応クライアントは、購読更新という現実的なループを GUI に載せたまま、プロキシグループでのノード選択や RULE のログ確認まで一本の操作体系に収めやすいです。「設定ファイルを全部読み込む大作戦」とは角度をずらしつつ、購読とノード操作だけを短期間で身につけたいという検索意図にはフィットします。
もし今まさに Windows でプロファイルを初めてアクティブにした直後なら、まず本記事の順で購読→更新→グループ選択を一周させ、その後で細かいルール調整や TUN の要不要を決めると迷いが減ります。