Clash TUNモード徹底解説：ネットワークの仕組み、設定の勘所、よくある不具合
検索で「Clash TUN 使い方」「システムプロキシ 効かない アプリ」と調べている方向け。ブラウザだけではなく、OS全体のトラフィックをコア側で扱う透明プロキシの一形態としての TUN を、用語の整理から現場で起きやすいトラブルまで日本語でまとめます。
TUNモードとシステムプロキシは何が違う？
多くの GUI クライアントは、既定でシステムプロキシ（HTTP/HTTPS/SOCKS を OS に登録）をオンにします。これはブラウザや WinHTTP に従うアプリには効きやすい一方、独自の TLS スタックを持つソフト、ゲームランチャー、一部のストア系アプリなどはプロキシ設定を読まず直結することがあります。
TUN（仮想ネットワークインターフェース）は別物です。OS に「もう一枚のネットワークカード」のような論理デバイスを生やし、ルーティングテーブル側からトラフィックをコアへ引き込みます。だから「アプリがプロキシを知らなくても、パケットの流れとしてはコアを経由できる」という性格になります。検索意図としては 透明プロキシ や フルデバイスプロキシ に近いニーズに応える部品だと捉えると分かりやすいです。
前提として、TUN は魔法ではありません。権限・ドライバ・既存 VPN・セキュリティソフトと順序や所有権がぶつかると、期待どおりに流れないことがあります。まずはシステムプロキシで安定させ、それでも抜けがあるときに TUN を検討する、という段取りが現実的です。基本操作の全体像は Clash のチュートリアル で押さえてから読み進めるとスムーズです。
パケットはどうコアに届くか（ざっくりネットワークの話）
TUN デバイスはもともと VPN やトンネル用途で使われる仕組みで、IP レイヤ（レイヤ3）付近で送受信を横取りします。Clash Meta 系コア（Mihomo）が TUN を有効にすると、指定されたプレフィックスのトラフィックが仮想インターフェース側に向けられ、コア内のルールエンジン・proxy-groups の判定に載ります。
ここで重要なのは、ルールで「どの出口に出すか」は従来どおりだという点です。TUN は「そもそもコアに届けるか」の経路の話で、出口の選び方そのものは proxy-groups と rules が担当します。だから「TUN をオンにしたのに期待どおりのノードに行かない」ときは、まずルール側のターゲット名や GEOIP の行き先を疑うのが早いです。
スタック実装（system / gvisor など）は OS とコアの版によって選択肢や既定値が変わります。挙動が変わったときはリリースノートとクライアントの組み合わせをセットで見る癖があると安心です。
どんなときに TUN が向いているか
- UWP やストアアプリがシステムプロキシを無視し、特定サービスだけ直結するとき。
- ターミナルや開発ツールが
HTTP(S)_PROXYを見ず、挙動がバラけるとき（※環境変数での統制も併用検討）。 - ゲームや UDP が多いアプリで、ユーザ空間プロキシだけでは捕捉しきれないとき。ただし UDP・QUIC はルールと出口タイプの両方に依存します。
- 「とにかく迷子を減らしたい」とき。代わりにルートの所有権が強くなるので、社内 VPN などとの兼ね合いには注意が要ります。
設定ファイルで押さえるポイント（概念）
Mihomo 系のプロファイルでは、tun: ブロックで有効化し、auto-route やインターフェース検出、スタックなどを指定します。クライアントによっては GUI のトグルが同じキーを書き換えるだけ、という実装が多いです。配布プロファイルに tun が無くても、自分用のオーバーライドで足せる場合があります（移行直後にオーバーライドを使っている場合は、そこに追記するイメージです）。
# 概念例（実際のキー名・既定値は利用中のコア版のドキュメントに合わせる）
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
# strict-route や dns-hijack など、環境に応じたオプションを検討auto-route を有効にするとルーティングが積極的に書き換わります。社用 VPN やゼロトラスト端末では、IT ポリシーと衝突しないかだけ先に確認してください。
「とにかく真っ先に TUN」はトラブルの元です。システムプロキシで問題が再現するか、ログに何が出ているかを切り分けてから有効化すると、原因がルールなのか経路なのかが見えやすくなります。
DNS・fake-ip とセットで考える理由
TUN を使うと、DNS の扱いが表に出やすくなります。Clash 系でよく使う fake-ip は、名前解決の段階でコアが応答を差し替え、あとから実アドレスへマッピングする流れです。ブラウザの DNS over HTTPS や OS のリゾルバ設定と二重に解決が起きると、「見ているドメインと実際に張っている接続がズレる」ように見えることがあります。
検索では「Clash DNS ループ」「fake-ip 効かない」といった語が出てきがちですが、現場では (1) クライアントとコアの版、(2) dns: セクションと tun の組み合わせ、(3) ブラウザ側 DoH のオンオフをセットで見ると早いです。IPv6 優先やループバックまわりは、OS アップデートで挙動が変わるので、古い記事だけに頼らない方が安全です。
OS ごとの前提（管理者権限・ドライバ）
Windows では TUN 用ヘルパーやドライバのインストールを促すプロンプトが出ることがあります。企業端末では SmartScreen やポリシーで止まる場合もあるため、許可フローは事前に確認してください。macOS ではシステム拡張やネットワークフィルタに関するダイアログが出る版があり、初回だけ手順を踏む必要があります。
いずれの OS も、「管理者相当の操作が一度必要」と覚えておくと期待値がずれません。標準ユーザーで日々使い、TUN のときだけ昇格、というパターンも珍しくありません。
現場で多いつまずき
- 既存の VPN / ゼロトラストとデフォルトルートが競合：両方が「自分がデフォルト」と主張すると、片方だけ通信が抜けることがあります。テスト時はどちらかをいったんオフにして再現性を取るのが近道です。
- セキュリティ製品がローカルプロキシや仮想 NIC を疑う：除外設定や学習モードの有無を確認します。ログにブロック理由が残ることが多いです。
- WSL2 や仮想マシンは別名前空間：ゲスト OS 内では Windows 側の TUN をそのまま共有しないので、ゲスト側でもプロキシかルーティングを別設計する必要があります。
- ゲームや対戦型アプリ：レイテンシや UDP の要件で、プロキシ経由がそもそも向かないケースがあります。ルールで
DIRECTに逃がす・TUN をオフにして切り分ける、など現実的な落とし所があります。 - 版のミスマッチ：「去年は動いた」がよくあるので、クライアントとコアをペアで更新し、変更点をリリースノートで確認します。
まとめ：経路とルールを混同しない
TUN はトラフィックをコアに届けるためのレーンであり、どのノードに出すかはルールと proxy-groups が決めます。だから設定が複雑に見えても、切り分けの軸は「届いていないのか」「届いたあとに誤った出口なのか」の二段にすると頭が整理しやすいです。
エコシステム全体の位置づけや、メンテの続くクライアント選びは 2026 年時点の Clash エコシステム解説 も参照してください。インストールや更新の入口は、迷わないよう 本サイトのダウンロードページ を第一にすると、配布チャネルと説明資料の対応関係が取りやすくなります。