Clash TUN モード完全ガイド：グローバルプロキシで全トラフィックを捕捉し、プロキシ迂回を解消する

TUN モードで「グローバルに近い」透過プロキシを実現する

Clash や Mihomo（旧称 Clash Meta）をデスクトップで使うとき、ブラウザや一部アプリだけがプロキシ設定を参照し、ほかのアプリは直出しのまま、という経験はよくあります。HTTP／HTTPS のシステムプロキシは、OS が提供する「プロキシを使うアプリ」にしか効きません。プロキシを読まないゲームクライアント、独自スタックの開発ツール、一部の即時通信アプリなどは、その外側を通り抜けます。

TUN モードは、仮想ネットワークインターフェース（TUN デバイス）を作り、ルーティング層でトラフィックをカーネルに近い位置から取り込み、Clash 側のルールとプロキシチェーンに載せる方式です。ユーザーが各アプリにプロキシを設定しなくても、OS がその仮想 IF へ流す範囲の通信は原則として中継対象になります。いわゆる「グローバルプロキシ」に近い体験を、ルールベースのまま実現するための主要手段のひとつです。

本ガイドでは、なぜ迂回が起きるのか、システムプロキシとの違い、Windows／macOS／Linux／Android での権限と有効化の流れ、設定ファイルと DNS の要点、典型トラブルまでを順に整理します。GUI は Clash Verge Rev のチュートリアルと併せて読むと、画面操作と用語の対応が取りやすくなります。

なぜ「プロキシを有効にしたのにアプリが通らない」のか

多くの OS では、アプリは次のいずれかで外部へ出ます。(1) システムのプロキシ設定を参照する、(2) 独自に SOCKS／HTTP プロキシを指定する、(3) どちらも使わずソケットを直接開く、の三パターンです。(3) のアプリは、システムプロキシをオンにしても一切プロキシを経由しません。これが「ブラウザだけ通る」「ターミナルの curl は通るがゲームは直結」の典型原因です。

さらに、UDP を多用するアプリや、特定ポートだけ直結する実装では、HTTP プロキシの枠組みだけでは不十分なこともあります。TUN は IP 層付近でパケットを扱うため、TCP に限らず UDP を含むフローをルールと組み合わせて扱いやすくする、という側面も持ちます（実際の振る舞いはスタック設定や OS によります）。

システムプロキシだけでは足りない場面

システムプロキシは設定が軽く、権限ダイアログも比較的少ない反面、対応していないアプリからは見えない壁があります。開発者向け CLI が環境変数 HTTP_PROXY を見るケース、見ないケースが混在するのも同種の問題です。

TUN を有効にすると、多くの場合 OS は「この仮想インターフェース経由でデフォルトルートに乗せる」などの形でトラフィックを誘導します。その結果、アプリ側がプロキシを意識しなくても、一度 Clash のスタックに入り、そこからルール（RULE）やプロキシグループに従って出口が決まります。だからこそ「グローバルに近い」透過性が得られる、という理解で差し支えありません。

TUN の仕組みをざっくり理解する

ユーザー空間の Clash／Mihomo が TUN デバイスを作成し、OS のルーティングテーブルやファイアウォールルールと協調して、対象トラフィックをそのデバイスへ向けます。アプリから見ると、通常のネットワークスタックを使っているだけですが、実際には仮想 NIC 越しにカーネルからユーザ空間へパケットが届き、そこでプロキシ処理やルールマッチが行われます。

DNS については、名前解決がプロキシの外で完結すると「見た目はプロキシ経由なのに実 IP が漏れる」などの問題が起き得ます。そのため TUN 運用では、DNS を Clash 側に寄せる（いわゆる DNS ハイジャックや listen と組み合わせた構成）ことがよく行われます。詳しくは後述の DNS 節で触れます。

メリットと注意点（導入前に押さえること）

メリットとしては、(1) プロキシ非対応アプリも含めトラフィックを捕捉しやすい、(2) ルールベースの分流を保ったまま全体をカバーできる、(3) UDP や複雑なプロトコルにも対応しやすい、が挙げられます。

注意点としては、(1) OS 権限やドライバ／システム拡張の承認が必要になることが多い、(2) 誤ったルート設定や競合 VPN があると一時的に全通信が止まることがある、(3) バッテリー駆動のモバイルでは常時 TUN／VPN は消費電力に影響しやすい、があります。本番マシンでは、まず短時間で有効化し、問題なければ常時運用に移すのが安全です。

Windows：サービスモード・管理者権限・競合

Windows では、TUN を安定させるために管理者権限でクライアントを動かすか、Clash Verge Rev などが提供するサービスモードを有効にする構成が一般的です。サービスモードは、ログオン前からバックグラウンドでコアが動く利点もありますが、インストール時に追加コンポーネントの許可が必要になることがあります。

すでに別の VPN クライアントやフィルタドライバが入っていると、TUN スタックが競合し「接続できない」「すぐ切れる」原因になります。トラブル時は、他社 VPN をいったん完全終了し、Windows の「ネットワークアダプター」に余分な仮想 NIC が残っていないかを確認すると切り分けが早いです。SmartScreen や Defender の警告については、Verge Rev のガイドで触れている対処の考え方がそのまま活きます。

macOS：システム拡張とネットワークフィルタの承認

macOS では、TUN やパケットフィルタに相当する機能にシステム拡張（System Extension）やネットワーク関連のプライバシー許可が必要になることがあります。初回有効化後に「セキュリティとプライバシー」から開発元を許可する、再起動を求められたら従う、といった手順が公式ドキュメントに沿って表示されます。

Apple Silicon と Intel でドライバ周りの挙動が微妙に異なる場合があるため、使用中のクライアントの macOS 向け READMEを一度通読してから有効化すると手戻りが減ります。iCloud プライベートリレーや別 VPN と併用するとルートが競合することがあるため、切り分け時は一時的に無効化して試す価値があります。

Linux と Android の考え方

Linux デスクトップでは、権限（CAP_NET_ADMIN など）と既存の iptables／nftables ルールとの関係が重要です。Docker や別のトンネルと同時運用していると、ルールの優先順位で意図しない経路になることがあります。ディストリビューションごとに推奨手順が異なるため、配布元の Linux 向け節を優先してください。

Android では、TUN に相当するのがほぼVPN プロファイルです。FlClash などで「VPN モード」を有効にするとステータスバーに鍵アイコンが出る挙動になります。バッテリー最適化の除外は FlClash Android ガイドでも述べたとおり、購読更新や接続維持に効きます。

GUI（Clash Verge Rev 等）から TUN を有効にする流れ

一般的な流れは次のとおりです。(1) カーネル（Mihomo 等）が正常に起動していることを確認する。(2) 設定画面で「TUN」または同等のトグルをオンにする。(3) OS が求める権限ダイアログを許可する。(4) 必要ならサービスモードやスタック種別（system／gvisor／mixed など）を選択する。(5) 接続テストで意図した出口になっているか確認する。

スタックの選択は、互換性とパフォーマンスのトレードオフがあります。system は OS ネイティブに近い経路で速い反面、環境依存の不具合が出ることがあり、gvisor はユーザ空間実装で安定しやすいがオーバーヘッドが乗る、といった使い分けが語られます。実際には両方試して体感とログで決めるのが現実的です。

設定ファイル（YAML）側のイメージ

GUI が生成する設定の背後では、おおむね次のような tun ブロックが使われます（例は概念説明用であり、利用中のバージョンのスキーマに合わせてください）。

tun:
  enable: true
  stack: system
  auto-route: true
  strict-route: false
  dns-hijack:
    - any:53

auto-route や strict-route、インターフェース名、MTU、IPv6 の扱いなどは、クライアントと OS の組み合わせで最適値が変わります。購読プロバイダーが配るデフォルトに加え、ローカルで tun だけ上書きする運用もよく行われます。YAML の基礎とルールの考え方は、当サイトのチュートリアル・ドキュメントと、サブスクリプション URL の取り込みガイドを参照すると全体像がつながります。

DNS・Fake-IP と「名前解決の抜け道」

TUN を使っても、DNS クエリだけが OS の既定リゾルバに直行し、結果として意図しない経路で名前解決されるケースがあります。dns-hijack や Clash の dns セクションで listen アドレスを定め、Fake-IP モードを使うかどうか、などを整えると、ルールと実際の接続先の一貫性が取りやすくなります。

Fake-IP は「早い名前解決とルールマッチのしやすさ」のために広く使われますが、挙動を誤解すると「特定サイトだけおかしい」原因にもなります。変更したらブラウザの DNS キャッシュや OS のキャッシュも意識し、段階的に試すとよいです。

ルールモードとグローバルモードの使い分け

TUN は「トラフィックを Clash に流し込むパイプ」であり、出口をどう選ぶかは別問題です。普段は RULE で国内直結と海外プロキシを分け、切り分け時だけ一時的に GLOBAL に寄せる、という運用が一般的です。グローバル固定は楽ですが、不要なトラフィックまで遠回りになるため、長期運用ではルール整備のほうが安定しやすいです。

分流の書き方自体は TUN の有無と独立ですが、TUN 有効化後は捕捉範囲が広がるため、ルールの誤りの影響も広がります。新しいルールを入れたら、必ず意図したドメインが期待どおりのプロキシグループに落ちるかを確認してください。

トラブルシューティング

TUN をオンにしたらネット全体が不通になる

競合 VPN、社内フィルタ、手動ルート、Kill Switch 系の設定を疑います。TUN をオフにして復帰するか確認し、クライアントログにルート追加やエラーが出ていないかを見ます。strict-route や IPv6 の組み合わせで詰まる例もあるため、ドキュメント記載の推奨セットに戻して試してください。

特定アプリだけプロキシを通らない

Split tunneling や「プロセス単位の bypass」がクライアント側にある場合、対象が除外リストに入っていないか確認します。また、アプリが固定 IP に直結している場合は、ルールで IP 側をカバーする必要があります。

名前解決だけおかしい・サイトが開かない

DNS 設定と Fake-IP、DoH／DoT を OS やブラウザで別途有効にしていないかを確認します。複数リゾルバが混在すると挙動が読みにくくなるため、試験時は設定を単純化すると切り分けが速いです。

オープンソースとドキュメント

Mihomo／Clash 系はオープンソースで、Issue や Wiki に TUN 周りの既知事項がまとまっています。挙動の詳細を追うときはリポジトリが有用です。一方、日々のインストールパッケージの入手は、説明が一貫した配布導線を優先すると取り違えを防ぎやすくなります。

まとめ

Clash／Mihomo で TUN モードを有効にすることは、「システムプロキシでは届かないアプリ」や「UDP を含むフロー」をルールの支配下に置きやすくするための強力な手段です。その代わり、OS ごとの権限・競合 VPN・DNS 設計への配慮が必須になります。手順は 権限付与 → スタック選択 → DNS 整合 → ルール確認 の順で押さえると、つまずきどころが減ります。

同種ツールのなかでも、Clash 系はルール表現の自由度と情報量のバランスが取りやすく、TUN と組み合わせると「ほぼ全体をカバーしつつ国内は直結」のような運用が現実的です。Windows／macOS 向けクライアントの入手から各 OS 版までを一覧したダウンロードページで環境に合うビルドを選び、本稿の手順で TUN を段階的に有効化してみてください。安定性と使いやすさのバランスは、多くのユーザーにとって他の単純プロキシツールより優れた体験になりやすいものです。→ Clash クライアントを無料でダウンロードし、快適な接続を試す