Clash Verge Rev：複数プロファイル・購読更新と規則／全体／直接モードの実務
インストールや初回インポートが終わったあとも、「複数の購読 URL をどう整理するか」「手動で更新するボタンはどこか」「規則モードと全体モードと直接をいつ切り替えるべきか」で迷う読者向けに、Clash Verge Rev とその背後の Mihomo コアを前提に日常運用だけをまとめました。macOS の権限や Windows の初回セットアップは別記事で触れているため、ここではプロファイルとモードに集中します。
プロファイルと購読は別物として整理する
GUI では「プロファイル」という語がファイル単位・構成単位の両方に近い意味で使われがちですが、運用上は次のように分けると混乱が減ります。購読はプロバイダが配るリモート設定の入口であり、URL をクリックしてブラウザに YAML が出るかどうかまで確認したうえでクライアントに登録します。プロファイルは実際に Mihomo が読み込む設定束であり、購読だけでなくローカル編集やマージ結果もここに載ります。複数の会社やコミュニティからリンクをもらった場合、それぞれを別プロファイルとして保存するか、ひとつのプロファイルに複数購読を束ねるかはサブスクリプション設計次第ですが、「今キーボードで選んでいるファイルがコアに載っているか」を常に起点に考えると切り分けが速くなります。
Verge Rev の画面構成はアップデートで文言が変わっても、三段構えは崩れにくいです。第一段階でプロファイル一覧からアクティブな構成を決め、第二段階でその中の購読を更新し、第三段階でダッシュボードからモードとノードを触ります。どこかで詰まったときも、この順番で戻ると「見えている UI と実際に動いている設定がずれている」典型パターンにすぐ気づけます。
複数プロファイルを持つときの実務フロー
仕事用と個人用、あるいは実験用に複数の構成を置く場合、名前規則だけ決めておくと半年後の自分が助かります。たとえば work-stable と home-rule-test のように用途が一目でわかるラベルを付け、メモ欄があればプロバイダ名と契約プランの更新日を書いておきます。切り替え操作そのものは一覧で別行を選んで適用するだけですが、ポイントは切り替え直後にプロキシ一覧が空になっていないかを見ることです。空のままブラウザテストを始めると、単なるノード枯れではなくプロファイル未適用を疑うべき状況まで時間を浪費します。
ヒント
バックアップしたいときは、GUI のエクスポート機能または設定フォルダ内の該当 YAML をバージョン管理しない場所へコピーします。購読 URL 自体は再発行コストが低い一方、ローカルで書いたルールは失うと再現が面倒です。
複数プロファイルを行き来する読者は、依存関係の違いにも注意してください。あるファイルだけレガシーなノードタイプを残している、別ファイルだけ追加のルールプロバイダを有効にしている、といった差は画面の見た目には出にくく、遅延テストの結果だけがバラついて見えることがあります。判断に迷ったら一旦単一プロファイルに絞り、余計な実験レイヤを外してから再度複数構成へ戻すと筋が良くなります。
購読の自動更新と手動リフレッシュ
多くの購読リンクはクライアント側で定期ポーリングできるように設計されています。間隔はサーバー負荷と鮮度のバランスで決まり、GUI では数時間から一日単位のプリセットがよく見えます。それでも手動更新が必要になる場面は普通にあります。プロバイダがメンテナンス明けにノード集合を差し替えた直後、トークン付き URL を再発行した直後、あるいは自分でサブコンバーターを挟んだミラーがキャッシュに挟まって古いままになっているときなどです。ボタンラベルは「更新」「リロード」「Download」のような英語表記のことがありますが、役割は同じで、ネットワーク経由でもう一度設定を取りに行く操作です。
- プロファイル画面で、実際にアクティブな構成が選択されていることを確認する。
- 購読リストから対象 URL を選び、エラーにならないまで手動更新を実行する。
- タイムスタンプやバージョン表示が進んだか、あるいはノード数が期待どおりかを見る。
- うまくいかない場合はコア再起動やプロファイルの再適用を挟んでから再度更新する。
注意
購読ページをブラウザで開いたときにログインフォームや JSON エラーしか出ない URL をそのまま貼っていると、更新ボタンを押しても中身が増えません。必ず「設定テキストとして取れるエンドポイント」かを先に確かめてください。
自動更新間隔を極端に短くしすぎると、プロバイダ側のレート制限に触れたり、自分の PC がスリープから復帰するたびに集中して叩いたりして不安定になります。逆に長すぎるとノードが死んだあとも一覧に残り続け、手動でピックしているつもりが実際には失敗ループに入ることがあります。日常的には十二時間から二十四時間程度を基点に、トラブル時だけ手動で補うくらいが現実的です。
規則モード（Rule）はこんなときの既定値
規則モードでは、ドメインや IP、GEOIP などルールセットに書かれた条件に沿ってトラフィックが DIRECT かプロキシチェーンかが決まります。サブスクリプション提供者が「国内は直行・海外はバックホール」のような前提でリストを配っているケースが多く、その設計をそのまま活かせるのがこのモードの強みです。体感としてはブラウザで国内ニュースや決済サイトを開いても遅延が増えにくく、動画やコードホスティングなど一部ホストだけが自動的にプロキシ側へ寄るイメージです。
規則モードで「意図しないホストだけ遅い」「特定サービスだけ証明書エラーになる」といった症状が出たとき、すぐノードを総取り換えしないほうがよい場合があります。ルールがそのドメインを別ポリシーへ送っている、DNS の書き換えとルール評価の順序が読み取れていない、ブラウザ側のセキュア DNS が別経路を取っている、といったレイヤが重なっているからです。まずは接続ログや Connections 相当の画面で、そのホストがどのチェーンに載ったかを確認し、ルール側のラベル名まで見えるようにすると次の打ち手が決まりやすくなります。
全体モード（Global）は短期の対照実験向き
全体モードはざっくり言えば、ルールによる細かな振り分けより先に「選んだ出口へまとめて送る」状態です。常用すると国内トラフィックまで余計に遠回りすることがあるため、パフォーマンスと安定性の両方でデメリットが出やすいモードでもあります。にもかかわらず現場で何度も使われる理由は、トラブルシュートにおいてルールより上のレイヤを一時的に無効化できるからです。あるサイトだけ開けないときに Global に切り替えて同じノードを使うと開けるなら、優先的に疑うのはルールや DNS ではなくプロバイダ側の出口品質、あるいはそのドメインに特化したフィルタです。
短時間の安全な使い方
- ブラウザの余計なタブを閉じ、テスト対象だけを残す。
- 全体モードへ切り替え、セレクタで出口を一本に固定する。
- 問題が再現するかを確認したら、すぐ規則モードへ戻す。
- ログに残ったホスト名とチェーン名をメモし、ルール側の修正に回す。
Global を長時間放置すると、社内ポリシーや決済フロードで IP 変動が問題になる場合があります。対照実験であることを忘れず、作業が終わったら必ず規則モードへ復帰させる習慣を付けると後悔が減ります。また、セレクタが複雑なプロファイルでは Global でも実際には別レイヤの自動選択が動いていることがあります。その場合は UI 上の文言だけでなく、実際に選ばれたノード名がどこに表示されるかを確認してください。
直接（DIRECT）モードはいつ使うか
直接は、プロキシチェーンを経由せずローカルの既定ルートへ流す指示です。銀行やゲームのランチャー、社内イントラネットなど、プロキシを挟むと逆に失敗するアプリを触るときに選びます。ここで誤解されやすいのは、「モードを DIRECT にしたからシステム全体が直結した」という期待です。OS のシステムプロキシ設定や TUN のルートがまだ Clash を指している限り、アプリによってはまだローカルリスナへ向きます。完全にプロキシを外したいときはモード変更に加えて、メニューバーまたは設定画面のトグル類も順にオフにしていく必要があります。
DIRECT はセキュリティ機能ではなく経路指定であることも押さえておきます。規則モードのままでも特定ドメインは DIRECT に落ちる設計になっていることがほとんどですから、モード自体を DIRECT に固定するより、ルールセット側で理由を明示できるならそちらを整えるほうが長期的には安全です。どうしても緊急で全部を直結させたいときだけ、モードレベルの DIRECT を短期利用するイメージです。
実測と対照実験を組み合わせるコツ
実務では次のような順番が再現性が高いです。規則モードで問題サイトを開き、Connections または同等の一覧に行が現れるか確認します。行がなくてもブラウザだけ固まる場合は DNS やブラウザ拡張を疑い、行はあるがチェーンが期待と違えばルール順序や手動セレクタを疑います。そのうえで全体モードへ一時移行し、同一ノードで改善するかを見ます。改善しないなら出口側またはローカルファイアウォール寄りの問題へ視点を移します。この流れは Android での手動切替検証や OpenClash のポリシー画面での確認とも思想が共通しており、プラットフォームが変わっても頭の中のモデルは使い回せます。
遅延テストボタンはあくまで ICMP や軽い TCP プローブに近く、実アプリの体感とずれることがあります。動画やチャットのような長めのセッションでは、テスト値が良くても実流通路が別ノードにフォールバックしているケースがあります。数字だけ盲信せず、ログに残る実ホスト名と時間軸をセットで見る癖を付けるとよいです。
Verge のボタンと Mihomo API の関係
Verge Rev は背面で Mihomo 互換のコントローラと対話しており、プロファイル適用やモード変更は最終的にコアの状態機械へ反映されます。そのため GUI が応答していてもコアが古いプロセスのまま残っていると、見た目だけ更新されたように錯覚することがあります。購読更新後にノードが変わらない、モードを変えたのにログが変わらない、といったときは再起動やリロードを挟むのが定石です。また外部ダッシュボードから同じ API を触っている場合、Verge 側の表示と数秒ずれることがある点も理解しておくと安心です。
よくある質問（本文での補足）
購読を更新したのにノードが変わらない
ほかのプロファイルがアクティブのまま、あるいは購読は成功しているがマージ結果が別ファイル側で上書きされていない、というズレが典型です。一覧で実際に適用中の名前をもう一度クリックし、コア再起動後にプロキシ数を数え直してください。それでも変わらない場合は、ブラウザで購読 URL を開いて本当に内容が更新されているかをホスト側から確認します。
規則と全体、どちらを常用すべきか
サブスクリプション設計が国内直行を前提にしているなら規則モードが基本です。全体モードは切り分けや強制的に出口を一本化したい短時間用途に留めると安全です。長時間 Global を常用するとレイテンシと請求先ログの両面で想定外になりやすいので、用途が終わったら戻す運用を徹底してください。
直接モードでもブラウザがプロキシ経由に見える
システムプロキシや TUN、ブラウザ独自のプロキシ設定が残っているとそう見えます。OS のネットワーク詳細とブラウザ設定を順に確認し、必要ならアプリを再起動してキャッシュされた接続を切ってください。
関連して読む記事
macOS での権限や初回ウィザードの流れは「macOS で Clash Verge Rev 初回設定」にまとめています。Windows 向けの GUI 導線は「Clash Verge Rev を Windows 11 に入れる」を参照してください。ルールプロバイダの更新間隔やファイル配置をいじりたい読者は「ルールプロバイダの保存先と更新間隔」も関連が深いです。
まとめ
- プロファイルと購読を分けて頭の中を整理し、アクティブな構成を最初に確認する。
- 購読は自動更新に加え、メンテ明けなど必要なタイミングで手動リフレッシュする。
- 日常は規則モードを軸に、切り分けのために全体モードを短時間だけ使う。
- 直接モードは経路指定であり、システムプロキシや TUN の状態もセットで見る。
- 実測では Connections とログをセットで見て、ノードとルールどちらが原因か決める。
選び直しやログが読みにくい GUI に疲れたら
複数プロファイルを抱えるほど、「どの画面が真実かわからない」「ログがバラバラで切り分けに時間がかかる」といったストレスが積み上がります。海外製クライアントのなかには更新が止まっていたり、コミュニティフォークが細分化してドキュメントが追いつかなかったりする例もあり、結果として同じ Mihomo でも運用体感が大きく変わります。
Clash は公式サイトから入手できるビルドとドキュメントを前提に、ログや設定の見通しを崩さないように設計されています。複数構成を切り替える日常的な作業でも、状態が追いやすいほどトラブル時間が短くなるため、長く使うほど差が出ます。
複数購読やモード切替の運用を続けたい方は、読みやすいダッシュボードと安定した更新サイクルがあるクライアントを一度ベースラインとして試す価値があります。Clash を無料ダウンロードし、同じプロファイルを読み込ませて操作感を比較してみてください。