設定の要点：システムプロキシを使わないアプリにはTUN

ブラウザーはつながるのに、ゲームやコマンドライン、デスクトップアプリがつながらない場合は、そのアプリがシステムプロキシに対応しているか確認しましょう。システムプロキシは、アプリにHTTPプロキシの設定を提供する仕組みです。アプリ側で利用することも、無視することもできます。一方、TUNはネットワーク層で仮想NICにルーティングされたIPパケットを受け取るため、アプリごとにプロキシアドレスを設定する必要がありません。

この記事では、Clash Metaの後継プロジェクトであるmihomoの設定項目を基準に説明します。Clashはカーネルやクライアントのエコシステムを指す一般的な呼び名であり、画面に「TUN」と表示されていても、カーネルやOSが異なれば実装も同じとは限りません。まずクライアントの「バージョン情報」やカーネル情報で実際に使用しているカーネルを確認し、対応する設定を適用してください。

  • ブラウザーだけ使う：通常はシステムプロキシで十分です。問題の切り分けも簡単になります。
  • アプリにプロキシ設定がない：TUNが適しています。ただし、そのアプリのTCP・UDP通信が取り込まれているか確認してください。
  • ゲーム、音声通話、QUIC：TUNに加え、プロキシプロトコルとサーバーがUDP転送に対応しているか確認してください。
  • 会社のVPNやリモートデスクトップを使用中：先に作業内容を保存し、現在のルートとDNSを記録してください。リモート接続しか操作手段がない状態で、安易にデフォルトルートを変更しないでください。

仮想NICの仕組み：IPパケットからルールによる振り分けまで

通信の取り込みは4段階

  1. アプリが接続を開始。アプリがドメイン名またはIPアドレスへの接続を試みると、システムはルーティングテーブルに基づいて送信するNICを決定します。
  2. ルートがTUNに向く。クライアントが仮想NICを作成して必要なルートを設定し、条件に合うパケットがTUNデバイスに入ります。
  3. カーネルが接続を処理。プロトコルスタックがIPパケットを受け取り、宛先アドレスやポート、取得できる場合はドメイン情報を取り出して、ルールエンジンに渡します。
  4. 出力先のポリシーを適用。直接接続する通信は実際のネットワークインターフェースから送信し、プロキシ通信は選択したプロキシ経由で送信します。応答は対応する経路を通ってアプリに戻ります。

ここでいう「仮想NIC」は、物理ネットワークを新たに追加するものではありません。OSとユーザー空間のネットワークプログラムがパケットをやり取りするためのインターフェースです。クライアントはプロキシの出力通信が再びTUNに入ってルーティングループにならないようにする必要があります。そのため、出力インターフェースの識別や権限設定が重要です。

取り込み範囲はルートと除外設定に左右される

auto-route: trueはTUNへのルートを自動設定し、auto-detect-interface: trueは出力インターフェースを自動識別します。ただし、あらゆる状況で通信を取り込める保証ではありません。別のVPNのルート、特定のNICにバインドされたアプリ、クライアントの除外設定、IPv6の設定によって、実際の通信経路は変わることがあります。

IPv4だけを取り込み、アプリがIPv6を優先する場合、一部の接続が別経路から送信されることがあります。「Webページが開く」だけで取り込みが完全だと判断しないでください。対象アプリの接続履歴、ルールの適用状況、実際の出力ポリシーも確認しましょう。TUNは同じLAN内にある他の端末の通信を自動でプロキシするものでもありません。ゲートウェイとして共有するには、転送とルーティングを別途設定する必要があります。

systemとgvisor：スタックを選んでから互換性を確認

stackはTUNのパケットを処理するプロトコルスタックを指定する項目で、ノードのプロトコルやプロキシの暗号化方式ではありません。性能はOS、カーネルのバージョン、接続の種類、デバイスの性能に左右されるため、特定のスタックを一律に「最速」とは言えません。

プロトコルスタック 処理方式 選び方
system OSのネットワークスタックを利用して接続を処理します。具体的な実装はプラットフォームによって異なります。 まずはこれを試し、特定のアプリやUDPで互換性の問題が起きた場合に別のスタックを検証します。
gvisor gVisorベースのユーザー空間ネットワークスタックでパケットを処理します。 systemとの比較テストに適しています。ユーザー空間での処理により、CPU負荷が増える場合があります。
mixed mihomoでは、TCPにsystem、UDPにgvisorを使用します。 TCPとUDPで処理を分けたい場合に利用できます。使用中のカーネルとクライアントがこの設定に対応しているか確認してください。

比較テストでは変更点を1つに絞る

  1. プロキシポリシー、ルールモード、ネットワーク環境を同じにして、まずsystemを試します。
  2. 対象アプリを開いて約60秒間観察し、接続できるか、途中で切れるか、CPU使用率が高い状態で続くかを記録します。
  3. プロトコルスタックだけをgvisorに変更し、カーネルを再起動して同じ操作を繰り返します。
  4. UDPを使うアプリだけに問題がある場合は、プロキシサーバーがUDPに対応しているかも確認してください。すべての問題をプロトコルスタックのせいにしないようにしましょう。

記録例は「system：Web閲覧は正常、音声通話を開始できない／gvisor：Web閲覧は正常、音声通話を開始できる」のように書けます。これは記録方法の例であり、この記事での実測結果ではありません。遅延が40ミリ秒と測定されても、ゲームのUDP通信が正しく転送されている証拠にはなりません。

mihomoの設定：TUN・DNS・ルートをまとめて確認

以下は既存の設定に追加する基本部分で、プロキシサーバー情報やプロキシグループは含みません。既存のサブスクリプションにあるproxies、proxy-groups、rulesは残してください。クライアントの上書き・マージ機能を優先して使い、サブスクリプションから生成されたファイルを直接編集すると、更新時に上書きされる可能性があります。

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

tun:
  enable: true
  stack: system
  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
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

各ポートの役割

  • 7890：HTTPとSOCKSで共用する混合プロキシの待ち受けポートです。システムプロキシや、プロキシを明示的に設定したアプリが接続します。TUNですべてのIPパケットをこのポートに送るわけではありません。
  • 127.0.0.1:1053：ローカルのDNS待ち受けアドレスです。システムの53番ポートを直接使わないための設定であり、システムDNSが自動的にこのアドレスへ変更されるわけではありません。
  • any:53とtcp://any:53：取り込み経路に入った通常のUDP・TCP 53番ポート宛てDNSリクエストを照合し、内蔵DNSで処理します。
  • 198.18.0.1/16：fake-ipで使用するアドレスプールです。カーネルがドメイン名と仮想アドレスを対応付けるためのもので、プロキシサーバーのアドレスではありません。

DNSハイジャックで対応できる範囲

アプリ内蔵のDoHやDoTは通常の53番ポートを使わないため、上記のdns-hijackではDNSの内容を書き換えられません。それらの接続がTUNを通る場合はありますが、内蔵DNSが最終的なドメイン名を把握できるとは限りません。ドメインルールが適用されるかどうかは、fake-ipのマッピング、スニッフィングの設定、実際のプロトコルにも左右されます。

fake-ipモードでは、外部ドメインに対して198.18.0.23のようなアドレスが返ることがあります。これはマッピング結果であり、接続先Webサイトの実IPではありません。LAN内のプリンターやNAS、社内ドメインで互換性の問題が起きた場合は、実際のドメインに応じてフィルターやDNSの振り分けを設定してください。特定の社内ドメインの問題を解決するために、すべてのドメインをfake-ipの対象外にするのは避けましょう。

OS別の設定：権限を許可してからカーネルを起動

メニュー名はクライアントのバージョンによって異なります。以下では一般的な設定項目と操作の目的を説明します。同じ名前のメニューが見つからない場合は、「サービス」「権限」「TUN」「仮想NIC」などを手がかりに該当機能を探してください。他のクライアントの手順が、現在のバージョンにも当てはまるとは限りません。クライアント選びはクライアント比較を参考にしてください。

Windows：サービスモードと仮想NICドライバー

  1. 設定をインポートしたら、まずシステムプロキシを使って同じプロキシポリシーで対象サービスに接続できるか確認します。混合ポートが7890の場合は、アプリ側の設定と一致させてください。
  2. Clash Verge Revでよくある画面を例にすると、「設定」→「サービスモード」を開き、画面の案内に従ってサービスをインストールまたは有効にします。この操作では管理者権限の許可を求められる場合があります。
  3. ホーム画面に戻って「TUNモード」を有効にするか、使用中のバージョンに対応したネットワーク設定からTUNを有効にします。サービスが利用できない場合は、スイッチを何度も切り替えず、先にサービスの状態を解決してください。
  4. カーネルログを確認し、仮想NICとルートの初期化で権限やドライバーのエラーがないことを確かめてから、以前はプロキシを使わなかったアプリをテストします。

Windowsのクライアントでは、Wintunなどの仮想NICドライバーが必要になることがあります。ドライバーの入手とインストールは、クライアントが提供する手順に従ってください。出所不明の場所からドライバーファイルをコピーしないでください。PowerShellでは、現在のNICとIPv4ルートを確認できます。

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

仮想NICの名前はクライアントや設定によって異なり、「Clash」とは限りません。NICが存在するだけではデバイスの作成を確認できるにすぎず、ルートと接続履歴も確認する必要があります。PCで別のVPNも動作している場合は、どちらか一方を終了してからテストし、通信の取り込み機能同士が競合しないようにしてください。

macOS：補助サービスの権限とutunインターフェース

  1. クライアントとそのカーネルがTUNに対応していることを確認してください。システムプロキシ機能しかないクライアントにYAML項目を追加しても、TUN機能が使えるようにはなりません。
  2. クライアントのサービスまたは権限設定を開き、案内に従って補助サービスをインストールし、管理者権限を許可します。
  3. TUNを有効にし、デバイス、ルート、DNSの初期化情報がログに記録されているか確認します。
  4. ターミナルでインターフェースとルートを確認してから、対象アプリを起動して動作を検証します。
ifconfig
netstat -rn -f inet
scutil --dns

macOSでは、utunに番号が付いた仮想インターフェースがよく使われますが、別のVPNやシステムサービスがutunを作成することもあります。utun3が存在するだけでは、現在のクライアントが作成したものとは判断できません。スリープ復帰後やWi-Fiの切り替え後に不具合が起きた場合は、プロキシノードを変えるだけでなく、出力インターフェースを確認してください。

Linux：TUNデバイスとネットワーク管理権限

Linuxでは通常、利用可能な/dev/net/tunと、インターフェースの作成やルート変更に必要なネットワーク管理権限が必要です。デスクトップクライアントではサービスを通じて権限を取得する場合があります。カーネルを直接起動する場合は、ディストリビューションとサービスの構成に応じて権限を設定してください。出所不明の実行ファイルに高い権限を与えたり、手間を省くためにクライアントのディレクトリ全体へ再帰的に権限を付与したりしないでください。

ls -l /dev/net/tun
ip link show
ip rule show
ip route show table all

ルートを確認する際は、すべてのテーブルを確認してください。自動取り込みでポリシールーティングを使うことがあり、ip routeだけではルール全体が見えない場合があります。コンテナ環境では、ホスト側からTUNデバイスと必要な権限を提供する必要があります。コンテナ内でスイッチを有効にしても、ホスト上のアプリの通信を取り込めるとは限りません。

Android・iOS：OSのVPN許可を利用

Androidの一般的なClashクライアントはVpnServiceを使って通信を取り込みます。初回の有効化時にOSのVPN接続許可が表示され、通常はroot権限は不要です。アプリのVPNモード、アプリの除外リスト、OSのバックグラウンド電池制限を確認してください。通常、同じユーザーで有効にできる一般的なVPNサービスは1つだけです。別のVPNを起動すると、現在の接続が置き換えられる場合があります。

iOSでは、クライアント自体がNetwork ExtensionなどのOS機能を提供し、使用許可を得ている必要があります。デスクトップ向けの設定にあるTUN項目を追加しても、この機能を新たに作ることはできません。クライアントの手順に沿ってVPN構成を追加・許可し、対応している設定構文を確認してください。mihomoのTUN設定一式を、構文の異なるiOSクライアントにそのまま適用しないでください。

通信の取り込みを検証：TUNスイッチだけで判断しない

3つのポイントを照合

  1. デバイスとルート：仮想インターフェースが作成され、取り込み用のルートが設定されていること。権限不足やデバイスのオープン失敗がログに繰り返し記録されていないこと。
  2. 対象アプリの接続：以前はシステムプロキシを無視していたアプリを開き、クライアントの「接続」画面で対象アドレスとポートを確認します。HTTPSはTCP 443、QUICはUDP 443が一般的ですが、ポートだけでアプリの種類を特定することはできません。
  3. ルールと出力先：接続に想定したルールとポリシーが適用されていることを確認します。プロキシが必要な接続にDIRECTが適用されていると、TUNが正常でも期待した動作にはなりません。

2つの接続経路を見分けるには、システムプロキシを一時的に無効にし、対象アプリに手動で設定したHTTP・SOCKSプロキシも削除して、TUNだけでテストできます。ブラウザーでインターネットに接続できても、それだけでは十分な証拠になりません。ネットワークから直接そのサイトにアクセスできる場合があるためです。接続履歴と出力ポリシーを照合し、テスト後は必要な設定を元に戻してください。

症状から原因を絞り込む

症状 優先して確認する項目
有効にするとすべてのアプリがオフラインになる サービスの権限、出力インターフェースの識別、DNSへの到達性、別のVPNとのルート競合。
Webは正常だが、音声通話やゲームに問題がある UDPの取り込み、プロキシ側のUDP対応、アプリの除外リストを確認してから、プロトコルスタックを比較テストします。
インターネットにはつながるが、NASやプリンターを利用できない LANのルート、社内DNS、fake-ipのフィルター、現在のネットワークで使われている実際のサブネット。
Wi-Fiを切り替えると動作しなくなる 出力インターフェースが更新されているか、古いルートが残っていないかを確認し、TUNを再度有効にしてからログを確認します。
接続履歴に対象アプリが表示されない アプリが除外されていないか、取り込み対象外のIPv6や特定のインターフェースを使っていないか、ログの記録がフィルターされていないかを確認します。

切り分け中はログレベルを一時的にdebugにし、TUNを有効にした時刻と対象アプリを起動した時刻を正確に記録します。たとえば14:32:10に有効化し、14:32:20にアプリを起動した場合、その前後10秒のデバイス、ルート、DNS、接続エラーを確認します。原因を特定したらinfoに戻してください。ログを共有する際は、サブスクリプションのURL、トークン、個人のネットワーク情報を隠してください。

無効化と復旧：まずネットワークを戻し、それから原因を調べる

PC全体がオフラインになった場合は、まずTUNを無効にし、クライアントに自動ルートを解除させてから、必要に応じてシステムプロキシを元に戻します。クライアントを通常の手順で終了した方が、カーネルを強制終了するより後処理が適切に行われます。終了後も問題が続く場合は、システムプロキシが停止済みの127.0.0.1:7890を参照していないか、DNS、仮想インターフェース、ルートが復旧しているか確認してください。

  • ルーティングテーブル全体を安易に削除しないでください。企業ネットワーク、コンテナ、別のVPNがそのルールに依存している場合があります。
  • すべての仮想NICをむやみに無効化しないでください。クライアントのログとインターフェースの変化を確認し、現在のクライアントが作成したデバイスを特定してください。
  • fake-ipのキャッシュによりアプリが仮想アドレスを取得し続ける場合は、アプリを終了して再起動してください。必要に応じてOSの方法でDNSキャッシュを更新します。
  • ネットワークが復旧したら、「権限とデバイス → ルートと出力先 → DNS → ルールとポリシー → アプリのプロトコル」の順で再試行し、1回につき設定を1つだけ変更してください。

最終的に残すのは、仕組みを説明でき、動作を検証でき、元に戻せる設定です。TUNが通信を取り込み、DNSがドメイン情報を提供し、ルールが出力先を決め、プロキシサービスが実際の接続を担います。各項目の詳細は設定の応用：TUN設定を、サブスクリプションを初めて読み込む場合はクイックスタートを参照してください。