TUNモードで「全体のトラフィック」をどう捉えるか
TUNは、OS に仮想ネットワークインターフェースを追加し、そこへ向かうパケットをユーザ空間のプログラム（この場合は Clash／Mihomo コア）が受け取って処理する方式です。ブラウザが参照するシステムプロキシ設定とは別経路で動くため、「プロキシを無視するアプリ」や「独自にソケットを張るゲーム／開発ツール」でも、ルーティングとポリシー次第で同じルールエンジンの上に載せやすくなります。
ただし魔法ではありません。VPN や別のフィルタドライバと競合したり、管理者権限・コード署名・ルートテーブルが絡むため、環境差が出やすいのも事実です。ここでは「全体を掌握する」ことを、可能な範囲で一貫した経路に寄せる設計問題として捉え、期待値と検証をセットで考えるのがポイントです。
「漏れ」はどこで起きやすいか
日常でいうプロキシ漏れは、大きく次のようなパターンに分けて考えると対処がしやすいです。
- アプリケーション側のバイパス：HTTP プロキシ環境変数や OS の「システムプロキシ」を読まず、直接アウトバウンドへ出す実装があります。TUN はルーティングより下流〜同層に近い位置でトラフィックを掴むため、この種のズレを減らしやすいです。
- DNS の取りこぼし：接続先がドメインのとき、名前解決が意図したリゾルバを通らないと、見かけ上はプロキシ経由でも解決経路だけ別系統になることがあります。TUN と DNS の設定はセットで設計するのが安全です。
- UDP／特殊プロトコル：TCP だけ整えても、音声通話や一部ゲーム、QUIC などが別経路に逃げる例があります。ルールとスタックの能力、および実際の接続ログを照らし合わせる必要があります。
- Split tunnel や企業 VPN：職場の仮想プライベートネットワークがデフォルトルートを握っていると、Clash 側の自動ルートと衝突することがあります。どちらを「本丸のデフォルト出口」にするかを決めないと、挙動が日によって変わることもあります。
システムプロキシだけでは足りない理由
システムプロキシは導入が容易で、アプリが API 経由で従ってくれれば安定します。一方で、従わないプロセスや、プロキシの概念そのものが合わないトラフィックでは限界が出ます。TUN は「まず OS のパケット転送の流れに乗る」という発想なので、ルールベースのポリシー（GEOIP、ドメインサフィックス、プロセス単位の制御をサポートするクライアントなど）と組み合わせたときに、設計の自由度が広がります。
GUI クライアント（Clash Verge Rev、FlClash など）では、TUN のオン／オフやスタック指定が画面から行えることが多く、裏側では Mihomo コアの tun セクション相当の設定が有効になります。細かなキー名はバージョンで差があるため、手元のクライアントのドキュメントとログ出力を正とすると安全です。
設定で押さえたい論点（概念レベル）
実際の YAML は環境ごとに異なりますが、TUN を検討するときに頭に置くべき論点は共通しています。
| 論点 | 意味合い | メモ |
|---|---|---|
| 有効化フラグ | TUN デバイスを立ち上げるか | クライアントの「TUN モード」トグルと設定ファイルの整合を取る。二重に有効化して競合しないか確認します。 |
| スタック | カーネル／ユーザ空間スタックの選択 | 互換性と性能のトレードオフがあります。更新で推奨値が変わることもあるため、リリースノートを追う価値があります。 |
| 自動ルート | デフォルトゲートウェイ周りの扱い | 既存 VPN や社内ネットワークとルートがぶつかると、一瞬で通信不能になります。変更前にルート表をメモしておくと復旧が速いです。 |
| DNS ハイジャック／フォワード | 名前解決をコア側へ寄せる | fake-ip や redir-host など、DNS モードとの組み合わせで挙動が変わります。意図しないフォールバックに注意します。 |
| 厳密な除外 | LAN、ローカル、社内ドメイン | プリンタや NAS、イントラの証明書検証など、プロキシを通すと壊れる宛先はルールで明示的に DIRECT へ残すのが定石です。 |
OS ごとの現実的な注意点
Windows
サービスモードやドライバのインストールを求められることがあります。OS アップデート後に TUN が無効になる事例も報告されているため、その場合はクライアントの「サービス再インストール」や管理者権限での再起動を試す価値があります。セキュリティソフトのパケットインスペクションと競合すると奇妙な遅延や切断が出ることもあるため、切り分け時は一時的に除外ルールを検討します。
macOS
コード署名とプライバシー関連のダイアログが関わることがあります。ヘルパーツールやシステム拡張の許可が抜けると、見た目はオンでも実際にはトラフィックが流れません。設定アプリのセキュリティ項目を順に確認し、公式のトラブルシューティングに沿って再インストールするのが確実です。
Linux
ディストリビューションによって iptables／nftables、NetworkManager、systemd-resolved の組み合わせが異なります。ループや二重 NAT のような症状が出たら、まず既存のファイアウォールスクリプトと Clash が追加したルールの両方を眺め、どちらがデフォルトルートを握っているかを整理します。
DNS を TUN と一緒に設計する
TUN はパケット経路を変えますが、名前解決の意志決定は別レイヤーです。コアの DNS セクションで上流サーバや enhanced モードを整えずに TUN だけをオンにすると、「接続はプロキシ側なのに、解決だけ別ルート」という中途半端な状態になりがちです。
運用上のおすすめは次のような段取りです。まず現状の解決経路を dig や OS 付属ツールで把握する。次に Clash のログで、クエリが期待したハンドラに届いているかを確認する。最後に、ブラウザだけでなく CLI ツールからも同一ドメインを引き、差があればルールかキャッシュを疑う。この三手順を踏むと、設定変更のたびに迷子になりにくくなります。
有効化から検証までの推奨フロー
-
バックアップとロールバック手段
動いているconfig.yamlと、クライアントのプロファイル一式をコピーしておきます。TUN 試験中に SSH やリモートデスクトップが切れると困るため、物理コンソールや別経路の接続を確保しておくと安心です。 -
最小ルールでスモールスタート
いきなり巨大な GEOIP ルールを足すのではなく、LAN は DIRECT、テスト用ドメインだけポリシーグループへ、といった短い構成で TUN をオンにします。期待どおりに接続ログへ流れ込むかを先に確認します。 -
二重のプロキシ設定を避ける
ブラウザ拡張の固定プロキシと OS レベルの TUN が同時に効き、意図しない二重経路になることがあります。検証中はどちらかに寄せてシンプルに保ちます。 -
ログと接続ビューで事実確認
ドメイン、プロセス名（対応クライアント）、プロトコル、選択されたポリシーを眺め、ルールの想定と一致するかを見ます。気になるアプリがあれば、そのみを対象に追加ルールを試します。
よくある症状と切り分け
有効化直後に全体がオフラインになる
ルートループや DNS の行き止まりが典型です。TUN をオフに戻せるショートカットを確認し、バックアップ設定で起動したうえで、自動ルート関連の項目を一つずつ戻して原因を特定します。
遅延だけが異常に増える
スタックの相性、セキュリティ製品のスキャン、MTU 周りの問題が疑われます。別スタックに切り替えられる場合は A／B テストを行い、改善するかを見ます。
ブラウザだけ通る／特定アプリだけ通らない
プロセス単位のバイパス設定、管理者権限で動く別ユーザコンテキスト、ハードコードされたエンドポイントなどを疑います。接続ログにそのアプリのフローが現れるかが最大の手がかりです。
GUI クライアントを使う場合の考え方
多くのユーザーはコマンドラインではなく GUI から TUN を操作します。クライアントのダウンロードページから入手したビルドでは、インストール直後に TUN トグルが無効やグレーアウトしていることがあります。これはヘルパーやドライバのセットアップが未完了なことが多いので、公式手順に従い一度だけ初期セットアップを完了させるのが近道です。
プラットフォーム横断で背景知識を補いたい場合は、当サイトのドキュメント／チュートリアルも参照すると、ルールモードや DNS の章とつながって理解しやすくなります。
上流実装と情報源
挙動の詳細や実験的オプションは、コアのバージョンに強く依存します。ライセンスやソース、Issue の議論は Mihomo（旧 Clash Meta）の GitHub リポジトリで確認できます。インストーラの入手先として GitHub Release を併記するサイトもありますが、本稿でいう「まず試す」導線は、一貫した説明と更新履歴が揃う当サイトの配布ページを推奨します。
まとめ：TUN は「全体設計」の一部
TUN モードは、システムプロキシの隙間を埋める強力な手段ですが、DNS・ルーティング・他ソフトとの関係まで含めて設計しないと、かえって不安定になることもあります。期待値を「完全な物理的隔離」ではなく「ルールとログで説明可能な一貫性」に置くと、運用が楽になります。
変更のたびにバックアップとスモールスタート、そしてログによる検証を挟めば、グローバルなトラフィックを把握しつつ、無用な漏れやループを大きく減らせます。同カテゴリのツールのなかでも、Clash 系はルール表現とクライアントの選択肢が豊富で、長期的にチューニングしやすいバランスにあります。