応用設定 読了目安：12分

仮想ネットワークインターフェースとルーティングテーブルの仕組みから、システムプロキシを使わないアプリの通信をTUNで取り込める理由まで解説。stack、auto-route、dns-hijackの設定手順とトラブル対処も紹介します。

TUNモード：IP層でアプリの通信を受け取る

TUNモード：IP層でアプリの通信を受信

TUNは仮想ネットワークインターフェースです。OSはルーティング条件に合致したIPパケットをこのインターフェースに送り、プロキシコアがパケットを読み取ります。その後、宛先アドレスやドメイン、ルールに基づいて、直接接続するかプロキシノードに転送するかを決定します。システムプロキシとの違いは、まず通信を受け取る場所にあり、ノードの速度ではありません。

システムプロキシは通常、HTTPまたはSOCKSプロキシのアドレスをアプリに知らせます。たとえば 127.0.0.1:7890 のように指定します。ブラウザーはこの設定に従うことがありますが、コマンドラインツールやゲーム、独自のネットワークスタックを持つプログラムは従わない場合があります。TUNはシステムルートを使って通信を誘導するため、システムプロキシ設定を参照しない一部のプログラムの通信も受信できます。

アプリがドメイン名を解決し、実際のIPアドレスまたはコアが割り当てたFake-IPを取得します。

  1. アプリがTCPまたはUDP接続を開始し、OSがルーティングテーブルを参照して仮想インターフェースを選びます。
  2. TUNプロトコルスタックがパケットを処理し、コアが接続情報を復元してルールを照合します。
  3. コアが物理ネットワークインターフェース経由で直接接続またはプロキシ接続を確立し、応答をアプリに返します。
  4. ここでいう「すべての通信」とは、システムレベルで通信を誘導できるという意味であり、あらゆるネットワーク通信を必ず取り込めるわけではありません。物理インターフェースに明示的にバインドされたアプリ、仮想マシンやコンテナ内のネットワーク、除外されたサブネット、取り込まれていないIPv6ルートなどは、別の経路を通る場合があります。LANブロードキャストやレイヤー2の探索プロトコルも、一般的なTUNプロキシ通信として扱えるとは限りません。

有効化する前に確認すること：コア、権限、設定の保存先

有効化する前に確認：コア、権限、設定の適用元

以下の設定例は、各フィールドに対応したmihomoコアを対象としています。Clashオリジナル版、旧Premiumコア、mihomoでは、TUNの機能や設定項目が完全には一致しません。また、クライアント名だけでは使用中のコアを判断できません。クライアントのコア情報やバージョン情報、起動ログでコア名とバージョンを確認し、該当バージョンの設定項目を参照してください。

現在の設定をエクスポートし、サブスクリプションの更新で変更が上書きされないか確認してください。クライアントが設定の上書き、マージ、拡張に対応している場合は、その仕組みを使ってTUNの設定を保存します。サブスクリプションから生成された一時ファイルを編集すると、次回の更新や再起動で変更が失われることがあります。共通の設定項目は設定リファレンスで確認できます。

最小構成：まず通信の取り込みを確認し、その後プロキシルールを適用

以下はデスクトップ環境の切り分けに使う、完全な最小構成例です。すべての接続を直接接続にして、仮想インターフェース、ルート、DNSが機能するか確認します。利用可能なプロキシノードを提供する設定ではありません。7890はこの例の混合プロキシポート、1053はローカルDNSの待ち受けポートで、用途は異なります。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

rules:
  - MATCH,DIRECT

この例では切り分けやすいよう、DNSの上流に通常のDNSを使用しています。暗号化通信には対応しないため、ネットワーク環境やプライバシー要件に合わせて変更してください。ipv6: falseは初期の切り分け範囲を狭める設定です。OSのIPv6を無効にするものではなく、ほかのプログラムがOSのIPv6経路で通信しないことを保証するものでもありません。

mihomo TUNプロトコルスタックの比較

処理方式選ぶ際のポイントシステムのプロトコルスタックを使って接続を処理します。
system互換性を比較する際の基準にできますが、具体的な挙動はプラットフォームによって異なります。ユーザー空間のネットワークプロトコルスタックを使います。
gvisor接続に互換性の問題がある場合、ほかの方式と比較テストできます。TCPにはsystem、UDPにはgVisorを使用します。
mixedこのオプションに対応するmihomoバージョンで、最初に試す設定として適しています。このオプションに対応するmihomoのバージョンで、初期設定として使えます。

特定のstackがすべての環境で高速になるとは限りません。OSやコアのバージョン、通信内容によって結果は変わります。比較時はstackだけを変更し、コアを再起動してから新しい接続を確立してください。既存の長時間接続では切り替えの効果を正しく判断できません。

auto-routeとauto-detect-interface

auto-route: trueを設定すると、TUNへ通信を誘導するルートがコアによって自動設定されます。プロキシルールを切り替える設定ではありません。auto-detect-interface: trueは、出力インターフェースを自動選択します。プロキシ接続を実際のネットワーク出口から送信し、TUNへ戻ってループするのを防ぐために使います。

複数のネットワークアダプターや別のVPN、企業向け専用線、仮想スイッチがある環境では、自動検出で意図した出口が選ばれないことがあります。まずルートとインターフェースを確認し、必要に応じて、使用中のコアが対応するinterface-nameなどの設定項目で出口を指定してください。他のPCのインターフェース名を流用しないでください。Wi-Fiと有線接続を切り替えると、インターフェース名が変わる場合もあります。

DNSの取り込み：dns-hijackとFake-IPの関係

dns-hijackは、TUNに入り、対象に一致したDNS通信をコアのDNSモジュールに渡します。この例のany:53はUDP 53、tcp://any:53はTCP 53に対応します。あらゆる名前解決方式を横取りする設定ではなく、すべての通信をローカルの1053番ポートに転送する設定でもありません。

Fake-IPモードでは、コアがアプリにマッピング用アドレスを返すことがあります。たとえば198.18.0.2を返し、後続の接続でそのマッピングからドメインを特定します。これによりドメインルールを適用しやすくなりますが、このアドレスがWebサーバーの実IPという意味ではありません。例にある198.18.0.1/16はマッピング用アドレスプールです。通常の公開宛先アドレスとして到達性をテストしないでください。

一部のLANサービスやアプリは、DNSの応答を独自に検証します。その場合は問題に応じてfake-ip-filterを設定し、特定のドメインに実IPを返す必要があります。すべてのドメインを除外すると、DNSの動作全体が変わるため避けてください。Fake-IPと実IPによる名前解決を切り替えた後は、テスト対象のアプリを再起動し、古いDNSキャッシュを消去して、以前のマッピングが使われないようにします。

有効化の手順：依存関係に沿って確認

  1. まず基本のネットワークを確認：TUNを無効にし、現在のネットワークが使えることを確認します。プロキシ設定がある場合は、先にシステムプロキシ経由でノードとプロキシグループが使えることを確認してください。ノードの問題を仮想インターフェースの問題と誤認しないためです。
  2. 権限を確認：クライアントの手順に従ってサービスを有効にするか、システム権限を許可します。Linuxではまず/dev/net/tunが存在することを確認してください。画面上のスイッチの色だけで判断しないでください。
  3. システムプロキシを一時的に無効化：ブラウザーが古いプロキシ設定を使って通信する影響を除外します。TUNとシステムプロキシは併用できますが、初回の検証では経路を分けて確認してください。
  4. 新しい接続を開始：テスト対象のアプリを終了して再起動し、クライアントの接続一覧で宛先ドメイン、宛先IP、ネットワーク種別、適用されたルールを確認します。
  5. 通常のルールに戻す：すべて直接接続する最小構成で検証した後、元のプロキシグループとルールを使い、直接接続とプロキシ接続それぞれの出口を確認します。
  6. 通常のルールに戻す：最小構成で直接接続を確認した後、既存のプロキシグループとルールを適用し、直接接続とプロキシ接続それぞれの出口を確認します。

クライアントの起動時にシステムプロキシが自動で再有効化される場合があるため、スイッチを再確認してください。アプリに保存されたSOCKS設定や、ターミナルの環境変数HTTP_PROXY、ALL_PROXYも通信経路に影響します。システムプロキシを無効にしただけで、接続が必ずTUN経由だとは判断できません。

ルートと名前解決の結果を確認

# Windows：PowerShellで実行

# macOS：ターミナルで実行
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Resolve-DnsName example.com

# Linux：メインルートとポリシールートを確認
ifconfig
netstat -rn -f inet
route -n get 1.1.1.1

名前解決テストでFake-IPが返っても、特定のDNS経路が使われたと分かるだけで、アプリの接続が正しくプロキシされている証拠にはなりません。接続履歴と出口の両方を確認してください。新しい接続がコアに入り、意図したルールとポリシーが適用されていることを確かめたうえで、対象サービスへの実際のアクセス結果を確認します。
ip link show
ip rule show
ip route show table all
ip route get 1.1.1.1

よくあるトラブル：インターフェース、ルート、DNS、出口の順に確認

有効にしても仮想インターフェースが作成されない

有効にしても仮想インターフェースが作成されない

サービスが実行中か、権限の許可が完了しているか、起動ログにエラーがないかを優先して確認してください。また、実際に読み込まれている設定にtun.enable: trueが含まれているか確認します。画面上のスイッチ設定が構成ファイルで上書きされている場合や、コアの起動失敗により反映されていない場合があります。この状況でDNSを変更しても、通常は解決につながりません。

有効化するとすべてのアプリが通信できない

ドメインでは接続できないのに既知のIPアドレスには接続できる場合は、名前解決の経路を重点的に確認します。逆に、DNSの応答はあるのに接続がタイムアウトする場合は、ルーティング、ポリシー、ノードを確認してください。IPアドレスを直接指定したHTTPSサイトへのアクセスは、証明書や仮想ホストの仕組みによって失敗することがあります。それだけでネットワークが切断されているとは判断できません。

ブラウザーは使えるが、ゲームや音声通話が失敗する

ブラウザーは使えるのにゲームや通話が失敗する

LAN機器、プリンター、社内リソースにアクセスできない

LAN機器、プリンター、社内リソースにアクセスできない

宛先がプライベートIPアドレスか、他のVPNやルートのネットワーク範囲と重複していないか確認してください。IP-CIDR,192.168.0.0/16,DIRECT,no-resolveはポリシー層で直接接続するルールの例ですが、直接接続でもTUNによる通信の取り込みを経由する場合があります。ルート層でネットワーク範囲を除外する必要がある場合は、使用中のコアが対応するルート除外項目を確認してください。これはDIRECTルールを追加することとは別の操作です。

無効にしてもネットワークが復旧しない

まずクライアントを通常の手順で終了し、コアに仮想インターフェースとルートを削除させてください。その後、システムプロキシの接続先が、すでに待ち受けを停止した127.0.0.1:7890のままになっていないか確認します。必要に応じてネットワークに再接続するか、システムを再起動してください。企業ネットワークのルートの用途が分からない場合、ルートテーブルの項目をまとめて削除しないでください。

TUNが必要なケース、システムプロキシで十分なケース

ブラウザーだけを使う場合は、システムプロキシのほうが状態を確認しやすく、トラブルシューティングも簡単です。システムプロキシに従わないアプリがある場合、より多くのTCP・UDP通信をまとめて処理したい場合、またはシステムレベルの経路にルールを適用したい場合は、TUNを検討してください。通信を取り込む範囲が広がる一方で、権限、ルート、DNSの設定管理も必要になります。

クライアントのインストーラーと使い方ガイド

Clashをダウンロード