まずTUNモードが必要か確認する

まずシステムプロキシでノードと設定が正常に動作するか確認してから、TUNを有効にしましょう。ブラウザーでは問題なくアクセスできるのに、コマンドラインやゲームなど、システムプロキシを参照しないアプリが直接接続してしまう場合は、仮想NICで通信を取り込むことを検討します。TUNを有効にしても、使えないノードが直るわけではなく、UDP転送に対応していないノードがUDP通信に使えるようになるわけでもありません。

TUNはOSが提供するレイヤー3の仮想ネットワークインターフェースです。アプリが送信したIPパケットがこのインターフェースにルーティングされると、カーネルがパケットを読み取って接続を識別し、ルールに従って直接接続するかプロキシ経由にするかを決定します。一部アプリのプロキシ要求だけを扱うシステムプロキシとは、処理するレイヤーが異なります。

比較項目システムプロキシTUNモード
通信を取り込む仕組みアプリがOSのHTTPなどのプロキシ設定を参照OSのルーティングによってIPパケットを仮想NICへ転送
主な対象アプリブラウザーやシステムプロキシに対応したアプリプロキシ設定に対応していないアプリ、一部のゲームやターミナルツール
UDP通信通常のHTTPシステムプロキシでは対象外処理可能。ただしノードのプロトコルやリモート側の機能に依存
必要な権限通常はユーザー単位のプロキシ設定を変更するだけデスクトップでは通常、サービス権限や管理者権限、ネットワーク管理権限が必要
よくあるトラブルプロキシポートの誤り、アプリがシステム設定を無視ルートの競合、DNSの異常、権限不足、他のVPNとの干渉

有効化前にカーネル・設定・権限を確認する

TUN設定が明示され、現在もメンテナンスされているクライアントを優先しましょう。以下のYAML項目はmihomoを例にしています。旧版Clashや異なる派生カーネル、モバイル版クライアントでは、対応項目がすべて同じとは限りません。アプリ名だけで互換性を判断せず、クライアントの「バージョン情報」やカーネル情報で実際に動作しているカーネルを確認してください。

  1. 現在の設定を使える状態で保存します。設定をエクスポートし、システムプロキシのポート、現在のモード、選択中のポリシーを控えておきましょう。サブスクリプションの更新でファイルに直接加えた変更が上書きされることがあるため、クライアントのオーバーライド機能や設定のマージ機能を優先してください。
  2. ノードの動作を確認します。先にシステムプロキシを有効にし、実際にプロキシ経由でアクセスする必要があるWebサイトを開いてください。遅延テストでミリ秒単位の数値が表示されるだけでは、目的のWebサイトやUDP通信が利用できる証明にはなりません。
  3. 他の通信制御ツールを一時停止します。他のVPN、ゲーム用の通信最適化ツール、別のTUNクライアントを一時的に切断してください。会社の端末で使われているセキュリティソフトやVPNは、管理ルールに従って扱い、無断で削除しないでください。
  4. LAN内へのアクセス先を確認します。ルーター、NAS、プリンターのアドレス（例：192.168.1.1）を控えておきます。有効化後はこれらにも再度アクセスし、インターネット側だけでなくLAN内の通信も確認してください。

システムプロキシのポートとDNSの待ち受けポートは用途が異なります。たとえば混合プロキシポートには7890、DNSの待ち受けには127.0.0.1:1053を設定できます。実際に使用する値は現在有効な設定を確認してください。プロキシポートをシステムDNSアドレスに指定しないでください。

OS別に仮想NICを有効にする

Windows：サービスをインストールしてからTUNを有効にする

mihomoを使用するデスクトップクライアントでは、まず「設定」を開き、「サービスモード」または「サービス管理」からサービスをインストールして、実行中であることを確認します。サービスのインストール時にWindowsユーザーアカウント制御の確認が表示されることがあります。その後、ホーム画面またはプロキシ設定に戻り、「TUNモード」または「仮想NICモード」を有効にします。具体的な項目名や場所は、使用中のクライアント画面で確認してください。

  1. 最初は「ルールモード」のままにし、動作確認済みのポリシーを選びます。
  2. サービスモードを有効にしてからTUNを有効にします。クライアントに「自動ルート設定」や「出力インターフェースの自動検出」がある場合は、まず既定の有効設定を使ってください。
  3. ログに権限拒否、NICの作成失敗、ルート追加失敗が記録されていないか確認します。スイッチがオンでも、ログにエラーが出ていれば通信を取り込めているとは限りません。
  4. システムプロキシを無効にしてからアプリの接続を再確立し、ブラウザー、ターミナル、LAN内へのアクセスをテストします。

クライアントにサービスモードがない場合、管理者としての実行が必要なことがあります。まずクライアントの権限に関する説明を確認してください。通常権限と管理者権限でクライアントを同時に起動すると、ポートの競合やルートの取り合いが起きやすいため避けてください。

macOS：ヘルパープログラムまたはネットワーク権限を許可する

クライアントのTUN設定またはネットワーク設定を開き、案内に従って特権ヘルパープログラムをインストールし、管理者パスワードを入力するか、システムが求めるネットワーク関連の権限を許可します。クライアントによって仕組みが異なります。システムから該当する許可を求められた場合にのみ承認し、出所のわからない拡張機能を手動でインストールしないでください。

有効化後、ifconfigでネットワークインターフェースを確認し、クライアントのログと照らし合わせて作成状況を確認します。macOSのutunインターフェースは、システムサービスや別のVPNによって作成される場合もあります。utun0やutun1が表示されただけでは、使用中のClashのTUNが正常に動作している証拠にはなりません。

Linux：TUNデバイスとネットワーク管理権限を確認する

まず、システムに/dev/net/tunがあるか確認します。カーネルには、仮想NICの作成やルート変更に必要な権限が必要です。GUIクライアントでは通常、補助サービスを通じて権限を取得します。コマンドラインで運用する場合は、サービスの権限設定が適切であることを確認してください。一般ユーザーに設定ファイルの読み書き権限を与えるだけでは、ルート操作が拒否される問題は解決しません。

test -c /dev/net/tun && echo "TUN デバイスが存在します"
ip link show
ip rule show
ip route show table all
ip route get 1.1.1.1

これらのコマンドは状態を確認するもので、ネットワーク設定は変更しません。Docker、LXC、制限付きVPSで動かす場合は、ホスト環境でTUNデバイスの使用が許可され、必要なネットワーク権限が付与されている必要があります。コンテナ内でrootになっても、ホストのネットワークを管理できるとは限りません。リモートサーバーのデフォルトルートを変更する前に、コンソールなどの帯域外アクセス手段を用意してください。

Android・iOS：OSのVPN許可画面から接続する

Androidでは、対応クライアントは通常、OSのVPNサービスを使って通信を取り込みます。初回接続時にVPN接続の要求が表示されますが、通常root権限は不要です。アプリごとのプロキシを有効にすると、選択したアプリだけが通信の取り込み対象になります。OSで同時に有効にできる一般的なVPNサービスは通常1つです。別のVPNに接続すると、現在のクライアントが切断されることがあります。

iOSでは、クライアントが提供するVPN設定と接続画面を使い、システムの案内に従って構成を追加してください。デスクトップ版のサービスインストール手順はiOSでは使えず、デスクトップ向けのTUN YAMLをそのまま適用することもできません。モバイルでは、アプリごとの除外設定、LANアクセス、バックグラウンド動作も確認してください。

mihomoのTUNとDNSハイジャックを設定する

まず設定項目を既存の設定に統合し、その後で設定を再読み込みします。以下は、使用可能なノード、ポリシーグループ、ルールがすでにある場合の抜粋であり、単独で使える完全なサブスクリプションではありません。同じトップレベル項目は1つだけにしてください。特にdns:やtun:を重複して追加しないでください。

mixed-port: 7890
mode: rule

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:
    - 223.5.5.5
    - 119.29.29.29

重要な3つの設定項目

  • auto-route：通信を取り込むためのルートをカーネルに自動設定させます。無効にすると通常はルートを手動で管理する必要があるため、初回のトラブルシューティング中に安易に切り替えるのは避けてください。
  • auto-detect-interface：外部への接続に使うNICを自動判別し、プロキシの送信通信がTUNに戻るループを防ぎます。複数のNICや他のVPN、特殊なルーティング環境では、実際の出口も確認してください。
  • dns-hijack：TUNに入る指定のDNS通信を内蔵DNSに渡します。例では一般的なUDP 53とTCP 53を対象にしています。アプリ内蔵のDoHやDoTを自動で復号したり、すべて取り込んだりする設定ではありません。

stack: systemはシステムプロトコルスタックを使う指定です。mihomoにはほかのスタックもありますが、実際に使えるかどうかや動作はカーネルのバージョンとプラットフォームによって異なります。まずはクライアントの推奨設定を使いましょう。互換性の問題が発生した場合に限り、スタックだけを切り替えて再テストしてください。ルート、DNS、MTUを同時に変更するのは避けます。

Fake-IPアドレスと実際の接続先アドレスを区別する

Fake-IPモードでは、ドメインに内部マッピング用のアドレス（例：198.18.0.1/16の範囲内のアドレス）が割り当てられます。カーネルはそのマッピングからドメイン情報を復元してルールを適用します。そのため、名前解決結果がこの範囲のアドレスでも、Webサーバーが実際にそのネットワーク上にあるわけでも、名前解決に失敗したわけでもありません。

上の例では設定の構成を示すため、IPv4のDNSサーバーを2つ指定しています。実際には到達可能で、ルーティングの要件に合った名前解決方法を選んでください。dns.ipv6: falseはDNSモジュールがAAAAレコードを返さないようにする設定です。OSのIPv6を無効にするものではなく、すべてのIPv6通信が取り込まれることを保証するものでもありません。アプリ独自の暗号化DNS、キャッシュ、固定IPアドレスは別の経路を使う場合があります。

通信が実際にTUNを通っているか確認する

2つの通信経路を切り分けるには、システムプロキシを無効にしてからテストしてください。ターミナルにHTTP_PROXY、HTTPS_PROXY、ALL_PROXYが設定されている場合は、これらの環境変数も使わずにテストします。設定したままだと、リクエストに成功しても明示的なプロキシが動作したことしか確認できません。

curl --noproxy "*" -I --connect-timeout 10 https://example.com

Windows PowerShellでは、実際のcurlプログラムを呼び出すためにcurl.exeを使えます。ここでの--noproxy "*"はcurlに設定された明示的なプロキシを回避するもので、OSのTUNルートを回避するものではありません。そのため、クライアントの接続一覧を見ながら取り込み状況を確認するのに適しています。例のWebサイトは基本的なHTTPS確認用です。実際に利用する接続先でもテストしてください。

  1. 接続一覧を確認します。作成された接続を見つけ、接続先のドメインまたはIP、適用されたルール、最終的に選択されたポリシーを確認してください。
  2. 直接接続する宛先を確認します。ルーターやNASにアクセスし、LAN接続が正常で、リモートノードを経由していないことを確認してください。
  3. プロキシ経由の宛先を確認します。実際にプロキシが必要なアプリをテストし、想定したポリシーが適用されていることを確認してください。
  4. UDP通信を個別にテストします。実際の音声通話、ゲーム、その他のUDP通信で確認してください。HTTPリクエストの成功やノードの遅延が正常であることは、UDPのテストの代わりにはなりません。

モードを切り替えた後は接続を作り直してください。ブラウザーの持続接続、ゲームのセッション、ダウンロードが古い接続を使い続ける場合があります。スイッチを切り替えただけでリクエストを再実行しないと、キャッシュされた結果を現在の状態と誤認するおそれがあります。

TUNを有効にした後に接続できない場合の対処法

まず障害が起きているレイヤーを切り分ける

症状まず確認する項目次に行う操作
有効にするとすべての通信が切れるカーネルログ、サービス権限、他のVPN、出力NICTUNを無効にして通信を復旧し、ルートの競合を1つずつ除外する
ドメインへの接続は失敗するが、IPアドレスへの接続は成功するDNSサーバーへの接続、ハイジャック設定、アプリ内蔵DNSDNSエラーを確認し、解析設定を一時的に簡略化して再テストする
Webサイトは使えるが、ゲームや音声通話は使えないノードのUDP対応、適用ルール、リモート側の制限UDP対応を確認した出口を使い、通信を再接続する
インターネットには接続できるが、NASやプリンターに接続できないLANルート、内部ドメインの名前解決、直接接続ルールまずLAN内のIPアドレスでテストし、その後内部DNSを確認する
Wi-Fiを切り替えると使えなくなる古い出力NIC、ルート、DNSの状態クライアントを再接続し、新しいデフォルト出口を確認する
小さなリクエストは成功するが、大きなページの読み込みが止まるMTU、経路上のフラグメンテーション、ノードの接続品質ほかの設定は変えず、MTUだけを調整して比較する

権限、ルート、DNS、ポリシーの順に確認する

まずログを確認します。permission deniedなど、操作が拒否されたメッセージが出ている場合は、サービスの権限を優先して解決してください。ポート使用中のエラーが出た場合は、カーネルを重複起動していないか確認します。この段階でノードを何度も切り替えても、通常は解決しません。

次に出口とルートを確認します。TUNはアプリの通信をカーネルに渡しますが、カーネルがプロキシサーバーへ接続するには、物理ネットワークへの経路が必要です。プロキシの送信通信までTUNに戻されると、ループが発生する可能性があります。複数NICの端末では、実際に使われているデフォルト出口を確認してください。必要に応じて、使用中のカーネルのドキュメントに従って出力NICを指定し、システムのルートをすべて削除することは避けてください。

続いてDNSを確認します。nslookup example.comで名前解決結果を確認できますが、表示されたDNSサーバーとカーネルログも併せて判断してください。Fake-IPで内部マッピング用のアドレスが返るのは正常です。タイムアウト、接続拒否、上流DNSに到達できないといったエラーがあれば、原因をさらに調べます。ブラウザーでセキュアDNSが有効な場合は、システムとブラウザーの名前解決結果も個別に比較してください。

最後に適用ルールとポリシーを確認します。ルールモードで直接接続のルールが広すぎると、対象がプロキシを迂回することがあります。選択中のポリシーグループがDIRECTを指している場合もあります。既知の正常なポリシーに一時的に切り替えて比較すると原因の特定に役立ちますが、調査後は元のルーティング設定に戻し、新しい接続に実際に適用されたルールを確認してください。

症状が一致する場合だけMTUを調整する

接続は確立するものの大きなデータの転送が止まる場合や、特定のネットワークで安定して再現する場合に限り、MTUの調整を検討します。現在値を記録してから、一時的にmtu: 1400を試し、必要であれば1280もテストします。一度に変更する項目は1つだけにしてください。これらは原因調査用の候補値であり、すべての光回線、モバイル回線、トンネル環境に共通する最適値ではありません。

TUNを無効にしてネットワークを復旧する

まずクライアントでTUNを無効にしてから、クライアントを通常の手順で終了し、カーネルに自動ルートを削除させます。システムプロキシも有効にしていた場合は、別途無効にしてください。TUNをオフにしても、システムプロキシの設定が元に戻るとは限りません。

  • 別のプロキシクライアントやVPNが起動したままになっていないか確認します。
  • 手動で設定したシステムDNSを元の設定に戻します。以前自動取得だった場合は、自動取得に戻してください。
  • ネットワークの異常が続く場合は、Wi-Fiまたは有線ネットワークに再接続してからデフォルトルートを確認し、必要に応じてシステムを再起動します。
  • リモート端末では、事前に用意したコンソールからの復旧を優先してください。ルートの全消去やファイアウォールのリセットを、確認せずに実行しないでください。

再度有効にする際は、「使用可能なノード、ルールモード、TUNクライアント1つ」の最小構成にします。カスタムDNS、アプリごとの除外設定、その他のネットワークツールを1つずつ戻し、その都度テストしてください。設定を繰り返し変えるより、どの項目が結果に影響したかを特定しやすくなります。