TUN モードの仕組みと有効化方法:グローバル通信を確実に制御する

システムプロキシ(System Proxy)は OS レベルの設定であり、実質的にはシステムやアプリの実行環境に一組のプロキシアドレス(HTTP_PROXY / HTTPS_PROXY などの環境変数、あるいは Windows の WinINet/WinHTTP 設定項目、macOS のネットワーク環境設定)を書き込むものです。アプリがネットワークリクエストを送る際にこの設定を読み取り、自らトラフィックをプロキシポートへ転送して初めて「プロキシを経由した」ことになります。これは**協調的な**転送方式であり、プロキシが実際に機能するかどうかは対象アプリが協力するかどうかに依存します。

一方 TUN モードは全く異なる仕組みです。Clash Meta(mihomo)で TUN を有効にすると、システム内に仮想ネットワークアダプタが作成され(Windows では Wintun ドライバに依存し、macOS/Linux では utun/tun0 デバイスに対応)、システムのデフォルトルートがこの仮想アダプタへ向けられます。以降、ネットワーク層を通過するすべての IP パケットは——どのプロセスから発生したか、プロキシの存在を知っているかにかかわらず——まず仮想アダプタに捕捉され、その後 Clash コアがルールに基づいて処理します。これは**ネットワーク層での強制的な制御**であり、アプリ側の協力を必要としません。

違いを一言でまとめると、システムプロキシは「経由するかどうかはアプリの意思次第」、TUN モードは「経由するかどうかにかかわらず必ず通過させる」という点にあります。

以下のようなケースではシステムプロキシが機能せず、TUN モードでなければカバーできません。

• UDP を主体とするプロトコル。システムプロキシの仕組みは主に HTTP/HTTPS(TCP ベース)を想定して設計されており、多くのオンラインゲーム、音声通話(VoIP)、一部のビデオ会議ソフトは UDP による直接通信を行うため、システムプロキシの設定を参照しません。
• コマンドラインおよびバックグラウンドサービス。多くの CLI ツール(パッケージマネージャや一部のビルドスクリプト)やシステムデーモンはプロキシ環境変数を確認しない、あるいは追加の --proxy パラメータを指定しなければプロキシを経由せず、設定が煩雑で見落としやすくなります。
• Socket 接続をハードコードしたアプリ。一部のデスクトップクライアントやモバイルアプリは低レベルの Socket API を直接呼び出しており、システムプロキシの設定を完全に無視します。一部のチャットツールやクラウド同期ツールでよく見られます。
• ICMP や特殊なプロトコル。 Ping や Traceroute など ICMP をベースとした探索トラフィック、および一部の P2P プロトコルも、システムプロキシの処理対象には含まれません。
• 仮想マシンやコンテナ内のトラフィック。ホスト側のシステムプロキシは通常、仮想マシンやコンテナには自動的に引き継がれませんが、TUN モードはホストのルーティング層で捕捉するため、ネットワークモードの設定次第でこれらのトラフィックもカバーできます。

「プロキシを有効にしているのに直接接続されている」というアプリを見つけた場合、たいてい上記のいずれかに該当します。TUN モードを有効にするのが最も直接的な解決策です。

TUN モードは仮想ネットワークアダプタの作成やシステムルーティングテーブルの変更を伴うため、いずれのプラットフォームでも高い権限が必要ですが、詳細な手順は異なります。

sudo modprobe tun
sudo setcap cap_net_admin=eip /path/to/mihomo

TUN モードを有効にすると、DNS クエリも仮想アダプタによって捕捉されます。これは TUN モードにおいて最もトラブルが起きやすい部分でもあります。設定ファイルでは通常、DNS ハイジャックと解決ポリシーを明示的に指定する必要があります。

tun:
  enable: true
  stack: system
  dns-hijack:
    - "any:53"
  auto-route: true
  auto-detect-interface: true
dns:
  enable: true
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

dns-hijack は、外部への 53 番ポートの DNS リクエストをすべて強制的に捕捉し Clash コアに処理させる設定で、ルールを迂回して海外や汚染された DNS サーバーへ直接アクセスしてしまうことを防ぎます。fake-ip モードは各ドメインに対してプライベートアドレス帯の仮の IP を割り当てる仕組みで、アプリ側にはこの仮 IP が見え、実際の接続が確立される際にコアが本来の宛先へ差し替えます。これにより実際の名前解決結果を待たずにドメイン名でルールを判定できるという利点があります。

よくある問題の切り分け方向:

• DNS リーク。直接接続のトラフィックで DNS リクエストが捕捉されていない場合(例えばブラウザが依然としてシステム標準の DNS を使用している場合)、dns-hijack が該当ポートをカバーしているか、システムのネットワーク設定で固定 DNS サーバーが手動指定されて競合していないかを確認してください。
• ルーティングループ。 TUN モードでは、プロキシサーバー自身への接続が再び TUN アダプタを経由してはいけません。そうなると「プロキシ自身への接続がループする」状態に陥ります。クライアントは通常 auto-detect-interface や明示的なプロセス除外ルールでこの問題を回避しているため、手動設定時は必ず該当項目が有効になっているか確認してください。
• VPN クライアントとの競合。 TUN モードを他の VPN ソフトと同時に実行すると、両者がデフォルトルートを取り合い、いずれかが断続的に機能しなくなることがあります。両者を同時に有効化しないことを推奨します。

TUN モードを有効にした後は、クライアントのスイッチの状態だけで判断せず、以下の順序で確認することを推奨します。

1. 仮想ネットワークアダプタが存在するか確認する。 Windows では「ネットワーク接続」を開き、「Mihomo」や「Clash」といった名称のアダプタが追加されているか確認します。macOS/Linux では ifconfig または ip addr を実行し、utun / tun0 デバイスが存在するか確認します。
2. デフォルトルートを確認する。 Windows では route print、macOS/Linux では netstat -rn または ip route を使用し、デフォルトルートが物理アダプタではなく仮想アダプタに向けられていることを確認します。
3. システムプロキシに依存しないツールでテストする。例えばターミナルでプロキシパラメータを何も指定せずに curl を実行したり、ルール上「プロキシが必要」と判定されるドメインをコマンドラインで Ping し、想定した出口にヒットしているかを確認します。
4. クライアントの接続ログを確認する。多くのクライアントは「接続」や「ログ」パネルで各接続のインバウンドタイプを表示しており、TUN モードでの接続は通常 HTTP/SOCKS ではなく TUN と表示されます。これによりどの経路が実際に機能しているかを確認できます。

上記の確認をすべて通過しても特定のアプリだけがプロキシを経由しない場合、そのアプリがシステム上で特定のネットワークインターフェースに固定されていたり、独自の DNS を使用している可能性が高く、Clash の設定をさらに調整するのではなく、そのアプリ自体のネットワーク設定を個別に確認する必要があります。