TUNモード徹底解説：グローバル透過プロキシの仕組みと設定方法

Clash を使い始めて多くの人が最初にぶつかる疑問があります。プロキシをオンにしているのに、なぜゲームは国内回線のまま通信するのか？なぜ git clone はプロキシを経由しないのか？なぜコマンドラインツールは個別に設定が必要なのか？これらの問題の根本には、システムプロキシの動作の仕組みがあります。システムプロキシはすべてのアプリをカバーできないのです。TUN モードはこの問題を解決する究極の方法です。本記事でその仕組みをじっくり理解していきましょう。

システムプロキシの限界

「システムプロキシ」モードの動作は、OS に対して「HTTP/HTTPS リクエストはローカルの 127.0.0.1:7890 に送ってください」と通知するものです。この方式には根本的な制約があります。それはシステムプロキシ設定を能動的に読み取るアプリケーションだけがそれに従うという点です。

ブラウザ（Chrome、Firefox、Safari）はデフォルトでシステムプロキシ設定に従いますが、次のようなタイプのプログラムは通常従いません。

ゲームクライアント（Steam、Epic Games、各種オンラインゲームのクライアント）
コマンドラインツール（git、curl、wget、npm、pip）
Windows の UWP アプリ（Microsoft Store からインストールしたアプリ）
一部の Electron アプリや、低レイヤーのネットワークライブラリを直接呼び出すプログラム
UDP プロトコルを使用するほぼすべてのプログラム（大半のゲームやビデオ通話を含む）

さらに、システムプロキシは HTTP/HTTPS プロトコルのトラフィックしかプロキシできず、ネイティブの TCP 接続や UDP トラフィックは扱えません。つまり、理論上は「プロキシに対応している」アプリでも、その UDP トラフィックはプロキシを迂回して直接送出されてしまうのです。

TUN モードの動作原理

TUN（Tunnel Network Interface）は OS が提供する仮想ネットワークアダプタのインターフェースです。リンク層で動作する TAP インターフェースとは異なり、TUN はネットワーク層（IP 層）で動作し、IP パケットを直接読み書きできます。

Clash の TUN モードの処理の流れは次のとおりです。

Clash が OS に対して仮想ネットワークアダプタの作成を要求します（通常 Mihomo や utun0 という名前が付けられます）。
システムのルーティングテーブルを変更し、特定の宛先 IP 帯への送信トラフィックをこの仮想ネットワークアダプタへリダイレクトします。
Clash コアが仮想ネットワークアダプタから生の IP パケットを読み取り、宛先アドレスとプロトコル種別を解析します。
TCP トラフィックの場合、Clash はローカルの TCP 接続を確立してデータを受け取り、ルールに従ってプロキシノードへ転送するか直接接続します。UDP トラフィックも同様に処理します。
プロキシノードまたは直接接続先のサーバーから返ってきたデータを再びカプセル化して仮想ネットワークアダプタへ書き戻し、OS がリクエストを発したアプリへルーティングします。

ネットワーク層でトラフィックを捕捉する（アプリケーション層ではない）ため、プロキシプロトコルに対応しているかどうかにかかわらず、すべてのプログラムの送信パケットが捕捉され処理されます。これこそが、TUN モードが真のグローバルプロキシを実現できる根本的な理由です。

TUN モードは仮想ネットワークアダプタの作成とシステムルーティングテーブルの変更を行う必要があり、この2つの操作には管理者権限（Windows の UAC による昇格）または Root/sudo（Linux/macOS）権限が必要です。これはプログラムが「過剰な権限を要求している」のではなく、OS のセキュリティ機構によって決められているものです。

fake-ip：TUN モードの DNS ソリューション

TUN モードでは DNS の処理方法が非常に重要になり、最も問題が起きやすい部分でもあります。まずは従来の DNS の流れを見てみましょう。

アプリケーション → DNS を問い合わせ: example.com → 実際の IP 203.0.113.1 を取得 → その IP へ TCP 接続を開始

問題は、Clash が TUN レイヤーで 203.0.113.1 宛ての TCP 接続要求を捕捉したとき、IP アドレスしか見えず、その接続がどのドメインに対応しているのか分からないという点です。Clash のルールシステムはドメインによるマッチング（DOMAIN-SUFFIX、DOMAIN-KEYWORD）に大きく依存しているため、ドメインが分からなければ正しく振り分けられません。

fake-ip モードは、この問題を解決するエレガントな方法です。

アプリケーションが example.com の DNS クエリを発行します。
Clash がこの DNS クエリを捕捉し、すぐに偽の IP を返します（例：198.18.0.1）。同時に内部で 198.18.0.1 → example.com という対応関係を記録します。
アプリケーションは偽の IP を受け取り、198.18.0.1 へ TCP/UDP 接続を開始します。
Clash は TUN レイヤーでこの接続要求を捕捉し、内部の対応表を参照して、宛先が example.com であることを把握します。
Clash はドメインのルールに従ってプロキシ経由か直接接続かを判断します。プロキシ経由の場合は、プロキシノード側で実際の DNS 解決が行われます。直接接続の場合は、Clash が改めて実際の DNS を問い合わせてから接続を確立します。

fake-ip の最大の利点は、機密性の高いドメインの DNS クエリがすべてプロキシノード側で完結するため、DNS リークを完全に防げる点です。さらに Clash がドメイン情報を把握できるため、ルールマッチングの精度も大幅に向上します。

TUN モードを有効にする

Clash Verge Rev（Windows / macOS）

クライアントを開き、左側の「設定」アイコンをクリックします。
「TUN モード」（または「Tun Mode」）のスイッチを見つけ、クリックして有効にします。
システムが権限要求のウィンドウを表示します。Windows では「はい」をクリックし、macOS ではシステムパスワードを入力して確認します。
初回有効化時にはバックグラウンドで仮想ネットワークアダプタのドライバ（Mihomo）がインストールされるので、5〜10 秒ほど待ちます。
クライアントの状態が「TUN 有効」に変わり、この時点ですべての送信トラフィックが Clash に引き継がれます。

完全な YAML 設定（Mihomo コア）

tun:
  enable: true
  stack: mixed        # mixed / system / gvisor
  dns-hijack:
    - any:53          # hijack all DNS queries
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
  nameserver:
    - https://1.1.1.1/dns-query    # Cloudflare DoH
    - https://8.8.8.8/dns-query    # Google DoH
  fallback:
    - https://1.0.0.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

TUN の Stack モード詳解

TUN の stack パラメータは、捕捉したネットワークパケットをどのように処理するかを決定し、性能・互換性・安定性に直接影響します。

mixed（推奨）：TCP トラフィックはシステムネイティブのネットワークスタックで処理し、UDP トラフィックは gVisor のユーザー空間実装で処理します。互換性と性能のバランスが最も優れており、ほとんどのユーザーに適しています。
system：TCP と UDP のすべてを OS のネットワークスタックに任せます。性能が最も高く CPU 使用率も最も低いですが、Linux の一部のカーネルバージョンでは互換性の問題が生じることがあります。極限の性能を求めるサーバー用途におすすめです。
gvisor：TCP と UDP のすべてをユーザー空間で完全なネットワークスタックとしてエミュレートします（Google の gVisor プロジェクト）。互換性が最も高く、あらゆるエッジケースを処理できますが、CPU とメモリのオーバーヘッドは mixed より 20〜40% 高くなります。mixed モードで原因不明の問題が起きたときに切り替えて試すとよいでしょう。

よくある問題とトラブルシューティング

LAN 機器（プリンター、NAS、ルーター管理画面）にアクセスできない

TUN モードは auto-route によって全トラフィックを引き受けるため、LAN の IP 帯のトラフィックもプロキシの出口へルーティングされてしまい、当然ローカルの機器に到達できなくなります。ルールファイルの最前面に次の直接接続ルールを追加すれば解決します。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # ... その他のルール

Clash を終了したらネットワークが切断された

Clash を終了する前に、必ず設定で TUN スイッチをオフにし、プログラムがルーティングテーブルのエントリを片付ける機会を与えてください。すでにネットワークが切れてしまった場合は、Clash を再度開く → TUN をオフにする → その後にプログラムを終了する、という手順を踏みます。あるいはデバイスマネージャー（Windows）で Mihomo という名前の仮想ネットワークアダプタを無効化し、ネットワークを再起動すれば復旧します。

fake-ip-filter のホワイトリストが足りない

ローカル開発用ドメイン（localhost、*.test など）、企業内ネットワークのドメイン、一部の国内アプリ（QQ、WeChat）の特殊なサービスドメインは、fake-ip 処理を経ると接続に失敗することがあります。これらのドメインを fake-ip-filter リストに追加すると、Clash は偽 IP を返さずに実際の DNS 解決を行います。

TUN モードを有効にすると CPU 使用率が上がる

これは正常な現象です。TUN モードはすべてのネットワークパケットをユーザー空間で処理する必要があるため、システムプロキシモードより CPU の負荷が 10〜30% 高くなります。CPU 使用率が異常に高い（20% を超える）場合は、stack を gvisor から mixed に切り替える、Clash を経由している大量の UDP トラフィック（P2P など）がないか確認する、といった対処を試してください。

まとめ

TUN モードは Clash の最も強力で完成度の高いプロキシモードです。仮想ネットワークアダプタによってネットワーク層で全トラフィックを捕捉し、fake-ip DNS メカニズムと組み合わせることで正確なドメインベースの振り分けを実現し、システムプロキシモードのカバー範囲が限られているという問題を根本から解決します。

日常的なブラウザの利用であれば、システムプロキシモードで十分です。しかし、ゲームやコマンドラインツール、あるいはすべてのアプリのトラフィックをプロキシしたい場合は、TUN モードが唯一の選択肢です。LAN の直接接続ルールと fake-ip-filter のホワイトリストをきちんと設定すれば、TUN モードは非常に安定して動作します。