TUN仮想ネットワークインターフェースとシステムプロキシの違い｜通信を取り込む範囲と選び方

1. 通信の取り込みとプロキシの振り分けは別の仕組み

システムプロキシとTUNは、どちらもアプリの通信をClashのコアに届けるための仕組みです。通信がコアに入った後、ルールやプロキシグループ、ノードによって、直接接続・プロキシ経由・拒否のいずれかが決まります。そのため、TUNを有効にしてもすべての通信がプロキシ経由になるわけではなく、システムプロキシを使ってもルールモードに限定されるわけではありません。

この記事では、Clash Meta（mihomo）コアを使ったTUN設定を例に解説します。クライアントによって、設定項目やサービスのインストール方法、既定のポートは異なります。また、旧バージョンのClashクライアントでは、ここで紹介する項目に対応していない場合があります。設定前にアプリ名だけで判断せず、クライアントのコア情報で実際にmihomoが動作していることを確認してください。

代表的な2つの接続経路

• システムプロキシ：ブラウザーがOSのプロキシ設定を読み取り、ローカルのHTTPプロキシポートに接続します。その後、コアが通信を振り分けます。
• TUN：アプリは通常どおりIP接続を開始し、条件に合うパケットがOSのルーティングによって仮想ネットワークインターフェースに送られ、コアで処理されます。
• アプリ内プロキシ：Gitやコマンドラインツール、チャットアプリなどにSOCKS5またはHTTPの接続先を個別に設定します。システムプロキシの設定に依存しない、3つ目の接続方法です。

2. 対象範囲を比較：ブラウザー、コマンドライン、UDP

システムプロキシは、アプリが読み取る設定の集まりであり、ネットワーク層で通信を遮断・捕捉する仕組みではありません。WindowsのネットワークAPIやアプリ独自の通信ライブラリ、macOSアプリのプロキシ設定への対応状況はそれぞれ異なります。ブラウザーで使えたとしても、それはブラウザーの接続が通ったことを示すだけで、同じ端末のすべてのアプリが接続されたとは限りません。

UDP対応は接続経路全体の確認が必要

HTTPプロキシポートは汎用UDPトンネルではありません。SOCKS5にはUDP転送の仕様がありますが、アプリが実装しているか、クライアントが受け付けるか、出口ノードが対応しているかは、それぞれ別に確認が必要です。TUNでより多くのUDP通信をコアに送れても、UDP非対応のノードが対応するようになるわけではありません。

たとえばHTTP/3では、UDP 443を使うことがあります。あるWebページがTCPで開けても、QUIC経由の通信が正常とは限りません。ゲームにログインできても音声通話が使えない場合は、ログイン通信と音声通信の接続先、プロトコル、適用ルールをそれぞれ確認してください。遅延テストの数値だけでは判断できません。

3. 権限と設定：プロキシポートと仮想ネットワークインターフェース

システムプロキシ：まずローカルの待ち受けアドレスを確認

ここでは具体例として127.0.0.1:7890を示しますが、すべてのクライアントでこのポートが既定値とは限りません。mihomoのmixed-portでは、同じポートでHTTPとSOCKSのリクエストを受け付けられます。実際の値は、クライアントに表示される混合ポート、または現在有効な設定で確認してください。

# mihomo設定例：ローカルの混合プロキシ
mixed-port: 7890
allow-lan: false
mode: rule

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」でアドレスとポートを確認できます。クライアントが自動構成スクリプトでシステムプロキシを設定している場合もあるため、手動プロキシの項目だけで判断しないでください。macOSでは「システム設定」→「ネットワーク」→利用中のネットワークサービス→「詳細」→「プロキシ」で確認します。ここに表示される接続先が、クライアントの待ち受けポートと一致している必要があります。

この端末だけで使う場合は、ループバックアドレスのままにしてください。ブラウザーで接続できないからといって、待ち受けアドレスをすべてのネットワークインターフェースに変更するのは避けましょう。LANにプロキシを公開する場合は、アクセス制御とファイアウォールの設定も必要です。

TUN：ルーティング設定とバックグラウンドサービスの権限

TUNでは仮想ネットワークインターフェースの作成とルーティングの変更が必要なため、デスクトップクライアントは通常、管理者権限または特権サービスを利用します。Windowsクライアントではサービスモードのインストールが必要な場合があり、macOSクライアントでは特権ヘルパーやネットワーク拡張を使う場合があります。認証方法は実装によって異なり、すべてのmacOS版Clashクライアントが同じネットワーク拡張権限を要求するわけではありません。

# mihomo TUN設定例。サブスクリプション全体ではありません
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

• 現在のmihomoでは、stack: mixedはシステムのTCPスタックとgVisorのUDPスタックを組み合わせて使用します。利用可能な値と互換性は、使用するコアのバージョンで確認してください。
• auto-route: trueは、必要なルートを自動設定します。仮想ネットワークインターフェースを作成できても、ルートが正常に設定されたとは限りません。
• auto-detect-interface: trueは、外向きのネットワークインターフェースを自動検出します。Wi-Fi、有線LAN、他のVPNを併用している場合は、実際の出口も確認してください。
• dns-hijackはtun内の設定項目です。この例ではUDPとTCPの53番ポートへのリクエストを対象にし、内蔵DNSモジュールに処理させます。

4. DNSとIPv6：TUNを有効にしても通信が漏れる原因

通信の取り込みとドメイン名の名前解決は、セットで確認する必要があります。アプリはドメイン名を問い合わせてから接続します。DNSリクエストが別の経路を通ると、名前解決に失敗したり、ルールでドメイン名を判別できなかったり、想定外の接続先につながったりすることがあります。仮想ネットワークインターフェースが表示されているだけでは、DNSの経路が正しいとは判断できません。

53番ポートのハイジャックでは、すべてのDNS通信を捕捉できない

上記のdns-hijackの例は、従来型のDNSを対象としています。ブラウザーのDNS over HTTPSはHTTPS接続を使い、DNS over TLSは通常TCP 853番ポートを使います。53番ポートをハイジャックする設定を追加しても、自動的にコアのDNS問い合わせへ切り替わるわけではありません。切り分ける際は、ブラウザーのセキュアDNSを一時的に無効にして同じ条件で比較し、その結果を踏まえて継続利用する設定を決めてください。

このTUN設定例は、dns.enable: trueのように有効化したmihomoのDNSモジュールと組み合わせ、利用可能な上流DNSも設定する必要があります。fake-ipとredir-hostは名前解決の処理方式であり、TUNの代わりにはなりません。Fake-IPを使う場合は、実際に利用するアプリとの互換性に応じてフィルターリストを設定してください。

IPv6は個別に確認する

ネットワークがIPv4とIPv6の両方を提供していて、現在のクライアントが片方しか正しく取り込めていない場合、アプリがもう一方のアドレスを優先することがあります。切り分けでは両方のアドレスファミリーを個別にテストし、コアのIPv6設定、DNSのAAAAレコード応答、システムルートを確認してください。IPv4のテスト結果だけで、すべての接続がTUNを通ると判断しないでください。

5. 確認方法：接続方法は一度に1つだけ切り替える

「明示的なプロキシ設定→システムプロキシ→TUN」の順に確認するのがおすすめです。テスト中は同じプロキシグループとノードを使い、他のプロキシやVPNは無効にしてください。接続方法を切り替えた後は接続を作り直し、ブラウザーの接続再利用による影響を避けます。以下のコマンドは公開されているサンプルサイトを使った手順例であり、応答時間は実測値ではありません。

1. ポートへの接続を確認する。TUNを無効にし、コマンドでローカルプロキシを明示してアクセスします。ここで失敗する場合は、仮想ネットワークインターフェースの設定に進まず、まずコア、ポート、ノードを確認してください。
2. システムプロキシを確認する。システムプロキシを有効にし、その設定に従うブラウザーで同じ接続先にアクセスします。クライアントの接続一覧で、対象ドメイン、適用ルール、プロキシ経路を確認してください。
3. TUNを確認する。システムプロキシを無効にし、TUNだけを有効にします。コマンドラインからアプリ側のプロキシ設定を使わずにアクセスし、接続ログを確認してください。必要に応じてシステムルートも調べます。
4. 実際に使う通信を確認する。ゲーム、音声通話、LAN内の接続などもテストしてください。Webページが開けても、UDP通信やローカルリソースが正常とは限りません。

# Windows PowerShellではcurl.exeを使用し、旧バージョンのPowerShellにあるcurlのエイリアスを避ける
curl.exe -I --connect-timeout 10 --proxy http://127.0.0.1:7890 https://example.com/

# TUNの比較テスト：curlのプロキシ設定を使わない
curl.exe -I --connect-timeout 10 --noproxy "*" https://example.com/

# IPv4とIPv6を個別にテストする
curl.exe -4 -I --connect-timeout 10 --noproxy "*" https://example.com/
curl.exe -6 -I --connect-timeout 10 --noproxy "*" https://example.com/

macOSとLinuxでは、コマンド内のcurl.exeをcurlに置き換えてください。--noproxy "*"はcurlにアプリ側のプロキシを使わせない設定であり、TUNを迂回するものではありません。HTTPレスポンスを受け取れたことが示すのは、リクエストに応答があったことだけです。プロキシノードを経由したかどうかは、コアの接続ログや出口側の確認とあわせて判断してください。

Windowsではroute printでルートを確認できます。macOSではroute -n get 1.1.1.1で指定したIPv4宛てのルートを、Linuxではip route get 1.1.1.1で経路を確認できます。OSによってインターフェースルートやポリシールーティングを使うため、「特定のデフォルトルートが表示されること」を一律の判定基準にしないでください。

6. 互換性と選び方：必要最小限の範囲で通信を取り込む

システムプロキシが適しているケース

• 主にブラウザーを使い、他のアプリは通常どおりのネットワーク経路を使いたい。
• 業務用端末で企業VPNに接続しており、端末全体のルートを自動変更したくない。
• 一部の開発ツールだけをプロキシ経由にしたい場合は、ツール内にHTTPまたはSOCKS5の接続先を設定できます。

TUNの利用を検討するケース

• 対象のアプリがシステムプロキシを読み取らず、アプリ内にもプロキシ設定がない。
• 対応するUDP通信を対象にしたい。また、使用するノードが必要な機能に対応していることを確認済みである。
• 複数のアプリの通信をまとめてコアに取り込み、ドメイン名、IPアドレス、プロセスなどのルールで振り分けたい。

TUNと他のVPNを併用すると、デフォルトルート、DNS、ネットワーク範囲の重複、戻り経路の競合が起きやすくなります。たとえば企業ネットワークでもプライベートアドレスを使っている場合、「すべてのプライベートIPを直接接続する」といった設定で企業VPNに必要なルートを迂回してしまうことがあります。まず企業ネットワークの宛先セグメントを確認し、クライアントが対応するルート除外やルール機能に沿って設定してください。汎用的なプライベートネットワーク向けルールだけで解決できるとは限りません。

2つの接続方法を同時に有効にすることもできますが、トラブルシューティング中はおすすめしません。アプリがローカルプロキシに明示的に接続し、他のアプリはTUNを通る場合があります。そのため、「片方の設定をオフにしても接続できる」という結果の原因が分かりにくくなります。主な接続方法を1つに絞ると、権限、DNS、ポート、ルールのどこに問題があるのか判断しやすくなります。

プラットフォームごとの違いはシステムガイドで確認できます。サブスクリプションの追加やルールモードの設定は使い方ガイドを参照してください。最終的な判断には、クライアント画面の「有効」表示だけでなく、対象アプリの実際の接続ログを使いましょう。