1. インストールと Windows 側の前提
Mihomo Party はリリース形態に応じてインストーラー（.exe）やポータブル構成などから選べるケースがあります。Windows 11 では初回起動時にSmartScreenが出ることがあり、発行元とハッシュを確認したうえで実行を許可するかどうかを判断します。企業端末では AppLocker や Defender のポリシーにより、署名のないヘルパーやドライバの配置が止まることもあります。個人設定だけでは越えられない壁の場合は、情報システム部門の方針に従ってください。
アーキテクチャはx64（AMD64）が主流です。ARM 版 Windows を利用している場合は、配布ページの対象 CPU とビルド種別を必ず確認します。インストール後はまず通常ユーザーで起動できるかを確認し、システム全体に関わる操作だけを UAC で個別に許可する運用にすると、原因の切り分けがしやすくなります。
パッケージの入手は、更新説明とセットで当サイトのダウンロードページを主な導線にすると、チュートリアル間の用語も揃いやすいです（ダウンロードページ）。ソースや Issue は GitHub で追い、実ファイルの取得は公式に近い経路に寄せるのが安全です。
2. 購読取り込みとコア（mihomo）起動まで
アプリを開いたら、まず購読 URL からプロファイルを取り込むか、既存の config.yaml を読み込みます。URL の扱いやインポートの考え方は、サブスクリプション導入ガイドと同じ流れで問題ありません。プロファイルが有効化できたらmihomo コアを起動し、購読更新の TLS エラーやポート競合がログに出ていないかを確認します。ここが不安定なままシステムプロキシや TUN だけ先に有効にすると、症状が画面とログの両方でちらつきやすくなります。
ルールの落ちどころは ルールルーティング解説と共通です。モード表示と実際のヒット先がずれていると「オンなのに期待どおりに見えない」状態になるため、接続一覧やログでホスト名とアウトバウンドをセットで見る癖をつけると初日から楽になります。
Mihomo Party 特有の画面ラベルはビルドで多少揺れますが、プロファイル選択 → コア起動 → 代理の有効化という大枠は mihomo 系クライアントで共通です。用語が違っても、この三本柱だけは崩さないようにすると迷子になりにくいです。
3. システムプロキシがすること・しないこと
システムプロキシをオンにすると、Windows のWinHTTP／WinINet 系のプロキシ設定が、mihomo が公開しているローカルポート（多くの構成で mixed-port や別途の HTTP ポート）へ向きます。システムのプロキシ設定を尊重するアプリケーションは、追加の手作業なしで Clash 側へ流しやすくなります。初日の検証では権限負荷も TUN より軽く、想定外の挙動も追いやすいことが多いです。
一方で、環境変数のプロキシを読まない CLI、独自スタックのネイティブアプリ、プロキシを明示オフにしているソフトは、システムプロキシだけでは取りこぼします。「ブラウザは速いが curl や特定ゲームだけ変」という差が出た時点で、TUN を検討するか、アプリ側へ直接 HTTP(S)_PROXY を指定するかを決めるとよいです。
ブラウザが独自の「セキュア DNS」をオンにしていると、プロキシ経路とは別レイヤで名前解決が動き、症状だけが不自然に見えることがあります。後述の DNS 節とあわせて、OS・ブラウザ・mihomo の三層を同時に疑うと早いです。
4. TUN モードと Wintun の位置づけ
TUN モードは、OS に仮想ネットワークアダプタを作り、ルーティングやフィルタのレイヤでトラフィックを mihomo 側へ引き込みます。Windows では多くの実装が Wintun に相当するカーネル側トンネルに依存します。アプリがプロキシを無視していても、OS がフローを仮想 IF へ送れる構成なら、システムプロキシより広くまとめて扱えます。ゲームランチャーや一部開発ツールのようなプロキシ非対応がちなソフトの一括扱いに向きます。
代わりに管理者承認・ドライバ導入・他 VPN やセキュリティ製品とのルート競合が増えやすくなります。設定次第ではプライベート LAN までトンネルに吸い込むため、bypass ルールや DNS の設計がより重要になります。概念の整理は TUN モード解説も参照してください。
Mihomo Party 側のトグル名称は「TUN」「システム拡張」などビルドで表記が変わることがありますが、仮想 IF が立ち、ルートが書き換わる点は同じです。ログに Wintun 関連の失敗が出たら、ドライバの再配置や競合 VPN の一時オフを先に試すのが一般的です。
5. どちらから試すか：判断の軸
初回は（1）コア起動とプロファイル確認 →（2）システムプロキシをオン →（3）取りこぼしが残るなら TUNの順が現実的です。いきなり TUN まで一気に有効にすると、UAC・ドライバ・他 VPN の三つが重なり、原因の切り分けが難しくなりがちです。
| 観点 | システムプロキシ | TUN モード（Wintun 系） |
|---|---|---|
| 主な仕組み | OS のプロキシ設定をローカルポートへ向ける | 仮想アダプタとルーティングでフローをコアへ集約 |
| 向いている例 | ブラウザ中心、プロキシ対応アプリが多い用途 | プロキシ無視アプリを含めてまとめたい用途 |
| 権限・設定負荷 | 比較的軽い（環境による） | 管理者承認・ドライバ・競合確認が増えがち |
| 典型トラブル | 一部アプリだけ直結のまま | 他 VPN や DNS と競合、LAN 取りこぼし |
常時別の VPN を-on にしている場合は、二つの「全系トラフィック系」が同時有効になりやすく、どちらか一方を切ってから検証すると時間を節約できます。ルールで国内や社内を直結に回していても、実際にアプリがどの経路を踏んでいるかがずれると「ルールは正しいのに効かない」ように見えます。
6. TUN を初めてオンにするとき（UAC・競合）
TUN を有効にすると、初回に ユーザーアカウント制御（UAC）のプロンプトが出ることがあります。ルーティングテーブルや仮想アダプタの操作は標準ユーザーだけでは完結しない処理が混じるためです。ダイアログを無視したままでは「トグルだけオンで挙動が変わらない」状態が続きやすいので、続行するか意図的にオフに戻すかをはっきりさせます。
Wintun が未導入・破損していると、仮想アダプタ生成に失敗しログへエラーが残ります。アプリの案内に従ってドライバを再配置するか、一度関連コンポーネントを消してから入れ直すのが一般的です。企業環境で未署名ドライバが全面的にブロックされている場合は、管理者承認なしには完了しません。
Microsoft Store 由来の UWP で挙動が変わるときは、Clash TUN・UWP ループバックの記事も参照してください。デスクトップ Win32 とネットワークパスが一致しないケースがあります。
7. DNS と「一見つながらない」症状
プロキシや TUN が動いても、DNS だけ別経路だと名前解決が失敗したり、特定サービスだけ証明書やリージョン判定がおかしくなったりします。mihomo では fake-ip と redir-host の組み合わせが結果に直結します。Windows の DNS クライアントキャッシュや、第三者セキュリティがリゾルバを握る構成も見落としがちです。詳しい比較は fake-ip 対 redir-host の記事が参考になります。
実務的な順序は、（1）接続ログでホスト名が出ているか、（2）期待するアウトバウンドにマッチしているか、（3）同じ名前を nslookup や Resolve-DnsName で見た答えが一貫しているかです。ここで答えがブレているときはプロキシ以前の問題です。スリープ復帰後だけ壊れるときは、仮想アダプタの再接続順や他 VPN の再接続タイミングも疑います。
8. よくあるトラブルと対処の順番
ブラウザだけ通る：システムプロキシのみで、対象アプリがプロキシを見ていない可能性が高いです。TUN を試すか、アプリ個別設定を確認します。すべて止まる：コア停止、ポート競合、ルールの誤配線、上流認証の誤りなどを疑い、いったんシステムプロキシと TUN を両方オフにしてローカルポートへ直接当てられるかを確かめます。
TUN オン直後だけ LAN 共有が切れる：プライベート帯を直結へ逃がすルールが必要な場合があります。LAN 共有の記事は別論点ですが、「ローカル宛をトンネルに入れない」発想は共通です。開発ツールだけおかしい：シェルに古い HTTP_PROXY が残っていないか、WSL が別ゲートウェイを見ていないか確認します。コンテナからホストの代理を使う場合は Docker ホスト経由の記事も参照してください。
購読取得だけ失敗し続けるときは、Windows の購読 TLS／DNS ログ稿で TLS と名前解決を切り分けると早いです。mihomo のログに残るホスト名をそのままクエリ比較に使うと再現が速くなります。
9. Verge Rev など他稿との補完関係
同じ Windows 11 でもクライアントが違えば画面の呼び方は変わりますが、「システムプロキシで足りる範囲」と「TUN でレイヤを上げる判断」は Clash Verge Rev でも同型です。UI 付きの兄弟稿として Windows 11 の Clash Verge Rev 初回設定を併読すると、用語の対応表が頭の中でできあがります。移行の俯瞰は CFW 代替ガイドが担い、本稿はMihomo Party にフォーカスした初日のチェーンに絞っています。
macOS 側の権限整理は macOS の Verge Rev 稿と対になる読み物です。OS が違っても「まず軽い方から確かめる」手順は再利用できます。
10. よくある質問
一般的な論点のみに絞ります。構成やプロバイダーにより答えは変わります。
- Mihomo Party と Clash Verge Rev は何が違いますか。
- どちらも mihomo コアを GUI で動かしますが、画面構成や設定の出し方、更新リズムが異なります。Win11 での代理の原理は同じなので、本稿のシステムプロキシ／TUN の考え方はそのまま使えます。
- システムプロキシだけで十分なことは多いですか。
- ブラウザ中心なら多いです。プロキシを無視するツールやゲームで困り始めたら TUN やアプリ個別設定を検討します。
- TUN をオンにすると UAC が出ます。無視しても大丈夫ですか。
- 多くの場合、キャンセルしたままでは期待どおりに切り替わりません。続行するなら許可し、不要なら TUN をオフに戻してください。
11. まとめ
Windows 11 で Mihomo Party を初めて使うときは、コアと購読を健全な状態にしてからシステムプロキシでブラウザ等を確実に通すところから始め、取りこぼしが残るなら TUN でレイヤを上げる順が切り分けにも設定にも優しいです。UAC や Wintun のメッセージは途中で放置せず、完了させるか意図的にオフに戻すのが重要です。ログでホストとアウトバウンドが追える状態にしておくと、DNS とルールの問題も同じ画面から追えます。
mihomo 系の GUI は複数あり、表示やダウンロード導線・更新できばの差で運用体感が変わります。ダークパターンな取得元に振り回されず、説明が揃ったページからパッケージを選べるクライアントであれば、インストールと購読の手戻りが減り、本題のルールと DNS に時間を使えます。逆に、画面遷移が多くログが読みづらい実装だと、初日から「設定は合っているはず」という錯覚が生まれやすく、トラブルが長引きがちです。環境に合うビルドを入手し、購読と分流を固めたうえでシステムプロキシと TUN のバランスを取るのが近道です。 → 無料で Clash をダウンロードし、快適な接続体験を試す
関連記事 · 同じテーマ
トピックの近さで選んだ関連記事 — 同じカテゴリの Clash 実践ガイド。
Windows 11 で FlClash を導入：購読インポートとシステムプロキシの初回設定（mihomo）
Win11 で FlClash を初めて使う手順。購読、mihomo コア、システムプロキシをオンにしてブラウザを代理経由にするまで。
続きを読むWindows 10 に Mihomo Party を導入：システムプロキシと TUN モードの初回設定、Wintun とよくあるエラーまで
Win10 で Mihomo Party 初回設定。購読・システムプロキシ・TUN／Wintun・UAC。Win11 稿と役割分担。
続きを読むWindows 11 に Clash Verge Rev：システムプロキシと TUN の初回設定、Wintun・UAC・よくあるエラー
Win11 で Verge Rev をゼロから。インストールと SmartScreen、購読取り込み、システムプロキシだけで足りるケースと TUN が要るケース、Wintun・管理者承認、DNS・UWP・LAN まわりの切り分け。macOS 稿・CFW 移行稿・UWP 稿と補完。
続きを読む