Mihomo Party で規則モード・全体モードを切り替える：戦略グループから手動ノード選択と接続検証
Mihomo Party を入れたあとでも、「規則モードと全体モードをどちらで普段運用すべきか」「戦略グループという名前ばかりが並んで、どこから手動でノードを選べばいいのか」「ブラウザで開いたサイトが本当にプロキシを経由しているかをどう確認するか」という段階で止まりがちです。本稿はMihomo（Clash Meta 系）やClash 互換構成を前提に、GUI が英語でも日本語でも追えるよう状態のモデルだけを統一語彙で整理し、実際にタブやパネルを触りながら検証するときの手順だけに絞ります。インストール手順自体は別稿「Mihomo Party · Windows 10 導入」を先に済ませた読者が、そのまま次のページとして使える並びになるよう意識しました。
モードと戦略グループを頭のなかで分ける
まず混同されやすいのは、「モード（Rule/Global/Direct と呼ばれる帯の切替）」と「YAML の proxy-groups に並ぶ名前（PROXY のような戦略グループ）」です。モードが上流の振り分け方針であり、戦略グループが出口候補の束ね方です。規則モードでは RULE セクションの優先順位にしたがって、あるドメインは DIRECT に落ち、別のホストだけが特定のグループ経由になります。全体モードにすると評価の前景が単純化されやすく、ルールセットの細い枝分かれより先に「選んだ出口へ寄せやすい」状態になります。直接モードや DIRECT に相当する状態は、その名のとおりチェーンへの積載をやめさせる宣言ですが、OS のシステムプロキシや TUN がまだローカルのリスナーを指している限り、アプリ側から見ると「結局 Mihomo が窓口」というレイアウトのまま残る点に注意してください。
Mihomo Party の画面構成はビルドやロケールでラベル表記こそ違っても、アイコンやタブで示される役割関係は他の Mihomo GUI と同型です。プロファイル一覧でアクティブな構成があり、その上に転送モードやシステムプロキシ／仮想アダプタのトグルが乗り、さらに深いところにグループ一覧と接続一覧があります。読者側で迷子にならないコツは、常にこの「縦に積まれた順序」を上から順に確認することです。
規則モード（Rule）が向く日常利用
規則モードは、購読テンプレが「国内サイトは直行、海外のみバックホール」のような設計になっているときに最も効きます。ブラウザで国内ニュースや公共サービスへ飛んだ際の体感遅延を抑えつつ、ルールセットにだけ載ったホストを自動でプロキシへ送れるのが強みです。たとえば動画プラットフォームやクラウド Git、生成 AI の Web だけが自動的に出口へ載る構成は、ユーザーがすべてを手動選択しなくても成立します。その反面、自分で追加したサービスへのルールが追いついていなかったり、RULE-SET が古い GEOIP に依存していたりすると、思わぬサイトだけチェーン経由になりすぎる、あるいは逆に必須サイトが DIRECT で詰まる、といった差分が発生します。
運用ヒント
規則モードを常用する読者ほど、ログとルールセットの対応関係が読めるかどうかでストレスが変わります。名前の意味が不透明なときは、その場でプロバイダの README や RULE-SET に付いたコメントだけでも眺めて「どの粒度で振り分けているか」を掴んでおくと、後からの自分が助かります。
体感が「サイトによってコロコロ経路が変わる」のは異常というより規則設計そのものです。問題になるのは、明らかに国内向けサービスだけが海外出口にぶら下がって決済ログに影響しそうなとき、または逆に開発者向け API が直行のままで遮断されているときなど、意図とズレているケースです。そこでの第一歩はノード総入れ換えより、ホスト単位がどの policy へ送られたかをログで読むことです。
全体モード（Global）を短期の対照試験に限定する理由
全体モードは、ルールと DNS とアプリ側設定が絡んだ複合トラブルで「どこを疑うべきか」がぶれるときに威力を発揮します。特定ドメインだけ開けず、しかし別のサイトは問題ない、という状態で Global に切り替えて単一ノードへ固定すると、ルール評価以前の問題か出口品質かを切り分けやすくなります。たとえば Global で改善するなら、そのドメインに特化したルール順序よりもチェーン側のレイテンシやブロック、アプリケーションが参照する DNS が原因である可能性が上がります。逆に Global でも再現するなら、ローカルのファイアウォール、サードパーティ AV の HTTPS 検査、アプリ側の証明書固定など、アップストリームのプロキシ以前に疑う領域へ視点が移ります。
注意
Global を長時間放置すると国内トラフィックまで迂回し、体感速度とログの両方で無駄が増えます。社内向けサイトやオンライン銀行のようにホワイトリスト型の出口制御があるサービスでは、短時間試験であっても想定外の IP で記録される恐れがあります。対照確認が済んだら必ず規則モードへ戻してください。
画面上は「すべてをまとめる」ニュアンスのトグルでも、実際のセレクタが URL-TEST など複合戦略だったり、親グループの子にさらにローテーションが仕込まれていたりすると、体感と異なるチェーン選択が進むことがあります。Global 試験中も接続一覧に出る実チェーン名を見ながら、UI のラベルと実体が一致しているかを確認することが重要です。
直接（DIRECT）とシステムトラフィック転送は別問題
「プロキシを止めたいから DIRECT にしたのに、アプリによっては変わらない」という質問は定番です。その背景は単純で、DIRECT は設定ファイル上のチェーン選択を直行へ倒すフラグである一方で、ブラウザがまだ設定された HTTP プロキシへ CONNECT を投げ続けていたり、TUN が全体を横取りしていたりすることがあるからです。Mihomo Party でも、ヘッダ付近にあるシステムプロキシ適用ボタンと、仮想デバイス（TUN 相当）ボタンの状態を別々に読む癖を付けるとミスが減ります。銀行アプリや社内 SSO のようにプロキシ越しになるとむしろ証明書で失敗するケースでは、規則をいじらずとも、一時的に転送総トグルだけをオフにするほうが早いときもあります。
「完全直行でテストしたい」場面では、モードだけでなく転送側とブラウザ拡張のプロキシをまとめて見直すほうが再現性が高いです。Chrome のセキュア DNS、Firefox のコンテナ単位設定、開発者ツールの独立プロファイルなど、アプリ側に二重経路があると GUI のモードだけを弄っても挙動が追いかけられません。
戦略グループでの手動ノード選択の進め方
購読が展開すると、画面上には複数の戦略グループが縦長に並ぶことがほとんどです。GLOBAL またはそれに準ずる最上位グループ、PROXY や AUTO、地域別リスト、複数空港を束ねたセレクト型など、アイコンごとに挙動が違って見えます。手動運用では、自動 URL-TEST よりも自分でノードを指名したい場面があります。選択手順としては、アクティブなプロファイルを再度タップまたは適用してからグループリストを開き、目的の親グループだけを触るようにします。子グループに対してだけ選択を書き換えたつもりが、実際には上位の親が別の自動戦略へ戻り続けるといった状態は、アップデート直後によく報告されます。
チェックリスト
- プロファイル一覧で「適用済み」の表示とコア側のログが同期していることを確認する。
- 親グループ（例：
GLOBAL）より、実際に目的トラフィックがぶら下がるセレクト型グループまで辿る。 - 名前と実サーバ情報が両方視認できるときは両方見て選択し曖昧表記のみのときは遅延テストで補助する。
- 選択後すぐ Connections を開いて、問題ホストが新しいチェーン名を指しているかを見る。
「手動でも選べるのはわかるが、どれを触ればサイト全体に効くか」がわからない場合は、まず問題 URL をひとつ開き、そのドメイン行がリストのどこに現れるかを見ます。その行がぶら下がっている policy の名前こそ、その瞬間に実効性のあった戦略グループです。親子関係へ遡れば、画面上の複数グループがどちらから参照されているかが把握しやすくなります。
サイトが経由しているか確認する実測の型
「海外っぽいサイトだから大丈夫」という感覚は外れやすく、CDN のエッジ IP は地理と一致しないことが普通です。そのため Mihomo Party のConnections パネル、あるいは「現在のセッション」に相当する画面でホスト・プロセス・チェーン名の三種をセットで読むほうが信頼できます。確認の型としては、(1) 規則モードで目的サイトだけを開きログに行が出るか見る、(2) グループ変更直後にもう一度読み込みを発生させ、チェーン名が期待どおり切り替わったか確認する、(3) 必要なら短時間だけ Global で固定出口を確認する、という三段が再現しやすいです。開発者ツールのネットワーク列よりも、Mihomo 側コントローラのログのほうが意図した policy を直接示すケースが多いですが、両方見られる環境では突合させると切り分けが早くなります。
「IP チェックサイトの表示が自分の ISP と違えば経由」と割り切るのは応急処置としては楽ですが、DNS レイヤでのジオ不一致や QUIC だけ別経路、といった罠にも注意してください。体感とサイト表示が食い違ったら、ログのチェーン順序と証明書警告の有無、ブラウザのセキュア DNS のオンオフまで含めて横断確認します。Mihomo 系で fake-ip とルールセットの評価順をいじっている場合は、名前解決だけが先行して実チェーンとはズレて見えることもあり、ここでの忍耐強いログ読みが差を作ります。
オンライン会議ツールやゲームなど UDP 偏重アプリでも同じ一覧を見るべきですが、プラットフォームによっては Mihomo が捕まえる前にそのプロセスだけバイパスされています。その場合ログに行自体が現れませんから、「プロキシを通すべきレイヤーを誤っている」可能性を別途疑います。Windows サービス側の名前解決順序まで踏み込む必要があるときもありますが、まず GUI で観える範囲を尽くすだけでも半分以上は収束します。
Clash Verge Rev 利用者との差分を意識する
操作思想は共通でも、名前付けやトグル位置はクライアントごとです。複数環境で行き来する読者向けには、文言ではなく状態遷移のパターンを覚えておくのが楽です。規則と全体・直接の三段、システムへのプロキシ注入、戦略グループの手書き順序という三セットが揃っていれば、どのクライアントでも同じ検証手順に読み替えられます。「Clash Verge Rev のプロファイルとモード運用」でも同種の整理をしているため、両方をセットで読むと用語だけでなく頭のワークフローが一本化されます。
よくある質問
規則にしたのに全部同じチェーンになる
RULE の最終行が catch-all で特定グループだけを指している、あるいは DNS の書き換え結果がすべて同じ GEOIP に分類されている、といったときに起きやすい現象です。ファイルの末尾付近にあるデフォルト行と GEOIP を確認し、アクティブなプロファイルだけを編集対象にしたかもチェックしてください。
手動選択がすぐ戻される
自動フェイルオーバーや定期的なヘルスチェックが親グループにくっついていると、自分の選択が次の評価周期で潰されます。親の戦略型を読み、その挙動を止められる設定かどうかを見極める必要があります。購読更新でテンプレが上書きされた場合も初期値へ戻るため、運用ログに自分の変更を書き留めると復旧が早いです。
遅延テストはよいが実通信は劣化する
テスト ICMP とは別協議、アプリによっては QUIC だけつまる、アップロード帯が枯れるなど複合要因です。一覧の数字だけ見ず、問題アプリだけを隔離したうえでもう一度ログを読みます。
関連して読む
初回導線は Windows 版のステップ説明がある「Mihomo Party · Windows 10 導入」、複数構成を運用するときは「Clash Verge Rev · 規則と全体ガイド」。ルールプロバイダの更新だけ深掘りしたい場合は「ルールプロバイダの保存先と間隔」へ進んでください。
まとめ
- 規則モードで日常運用し、調査目的にだけ全体モードを短時間挟む設計が最も無難です。
- 戦略グループ変更は親子関係を辿ってから行い Connections で実チェーンを確認してください。
- DIRECT は設定上のフラグであり、転送ボタンの状態とは独立に読んでください。
- サイトが経由したかどうかは IP サイトよりログのチェーン証拠が信頼しやすいです。
- クライント横断では名称より状態遷移の型を頭に描くほうが再現実験が速くなります。
UI が読みにくいまま複雑構成を運用していたら
コミュニティ製クライアントは個別に優れた点があっても、プロファイルとログの両方が読めるかどうかで長期運用の疲労が大きく変わります。とくに複数購読を切り替えながら手動グループ運用までしていると、「どこが現実」「どこが単なるキャッシュ」と感じやすく、結局コンソールを開いてトラフィック確認に戻る……という迂回が増えます。更新が細分化されているフォーク群では、このドキュメント断片だけを追うのも負荷になりやすいです。
Clash は公式サイトから入手できるチャネルとガイドを前提にログと設定ファイルの視認性が保たれるよう設計されており、同じ構成でも状態把握にかかる時間が短くなります。問題切り分けに費やす時間は月単位では無視できないため、複雑運用ほど読みやすいダッシュボードに寄せていく効果が大きくなります。
モード変更や戦略グループの読み込みだけでも十分手間になりがちですが、状態が追えるクライアントに切り替えると同じワークフローを浅い認知コストで回せます。Clash を無料ダウンロードし、自分の問題ホストセットで並行比較してみてください。