Windows 10 に Mihomo Party を導入：システムプロキシと TUN モードの初回設定、Wintun とよくあるエラーまで

1. インストールと Windows 10 側の前提

Mihomo Party はリリース形態に応じてインストーラー（.exe）やポータブル展開などから選べるケースがあります。Windows 10 でも初回起動時にSmartScreenが表示されることがあり、発行元と入手経路を確認したうえで実行を許可するか判断します。社内 PC では AppLocker や Defender のポリシー、古めのフィルタリング製品が、ヘルパーやカーネルモードのコンポーネント配置を止める例があります。個人設定だけでは越えられない場合は、情報システムの方針に従ってください。

アーキテクチャはx64（AMD64）が主流です。ARM 版 Windows 10 をお使いの場合は配布ページの対象 CPU とビルド種別を必ず確認します。バージョンは 1903 以降を想定した記述が多いですが、実務では21H2／22H2 のような後期リリースに近いほど、仮想アダプタまわりの挙動が安定しやすいという雑な相関があります。いずれにせよ「更新プログラムが極端に古い端末」は、TLS まわりや証明書ストアだけ先に整えた方が購読取得からスムーズです。

インストール後はまず通常ユーザーで起動できるかを確認し、システム全体に関わる操作だけを UAC で個別に許可する癖をつけると、原因の切り分けがしやすくなります。パッケージの入手は、更新説明とセットで当サイトのダウンロードページを主な導線にすると、チュートリアル間の用語も揃います（ダウンロードページ）。

2. 購読取り込みとコア（mihomo）起動まで

アプリを開いたら、まず購読 URL からプロファイルを取り込むか、既存の config.yaml を読み込みます。URL の扱いは サブスクリプション導入ガイドと同じ流れで問題ありません。プロファイルが有効化できたらmihomo コアを起動し、購読更新の TLS エラーやポート競合がログに出ていないか確認します。ここが不安定なままシステムプロキシや TUN だけ先に有効にすると、症状が画面とログの両方でちらつきやすくなります。

ルールの落ちどころは ルールルーティング解説と共通です。モード表示と実際のヒット先がずれていると「オンなのに期待どおりに見えない」状態になるため、接続一覧やログでホスト名とアウトバウンドをセットで見る癖をつけると初日から楽になります。

Mihomo Party の画面ラベルはビルドで多少揺れますが、プロファイル選択 → コア起動 → 代理の有効化という三本柱は mihomo 系 GUI で共通です。用語が違っても、この順序だけは崩さないようにすると迷子になりにくいです。Win10 ではタスクバー常駐とスタートアップの挙動がブラウザやセキュリティ製品とぶつかり、コアが静かに落ちているケースもあるため、トレイアイコンの状態とログをセットで見ると安心です。

3. システムプロキシがすること・しないこと

システムプロキシをオンにすると、Windows のWinHTTP／WinINet 系のプロキシ設定が、mihomo が公開しているローカルポート（多くの構成で mixed-port や別途の HTTP ポート）へ向きます。システムのプロキシ設定を尊重するアプリケーションは、追加の手作業なしで Clash 側へ流しやすくなります。初日の検証では権限負荷も TUN より軽く、想定外の挙動も追いやすいことが多いです。Windows 10 の「設定」→「ネットワークとインターネット」→「プロキシ」で、手動プロキシやスクリプトの状態が想定と違っていないか確認すると、別ソフトが上書きしている典型に早く気づけます。

一方で、環境変数のプロキシを読まない CLI、独自スタックのネイティブアプリ、プロキシを明示オフにしているソフトは、システムプロキシだけでは取りこぼします。「Edge は速いが 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 の一時オフを先に試すのが一般的です。Win10 に限らず、法人向けエンドポイント製品が仮想 NIC の作成をブロックする例もあるため、その場合は TUN を諦めてシステムプロキシとアプリ個別設定に寄せる現実的な落としどころもあります。

5. どちらから試すか：判断の軸

初回は（1）コア起動とプロファイル確認 →（2）システムプロキシをオン →（3）取りこぼしが残るなら TUNの順が現実的です。いきなり TUN まで一気に有効にすると、UAC・ドライバ・他 VPN の三つが重なり、原因の切り分けが難しくなりがちです。

常時別の VPN をオンにしている場合は、二つの「全系トラフィック系」が同時有効になりやすく、どちらか一方を切ってから検証すると時間を節約できます。ルールで国内や社内を直結に回していても、実際にアプリがどの経路を踏んでいるかがずれると「ルールは正しいのに効かない」ように見えます。

6. TUN を初めてオンにするとき（UAC・競合）

TUN を有効にすると、初回に ユーザーアカウント制御（UAC）のプロンプトが出ることがあります。ルーティングテーブルや仮想アダプタの操作は標準ユーザーだけでは完結しない処理が混じるためです。ダイアログを無視したままでは「トグルだけオンで挙動が変わらない」状態が続きやすいので、続行するか意図的にオフに戻すかをはっきりさせます。

Wintun が未導入・破損していると、仮想アダプタ生成に失敗しログへエラーが残ります。アプリの案内に従ってドライバを再配置するか、一度関連コンポーネントを消してから入れ直すのが一般的です。企業環境で未署名ドライバが全面的にブロックされている場合は、管理者承認なしには完了しません。

Microsoft Store 由来の UWP で挙動が変わるときは、Clash TUN・UWP ループバックの記事も参照してください。デスクトップ Win32 とネットワークパスが一致しないケースがあります。Windows 10 でも Store アプリ比率が高いプロファイルでは、この稿のリンクが効くことがあります。

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. Win11 稿・Verge Rev 稿との補完関係

同じ mihomo コアでもクライアントが違えば画面の呼び方は変わりますが、「システムプロキシで足りる範囲」と「TUN でレイヤを上げる判断」は共通です。OS を横断して稿を分けた例として、Windows 11 向けの Mihomo Party 初回設定は UI 前提や周辺機能の言及を Win11 に寄せています。本稿はWindows 10 に残る端末の検索意図に合わせ、設定画面の言い回しや残存環境での注意を厚めにしています。

クライアントを Mihomo Party ではなく Clash Verge Rev に寄せる場合は、Windows 10 の Clash Verge Rev 初回設定が兄弟稿です。移行の俯瞰は CFW 代替ガイドが担います。Win11 環境へ移行した後は、対応する Win11 側の稿へ読み替えると用語のズレが減ります。

10. よくある質問

一般的な論点のみに絞ります。構成やプロバイダーにより答えは変わります。

Windows 10 向けに Win11 の Mihomo Party 稿を読み替えれば足りますか。

原理は同じですが、端末分布や設定 UI、周辺の注意が違うため、OS 版を固定した本文の方が手順追いやすいです。日々触るのが Win10 なら本稿、新規購入マシンが Win11 なら兄弟稿を先に読むと迷いが減ります。

Mihomo Party と Clash Verge Rev は何が違いますか。

どちらも mihomo コアを GUI で動かしますが、画面構成や設定の出し方、更新リズムが異なります。Win10 での代理の原理は同じなので、本稿のシステムプロキシ／TUN の考え方はそのまま使えます。

システムプロキシだけで十分なことは多いですか。

ブラウザ中心なら多いです。プロキシを無視するツールやゲームで困り始めたら TUN やアプリ個別設定を検討します。

TUN をオンにすると UAC が出ます。無視しても大丈夫ですか。

多くの場合、キャンセルしたままでは期待どおりに切り替わりません。続行するなら許可し、不要なら TUN をオフに戻してください。

11. まとめ

Windows 10 で Mihomo Party を初めて使うときは、コアと購読を健全な状態にしてからシステムプロキシでブラウザ等を確実に通すところから始め、取りこぼしが残るなら TUN でレイヤを上げる順が切り分けにも設定にも優しいです。UAC や Wintun のメッセージは途中で放置せず、完了させるか意図的にオフに戻すのが重要です。ログでホストとアウトバウンドが追える状態にしておくと、DNS とルールの問題も同じ画面から追えます。

mihomo 系の GUI は複数あり、表示やダウンロード導線・更新頻度の差で運用体感が変わります。不透明な取得元に振り回されず、説明が揃ったページからパッケージを選べるクライアントであれば、インストールと購読の手戻りが減り、本題のルールと DNS に時間を使えます。逆に、画面遷移が多くログが読みづらい実装だと、初日から「設定は合っているはず」という錯覚が生まれやすく、トラブルが長引きがちです。環境に合うビルドを入手し、購読と分流を固めたうえでシステムプロキシと TUN のバランスを取るのが近道です。レガシーな Win10 マシンでは、セキュリティ製品が仮想 NIC を止める・ブラウザ DoH が効きすぎるといった「OS 以外の摩擦」が増えがちな点も、兄弟となる Clash Verge Rev に慣れたユーザーならおなじみでしょう。Mihomo Party は画面設計が異なるぶん、初日にトグルとログの対応を頭に入れておくと、その差分をストレスなく越えられます。 → 無料で Clash をダウンロードし、快適な接続体験を試す