なぜ TUN の「細かい設定」が単独記事になるのか

TUN モードは、仮想アダプタ経由で広い範囲のトラフィックをコア側へ寄せられる上位オプションです。だからこそ「購読が取れた」「システムプロキシではブラウザが通った」段階から一歩進むと、突然ワンクリックで OS のルーティング表やフィルタと正面衝突し、挙動は環境依存に振れます。Windows 11 は UI が整理されている一方で、バックグラウンドの VPN・セキュリティ製品・企業ポリシーが絡むと、画面上は同じトグルでも結果だけが読者ごとにまったく違う、という状況が起きえます。

そのなかで個別に効いてくるのが tun セクションまわりのスタック選択と、経路をより意図どおりに「締める」方向へ寄せる Strict Route です。名前だけ見ると似たようなチェックボックスに見えますが、前者はパケット処理の実装階層の選択に近く、後者はシステムの経路解決とトンネル側の前提を、より強く一致させる意図を表すことが多い、と考えると切り分けがしやすくなります。

本稿はフロントエンドのビルドごとにラベルが微妙に違う前提で、「どの概念をどの順に潰していくか」を軸に書きます。発想の下地として TUN モードの詳解 も併読すると、DNS や fake-ip の話まで含めた全体像に戻りやすいです。

前提：インストール記事との役割分担とベースライン

まず Windows 11 に Mihomo Party を導入する手順 で、購読・mihomo コア・mixed-port とシステムプロキシまでが一通り見えている状態を勧めます。そこが不確かなまま TUN だけ先に有効化すると、「コアは動いているのに画面だけおかしい」「ブラウザは通るのに特定アプリだけ素通り」のような観測の階層が積み上がらないまま原因候補が爆発しがちです。

ベースラインとして最低限そろえたいのは次の四点です。(1) アクティブなプロファイルが意図した YAML を指している、(2) ルールモードなど処理順の前提が把握できている、(3) ログ画面で接続がヒットする、(4) Windows の手動プロキシ画面で 127.0.0.1 とポートが期待どおりか、です。この四点が固まっていると、TUN を足した瞬間の差分が「スタック」「Strict Route」「別製品のルート奪取」のどこに寄っているかを素早く絞れます。

ℹ 用語の釘：本文ではコア設定で一般的な tun ブロックのキー名（stack や strict-route など）を参照しますが、Mihomo Party 側では同じ意味の項目が GUI の英語ラベルやツールチップに分散していることがあります。最終的にはデータフォルダの config.yaml で実値を突き合わせると迷子になりにくいです。

スタック（gVisor と system）を用途で選ぶ

スタックは、TUN が有効なときに「パケットをどの層で、どの程度 OS ネイティブに近い経路で扱うか」という実装トレードオフです。読者環境によって最適解は代わりますが、検索語としてよく出る対比は gVisor 系と system 系です。ざっくり言えば、gVisor 側はユーザーランドで処理を束ねるスタイルが強く、特定の挙動では CPU や遅延の振れが読みやすい一方、隔離の仕方が相性の悪いアプリとは衝突しないこともありません。system 側は OS のスタックに寄せる分、環境によっては素直に速く見える一方、ドライバや WFP まわりの癖とより強く相互作用します。

実務的な選び方は「正解を暗記」ではなく、(1) まず片方で安定するか、(2) オンライン会議・ゲーム・社内 VPN のような遅延と UDP／QUIC が気になるアプリで違和感が出るか、(3) 逆側に切り替えたときに改善するか、の三段で試すことです。CPU 常時高負荷や妙なタイムアウトだけが残るときは、スタック変更よりDNS モードや fake-ipの寄与も疑うのが定石で、分流の読み方は DNS／fake-ip の整理記事 と矛盾しません。

YAML 上の形（参考・実キーはプロファイル依存）

GUI と往復しながら値がどこに書き込まれているか不安なときは、コアが解釈しているファイルを見るのが早いです。ビルドやバージョンで列挙子の綴りは変わり得ますが、概念的な置き場所は次のような形で把握しておくと会話や検索に繋がります。

YAML excerpt — tun rule-of-thumb (illustrative) 
tun:
  enable: true
  stack: system  # or gvisor-like value your build supports
  # strict-route: true  # discussed in the next section

Strict Route は何を締めるオプションか

Strict Route は、名称どおり経路を厳密化する意図を持つスイッチです。オフのときに起きがちなのは、一部トラフィックがトンネル外のインターフェースへ迂回して見える、あるいは意図しないデフォルトの奪い合いが表面化することです。オンに寄せると、「そうした迂回を抑え、論理インターフェース前提の取り回しに寄せる」方向に働くことが多く、結果として分流が読みやすくなる反面、社内ネットや別 VPN と同時に経路を握る要件では期待と逆のブロックが出ることがあります。

つまり Strict Route は万能の高速化スイッチではなく、あなたのルールセットと共存アプリの前提が、トンネル優先で問題ないかの確認作業です。併用が多い環境では、いったんオフでベースラインを掴み、問題が再現する局面だけオンへ、という二分探索が安全です。閉じた後にルートが変な挙動を見せる話は プロキシ／TUN 終了後の再接続トラブル が参考になります。

Mihomo Party 上での実操作の流れ（ビルド差を吸収する読み方）

ここからは Mihomo Party の画面操作に落とします。バージョンでメニュー名は揺れるため、「この順番で名前を押す」とまでは断言しません。代わりに探索の順序を固定します。

  1. 設定またはコア／仮想アダプタ相当の画面を開き、TUN の有効化トグルを探します。初回は UAC の昇格を求められるのが普通です。
  2. 同じ文脈か、tun に対応する詳細欄に stack（gVisor／system 等）の選択があるはずなので、まずは現状値をメモし、変更は一度に一項目だけずつ行います。
  3. Strict Route に相当するチェックを見つけたら、説明文があれば「迂回抑制」と読み替え、オンのまま別 VPN を併用していないかを再確認します。
  4. 変更後は可能ならコア再起動またはプロファイルの再適用を行い、ログに致命的エラーが出ていないかを見ます。
  5. 期待どおりに見えたら、ブラウザだけでなく音声通話や特定アプリも許可範囲で一度通します。ここでだけ遅延が出るならスタック候補を入れ替える判断材料になります。

画面上の英語ラベルが分散している場合でも、最終的に データフォルダの config.yaml の tun: 節へ反映されているかを見ると、GUI の言い回し差を一気に吸収できます。

疎通確認：ログ・プロキシ画面・ルールヒット

TUN を足した検証では、「ブラウザの IP 表示が変わった」だけだと假象型の成功になりがちです。最低限、(1) 接続ログで対象ドメインが期待するポリシーに乗っている、(2) Windows のプロキシ UI が意図しない値へ上書きされていない、(3) ルール未命中が妙に多くない、の三点を同時に見ます。TLS や timeout の読み方は 接続ログと TLS を併用すると早いです。

Strict Route をオンにした直後だけ特定サイトが開けなくなる場合は、(a) ルール自体の順序、(b) DNS の帰り先、(c) 別製品のフィルタ、(d) IPv6 と IPv4 の段差、のどれかに寄っていることが多いです。一度 Strict をオフに戻して差が消えるかを見ると、切り分けの第一歩になります。

Checklist — after changing tun options 
1. Party: tun ON, stack chosen, strict-route as intended
2. Log: no fatal parse errors; hits look sane for test domains
3. Windows proxy UI: no surprise manual proxy if you expect none
4. App spot-check: browser + one latency-sensitive app (if allowed)

TUN をオフにしたあとのルートとプロキシの掃き方

TUN モードを終了したあとにネットが不安定になるのは、読者からの相談でも頻出です。典型は システムプロキシ の残骸、手動プロキシ の固定、別クライアントが入れた静的ルート、DNS の固定、です。Mihomo Party 側で TUN とシステムプロキシの両方を明示的にオフにし、Windows の「設定 → ネットワークとインターネット → プロキシ」を開いて値を点検してください。

さらに踏み込むなら route print やネットワークアダプタの状態で、見慣れないインターフェースが優先度だけ残っているケースもあります。社内手順が許す範囲でアダプタの無効化／再有効化や再起動を挟むと、見えない優先度のズレがリセットされることがあります。詳しい因果の型は前述の 終了後トラブル記事 に譲ります。

分流がおかしいときの切り分け（DNS・別 VPN・二重クライアント）

「ルールは合っているはずなのに別出口に見える」とき、まず疑うのは DNS です。DoH や静的 DNS がブラウザや OS に残っていると、見た目はルールどおりでも実際のコネクト先の解決が別系統に逃げます。次に 別 VPN やフィルタが デフォルトルート を握り直していないかを疑い、検証では停止のオンオフだけを変えて差分を取ります。

二重クライアントも典型で、片方が TUN、もう片方がシステムプロキシを同時に有効にすると、画面のどちらか一方だけ見ていても実際の経路は三枚舌になります。長く運用するほどルールの保守は ルール分流のベストプラクティス に寄せたほうが再現性が上がります。

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

よくある質問

gVisor と system、どちらが速いですか？

環境差が大きく、どちらが常に速いとは言えません。遅延だけでなく CPU と特定アプリ互換性まで踏まえて、短時間の A/B が現実的です。測り方の癖は 遅延測定の整理記事 の考え方を応用できます（クライアントは異なりますが、観測の段取りは流用できます）。

Strict Route をオンにしたら社内イントラに届かなくなりました

併用前提の経路設計では、厳密化が逆効果になることがあります。いったんオフに戻し、必要な宛先を直ルールで明示する・別ブリッジを切る、といった運用へ寄せてください。セキュリティ境界の越境は許可範囲を確認してからにしてください。

Firewall が警告を出します

TUN は新しいインターフェースとフィルタ規則を伴いやすく、初回に OS やセキュリティ製品が注意を出すことはあります。信頼できるバイナリか、規則が意図どおりかを確認し、闇雲に全許可は避けてください。

まとめ

Windows 11 で Mihomo Party の TUN モードを実戦投入するときの骨格は、導入稿で購読とシステムプロキシのベースラインを固めたうえで、(1) スタックを用途と遅延感で A/B し、(2) Strict Route は経路厳密化のトレードオフとして段階的に、(3) オフ後はプロキシとルートの残骸を必ず点検する、の三枚です。概念の奥行きは TUN の詳解 に戻り、日々のルール運用は分流記事とセットにすると長期的にブレません。

一方で、単機能型の商用 VPN アプリは画面は単純でも、細かい tun オプションや接続ログの粒度が薄く、環境差で起きた不具合の原因が「製品なのか OS なのかルールなのか」を追いにくい製品も少なくありません。Clash V.CORE は購読・ルール・ログを同じ運用文脈へ置きやすく、今回のようなスタック切替や Strict Route の試行錯誤も、差分をログと設定ファイルの両方から検証しやすいのが実務上の強みです。継続的な入手と更新は ダウンロードページ から、TUN を触った日はプロキシ画面とルート確認をセットにすると安心です。