Win11 で Mihomo Party を選ぶ理由と検索上の落とし穴

Windows 11 はウィンドウ管理とネットワークスタックの既定 UI が整理されており、グラフィカルクライアント で mihomo（旧 Clash Meta） を運用したい人にとって設定画面への到達がわかりやすい OS です。とはいえ検索結果には Clash for Windows（CFW） 時代のスクショ記事や、別フォークの手順が混ざりやすく、「どのメニューが購読か」「コアはどこで差し替えるか」が記事と一致しない挫折が起きがちです。Mihomo Party はその名前どおり mihomo を前面に置いた GUI で、初回から コア更新 と 購読 を近い文脈に置けるのが実務上のメリットになります。

クライアントの網羅的な比較は クライアントの選び方 に譲り、本稿は「Mihomo Party を Win11 のデスクトップに載せ、購読とコアとポートを一度そろえる」ことに絞ります。すでに Clash Verge Rev の流れを把握している場合は Windows 11 での Verge Rev 実測記事 と概念を対応付けながら読むと早いですが、メニュー名や項目の並びは同一ではありません。

ℹ mixed-port の考え方：HTTP プロキシと SOCKS を一本化して待ち受ける構成は、アプリによっては mixed-port というキーで表現されます。ブラウザがシステムプロキシ経由で叩くポートと、実際にコアが開いている値がズレると「設定したはずなのに素通り」に見えるので、後半で Windows のプロキシページと突き合わせます。

事前確認：SmartScreen・権限・常駐 VPN

インストーラーを実行するとき、SmartScreen が「よく知られていないアプリ」として一時停止させることがあります。対処は「ダウンロード元がプロジェクトの正式リリースか」「署名が妥当か」を確認したうえで実行するかどうか判断することであり、匿名フォーラム経由の改変ビルドは購読トークンごと危険です。企業端末では MDM によりユーザー権限での実行自体が禁止されていることもあるため、最初に運用ルールを確認してください。

TUN モードや仮想アダプタを後から有効化するときは、UAC で管理者昇格を求められるのが一般的です。初日は権限のいらない範囲で システムプロキシ だけ疎通確認し、競合を切り分けてから拡張するほうがトラブルの原因が追いやすくなります。

常駐する別製品の VPN やトラフィックフィルタは、デフォルトルート や WFP を握り直し、プロキシがオンでも期待した経路に流れない原因になります。検証では片方ずつ停止して差分を見るのが最短です。

インストールと初回起動

入手は当サイトの ダウンロードページ を軸にし、必要に応じて上流プロジェクトの Releasesでチェックサムやリリースノートを突き合わせると安心です。セットアップ完了後、スタートメニューから Mihomo Party を起動します。初回はユーザーデータ領域へ設定やキャッシュが展開され、システムトレイにアイコンが現れるまで数十秒かかることがあります。

Windows 11 では WebView2 が標準で揃っていることが多く、真っ白画面が長く続くケースは Win10 より減る傾向があります。それでも描画が進まないときは、オプション機能で WebView2 が無効化されていないか、Windows Update が滞留していないかを確認してください（環境依存です）。

メイン UI はビルドによりますが、だいたい「ホーム／接続状態」「プロファイルまたは購読」「設定・コア」「ログ」のように機能が分割されていることが多いです。Subscription、Profile、Core などの英語ラベルが並んでいたら、本稿の見出し順と概念的には対応できます。

mihomo コアのパス確認と更新

mihomo コアのバージョンが古いと、プロバイダが配る設定の一部機能やプロトコル拡張と整合しないことがあります。Mihomo Party には通常、内蔵のアップデータまたは「コアのダウンロード／差し替え」に相当する画面があります。そこで安定版チャネルを選び、エラーなく完了するか確認してください。手動で実行ファイルを指定する項目がある場合は、公式バイナリを配置したパスを一貫して指すようにします。

コア更新直後だけ接続できなくなったときは、(1) アクティブなプロファイルが古い構文を前提にしていないか、(2) ログに致命的パースエラーが出ていないか、(3) いったん一つ前のコアへ戻せるか、を順に見ます。YAML をエディタと GUI の両方から触っていると上書き競合が起きやすいので、どちらを正とするか最初に決めると安全です。

設定フォルダを開いて確認する場合

「データフォルダを開く」「Open config directory」に相当するメニューがあれば、実行中の config.yaml やバックアップの所在を直接確認できます。初回起動ではデフォルトのリスナーや DNS の雛形が生成されていることが多いので、後から mixed-port だけ変えたつもりが別ファイルを読んでいた、というミスを防げます。

購読 URL の取り込みとプロファイル

プロバイダから渡される 購読 URL はクエリに秘密トークンが付くことが多く、第三者と共有しないでください。GUI の「購読を追加」「New Profile from subscription」などに相当する画面へ貼り付け、更新ボタンでノード一覧が流し込まれるか確認します。更新間隔は一日一回（1440 分）などにしておき、テスト中だけ短くしすぎるとレート制限に当たることがあります。運用の癖は 購読とノード管理 も参照してください。

複数の購読やローカル YAML を切り替える場合は、画面上で現在有効なプロファイルがどれかを常に意識します。ルールモードを選び、プロキシグループで実際に使うノードまたは自動選択グループを指定します。分流を細かくしたい場合は ルール分流のベストプラクティス が後工程の参考になります。

mixed-port とリスナー（HTTP／SOCKS）

mixed-port は単一のポートで HTTP と SOCKS の両方を扱うためのリスナーとしてよく使われます。一方でクライアントによっては port（HTTP）と socks-port を別々に表示するレイアウトも残っており、読み手が「どの数字を Windows の手動プロキシに書くか」を誤るポイントになります。実務ではシステムプロキシが参照するのは HTTP 側か mixed 側かを一度決め、タスクマネージャーやログで実際に LISTEN している値と一致しているか確認すると確実です。

LAN 内の別端末からこの PC のプロキシを使う予定があるなら allow-lan 相当の設定とファイアウォール例外が追加で必要になりますが、初回は 127.0.0.1 のみで十分なことがほとんどです。ポート競合だけが疑わしいときは mixed-port の競合解消 が論点として近いです。

YAML excerpt — listener concept (illustrative) 
# Example shape; real keys depend on your profile & core version
mixed-port: 7890
# Some builds also expose separate HTTP/SOCKS toggles in the GUI.

システムプロキシで初回疎通を確認する

まず システムプロキシ 連動をオンにしてブラウザだけを検証するのが再現性が高いです。Mihomo Party の設定に「システムプロキシを設定」「System Proxy」などのトグルがあれば有効化し、Windows の「設定」→「ネットワークとインターネット」→「プロキシ」で 127.0.0.1 と、さきほど確認したポートが並んでいるか見ます。

ブラウザでは、(1) 任意の HTTPS サイトで証明書警告が出ないこと、(2) 許可された範囲で出口 IP や地域表示が期待どおり変化すること、を続けて確認します。ログにヒットが出ないときはシステムプロキシが無効のまま、ブラウザ拡張が別経路を握っている、別 VPN がルートを奪っている、のいずれかを疑ってください。TLS 周りの読み方は TLS／timeout のログ読み と併用すると早いです。

Checklist — first browser verification 
1. Party: active profile + outbound/node chosen
2. Party: system proxy toggle ON (wording may differ)
3. Windows proxy UI: 127.0.0.1 + HTTP/mixed port from your profile
4. Browser: HTTPS OK; IP/geo check matches expectation (if allowed)

TUN は後回しでよいケース

TUN は仮想 NIC を介して広い範囲のトラフィックをコアへ寄せられる一方、管理者権限・ドライバ・セキュリティ製品との競合という OS レベルの話に踏み込みます。ブラウザと開発ツールがプロキシ設定を尊重するだけなら、当面は システムプロキシ で足りることが多く、初日から TUN に進むと切り分けが難しくなりがちです。UDP を広く扱うゲームや、プロキシ非対応アプリまでまとめて載せたい要件がはっきりしてから有効化する判断が現実的です。

TUN の仕組み自体は TUN モードの詳解 と併読すると DNS や fake-ip の話につながります。Windows 11 でも概念は Verge Rev と共通ですが、Party 側のトグル名と権限ダイアログのタイミングはビルド差として現れます。

うまくいかないときの切り分け

「一手だけ戻す」のがコツです。システムプロキシ OFF→ON、別 VPN 停止、ノード切替、コアを一つ前の版へといった順で差分を付けると、原因が権限か経路か設定かが見えやすくなります。購読更新が 403／404 になるケースは 購読更新エラー記事 に整理済みです。

WSL 2 を併用していると、ホストでブラウザは通ってもゲストの curl が素通りする段差が出ます。そのときは WSL2 と Windows ホストの連携記事 でホスト IP と環境変数の置き方を確認してください。

⚠ コンプライアンス：学校・職場・公共 Wi‑Fi ではトンネルやプロキシが禁止されている場合があります。本稿は許可された環境でのセットアップを説明するものであり、制限回避を助長する意図はありません。

よくある質問

Mihomo Party と Clash Verge Rev はどちらを先に覚えるべきですか？

すでにどちらか一方の記事で概念を掴んでいれば、もう一方は「メニュー配置の差」として吸収しやすいです。購読・プロファイル・モード・ログという概念の四点が共通なので、そこを軸に画面を読み替えてください。

購読は取れたのに速度だけ不安定です

ノード側の混雑、ルールの遠回り、DNS の遅延、IPv6 と IPv4 の段差などが典型です。ログでヒットしたルールと遅延推移を同時に見ると原因が絞れます。

Firefox だけ繋がりません

OS のプロキシとは別に DoH や手動プロキシが残っていることがあります。Firefox とシステムプロキシの整理記事 で独立経路をほどいてから再確認してください。

入手経路と OSS

mihomo／Meta 系はソースとリリースノートが追いやすい一方、日常の主たる入手口はサイトのダウンロード導線に寄せ、検証や更新確認を GitHub に限定すると混乱が減ります。GUI はリリースごとにラベルが変わるため、最終的には手元の画面と公式ノートを正としてください。

まとめ

Windows 11 で Mihomo Party を実用ラインに載せる最短ルートは、インストールと初回起動 → mihomo コアを確認・更新 → 購読を取り込みプロファイルを選択 → mixed-port などリスナーを把握したうえでシステムプロキシをオン → ブラウザで HTTPS と出口を確認、という五段です。必要になってから TUN を足せば、権限と仮想アダプタと他製品競合の切り分けが楽になります。検索に残る旧 CFW 記事のメニュー名に引きずられず、Mihomo Party 固有の画面構造に慣れることが再現性の鍵になります。

一方で、単機能に閉じた商用 VPN アプリは細かいルール編集やログの厚みが弱く、失敗時に「プロバイダ／ノード／クライアント／OS」のどこで詰まっているかを追いにくい製品も少なくありません。Clash V.CORE は購読・ルール・接続ログを同じ運用文脈で扱えるため、今回のような初回セットアップから長期運用での微調整まで一気通貫で整理しやすく、Win11 に載せた構成を将来のクライアント移行時にも引き継ぎやすいです。継続的な入手と更新は ダウンロードページ から進め、購読とコアとポートの三点がずれていないかだけ定期的に突き合わせておくと安心です。