1. システムプロキシとTUNでは通信を処理する場所が異なる

ブラウザーではWebサイトにアクセスできるのに、ターミナルのツールやゲーム、アップデーターは接続に失敗することがあります。まず、アプリがプロキシを利用しているか確認しましょう。システムプロキシはOSの設定にプロキシサーバーのアドレスを登録する仕組みです。アプリ側が設定を読み取り、それに従って初めて通信がClashに渡ります。アプリが独自にTCPやUDP接続を行う場合、システムプロキシを有効にしただけでは通信経路は変わりません。

TUNはIPパケットを処理するレイヤー3の仮想ネットワークインターフェースです。有効にすると、カーネルとクライアントが連携してインターフェースを作成し、ルーティングを変更して、条件に合うパケットをプロキシカーネルへ送ります。アプリがHTTPプロキシやSOCKSプロキシに対応している必要はありません。ただし、ルーティング、権限、カーネルの対応状況などの条件を満たす必要があります。

方式通信を取り込む場所動作確認に適したケース
システムプロキシアプリがシステムプロキシ設定を参照ブラウザー、システム設定に従うデスクトップアプリ
明示的なプロキシアプリにローカルプロキシのアドレスを指定curl --proxy、ターミナルの環境変数
TUNモード仮想NICとシステムルーティングシステムプロキシを参照しないアプリ、対応するUDP通信

この記事のYAML設定例はmihomoを基準にしています。旧Clashカーネルや各種フォーク、モバイル版クライアントでは、対応機能が異なる場合があります。トラブルシューティングの前に、クライアントの「バージョン情報」やカーネル情報で実際に動作しているカーネル名を確認してください。アプリ名にClashが含まれているかどうかだけでは判断できません。

2. パケット、ルーティング、DNSの連携

アプリから外部への通信経路

  1. アプリがドメイン名を名前解決し、接続先IPアドレスへ通信を開始します。
  2. OSがルーティングテーブルを参照し、TUNのルーティング条件に合うパケットを仮想インターフェースへ送ります。
  3. mihomoがパケットを読み取り、接続先アドレス、ドメイン名との対応情報、ルールの照合結果をもとに処理方針を選択します。
  4. カーネルが物理NICを介して直接またはプロキシ経由で接続し、応答をアプリへ返します。

ルーターや無線LAN、モバイルネットワークへの接続には、引き続き物理NICを使用します。TUNが実際のネットワーク回線に置き換わるわけではなく、ノードの帯域を自動的に改善するものでもありません。カーネル自身の外向き通信が再びTUNに入ってループしないようにする必要があります。自動出口インターフェース検出、インターフェースのバインド、ルーティング処理はこのために使われます。別のVPNを同時に使用すると、デフォルトルートやポリシールーティングが競合する場合があります。

DNSが動作の成否を左右する理由

ルールはドメイン名で照合する場合がありますが、ネットワークパケットに含まれるのは主にIPアドレスです。DNSリクエストがカーネルを通らないと、ドメイン名との対応情報が不足する可能性があります。カーネルのDNS機能を有効にし、通常のDNSリクエストをそこへ送ると、ドメイン名に基づくルールと接続記録を対応させやすくなります。

fake-ipモードでは、アプリに合成アドレスを返せます。たとえば、198.18.0.1/16の範囲からアドレスを割り当て、カーネルがマッピング情報を使って接続先のドメイン名を特定します。このアドレスは接続先サイトの実IPアドレスではなく、ノードのIPとして扱うものでもありません。デバイス検出やLAN内サービス、実際の名前解決結果に依存するアプリなどでは例外が必要な場合があります。対象のドメインに応じてfake-ip-filterを調整してください。

  • dns-hijackが取り込むのは条件に合うDNS通信であり、暗号化DNS通信すべてではありません。
  • ブラウザー内蔵のDoHは通常HTTPSを使うため、53番ポートを取り込むだけでは処理できません。
  • アプリにキャッシュ済みの名前解決結果は、設定を変更してもすぐには消えません。DNS設定の変更後はテストするアプリを再起動し、必要に応じてシステムのDNSキャッシュをクリアしてください。

3. mihomoの設定と起動前の確認

まずTUNを無効にした状態で、ローカルの混合ポートを使い、サブスクリプション、ノード、ルールが動作することを確認します。ここではローカルプロキシのアドレスを127.0.0.1:7890としています。クライアントに別のポートが表示されている場合は、テストコマンドも合わせて変更してください。ノードに接続できない場合は、仮想NICの問題と誤認しないよう、先にノードやサブスクリプションを修復します。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

Windows PowerShellではcurl.exeを使うと、旧バージョンの環境でcurlが別のコマンドとして解釈されるのを避けられます。HTTPレスポンスが返れば、今回のプロキシリクエストが接続先サーバーに届いたことを確認できます。ただし、すべてのサイトやUDP通信、TUNが正常に動作することを示すものではありません。

既存の設定に追加する例

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

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
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
設定項目役割確認ポイント
stack: mixedmihomoでシステムスタックとユーザー空間スタックを組み合わせるmixed-portとは別の設定項目であり、同じ意味ではありません
auto-routeTUNへのルートを自動追加システム権限が必要です。既存のVPNルートと競合する場合があります
auto-detect-interface外向きインターフェースを自動検出複数のNIC、仮想マシン、VPNを使用している環境では、実際の出口も確認してください
dns.listenローカルDNSリスナーを提供1053に設定してもシステムが自動的にこのポートを使うわけではありません。DNSの取り込みや別の転送設定が必要です

GUIクライアントでは、最終的な設定ファイルが自動生成されることがよくあります。サブスクリプションのキャッシュファイルを直接編集すると、更新時に変更が失われる可能性があります。クライアントのオーバーライド、設定のマージ、TUN設定機能を利用してください。トップレベルにtunやdnsキーを重複して追加しないでください。編集画面のテキストだけでなく、実際に読み込まれた設定と起動ログも確認します。

4. OSごとの設定手順と必要な権限

Windows：サービス権限を確認してから仮想NICを有効にする

  1. 使用しているクライアントの設定で「サービスモード」やサービスのインストール項目を探し、案内に従って管理者権限を許可します。クライアントによっては、管理者として直接実行する方法もあります。詳しくはクライアントの説明を確認してください。
  2. サービスが正常に動作していることを確認してから、「TUNモード」または「仮想NICモード」を有効にします。Clash Verge Revでは、「設定」から「サービスモード」と「仮想NICモード」を探してください。リリースによって項目の分類や名称が異なる場合があります。
  3. ログを開き、権限不足、デバイスの作成失敗、ルートの追加失敗が記録されていないか確認します。画面上でスイッチがオンになっていても、操作が送信されたことを示すだけで、カーネルが正常に通信を取り込んだとは限りません。
  4. Get-NetAdapterでネットワークインターフェースを確認し、route printで有効化の前後にルートを比較します。実装によっては分割ルートやポリシールーティングを使うため、表示上のデフォルトルートが直接置き換わるとは限りません。

組織管理のデバイスで仮想NICやバックグラウンドサービスのインストールが禁止されている場合は、デバイス管理者に権限ポリシーを確認してもらってください。テストのためにシステムファイアウォール全体を無効にしないでください。まずクライアントとカーネルの許可ルールを確認し、ログから失敗した手順を特定します。

macOS：特権ヘルパーを許可し、出口を確認する

デスクトップクライアントでTUNインターフェースの作成、ルーティング、DNSの変更を行うには、通常、特権ヘルパーのインストールまたは許可が必要です。アプリの案内に従ってシステム権限を許可してからTUNを有効にしてください。ifconfigでutunインターフェースを確認できますが、macOS本体や他のVPNも同種のインターフェースを作成します。インターフェースが存在するだけでは、現在のクライアントが作成したとは判断できません。

ifconfig
route -n get 1.1.1.1
scutil --dns

起動ログ、ルート情報、接続記録を照らし合わせて動作を判断してください。企業VPN、他のネットワーク拡張機能、ネットワークフィルターツールを使用している場合は、まず現在の状態を記録し、一度に一つの条件だけを変えて比較します。utunの番号だけで競合元を特定しないでください。

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

デスクトップGUIクライアントでは、サービス経由で権限を得られる場合があります。コマンドラインからmihomoを実行する場合は、インターフェースの作成やルートの設定に必要な権限が必要です。rootでサービスを実行する方法が一般的ですが、要件に応じてケーパビリティを設定することもできます。ただし、バイナリに権限を一つ追加するだけで、すべてのDNSやルーティング環境に対応できるわけではありません。

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

resolvectlはsystemd-resolvedを使用するシステムでのみ利用できます。コンテナではプロセス権限に加えて、TUNデバイスを公開し、必要なネットワーク権限を設定する必要があります。コンテナ内でenable: trueを指定するだけでは不十分です。リモートサーバーのルートを変更する前に、2つ目の管理用接続またはコンソールを確保してください。新しいルールによってSSHの戻り通信が変わると、接続できなくなるおそれがあります。

Android・iOS：OSのVPN接続機能を利用する

AndroidのClash系クライアントは通常、OSのVPN権限を使って端末の通信を取り込みます。デスクトップ版のサービスインストール手順は必要ありません。初回接続時にシステムのVPNダイアログで許可し、アプリ別プロキシの対象リストも確認してください。除外されたアプリは、ルールをグローバルに設定してもクライアントを経由しません。別のVPNアプリが接続中の場合、現在のVPN接続を確立できないこともあります。

Androidの「常時接続VPN」と「VPNを使わない接続をブロック」は、切断時の動作を変えます。ブロックを有効にすると、クライアントの終了後に端末が一時的にネットワークへ接続できなくなる場合があるため、復旧方法を事前に確認してください。iOSでは、対応クライアントがNetwork Extensionを使ってVPN構成を作成し、システムの案内に従って許可します。デスクトップ版mihomoのTUN設定を、すべてのiOSクライアントで使える共通設定として扱うことはできません。

5. スイッチだけでなく通信の取り込みを確認する

TUNをテストするときは、システムプロキシを一時的に無効にし、テストするターミナルのプロキシ環境変数も削除してください。明示的なプロキシ経由でリクエストが成功するのを避けられます。テスト後は元の設定に戻してください。以下のコマンドは今回のcurlリクエストでプロキシ設定を無視しますが、OSのルーティングによってTUNに送られることはあります。

curl --noproxy "*" --connect-timeout 10 -I https://example.com
  1. 接続記録を確認：コマンドを実行した後、クライアントの「接続」画面で接続先のドメイン名またはIPアドレスを探し、適用されたルールと実際の出力先を確認します。
  2. ルートの変化を確認：TUNを無効にした場合と有効にした場合のルートやポリシールートを比較し、別の仮想NICが誤って出口に選ばれていないか確認します。
  3. 実際のアプリでテスト：システムプロキシを使わないアプリを起動し、新しい接続を確認します。すでに確立されている長時間接続は、一度切断して再接続してください。
  4. UDPを個別にテスト：実際にUDP通信を行うアプリで確認します。HTTPリクエストが成功しても、ゲーム、音声通話、QUICが正常とは限りません。

接続記録にDIRECTと表示される場合、通信はすでにカーネルに入っていて、ルールによって直接接続が選ばれた可能性があります。これは取り込みの失敗を意味しません。逆に、ブラウザーでページを開けても該当するリクエストが接続記録にない場合は、ブラウザー拡張機能、内蔵プロキシ、キャッシュ、他のVPNの影響を先に確認してください。

6. よくあるトラブルを層ごとに切り分ける

症状優先して確認する項目次に行うこと
有効にするとすべての通信が切れる権限、出口インターフェース、DNS、ルーティングループTUNを無効にして通信を復旧し、起動ログを見ながら項目を一つずつ確認する
ドメイン名では失敗するが、一部のIPアドレスには接続できるDNSリスナー、DNS通信の取り込み、上流DNSへの到達性カーネルのDNSログを確認し、ブラウザーのセキュアDNS設定も調べる
Webページは開くが、ゲームや音声通話が使えないUDP対応、ルールの出力先、サーバー側の設定ノードがUDPに対応していることを確認し、該当する通信がカーネルに入っているか調べる
LAN内のデバイスへの接続に問題があるプライベートネットワーク向けルール、DNSマッピング、ルート除外実際のネットワーク帯に合わせて直接接続を設定し、取り込みを避ける必要がある場合はルート除外を設定する
一部のIPv6接続だけが不安定OSのIPv6ルートとカーネル設定IPv4とIPv6でテストを比較し、取り込みを回避していないか、出口が対応しているか確認する

直接接続ルールとルート除外は別の設定

たとえばIP-CIDR,192.168.0.0/16,DIRECT,no-resolveは、条件に一致した通信をカーネルに取り込んだ後、直接接続することを意味します。OSレベルでTUNを経由しないようにする設定ではありません。プリンターの検出、ブロードキャスト、マルチキャストが必要な場合は、アプリ側の検出方式とクライアントの対応状況も考慮してください。TCPの直接接続ルールを一つ追加するだけで完全に解決したと判断しないでください。

MTUを最初の調整項目にしない

一部のWebサイトだけ読み込みが止まる、大きなファイルの転送が中断する一方で、小さなリクエストは正常に動作する場合は、DNS、ノード、ルールの問題を除外したうえでパスMTUを確認します。現在の値が1500なら、元の値を記録してから一時的に1400を試し、結果を比較できます。この値は診断用の目安であり、すべてのネットワークに推奨される設定ではありません。改善がなければ元に戻してください。スタック、DNS、MTUを同時に変更すると、原因を特定できなくなります。

無効化後に設定を戻す手順

  1. まずクライアントでTUNを無効にし、インターフェースと自動ルートの削除が完了するまで待ちます。
  2. システムプロキシ、DNS、他のVPNの設定を元に戻し、テスト接続をやり直します。
  3. 通信が復旧しない場合は、残っているルートやDNS設定を確認します。まずクライアントまたはサービスを通常の手順で再起動してください。内容の分からないシステムルートを直接削除しないでください。

安定した設定では、次の3点を説明できる必要があります。どの通信が仮想NICに入るのか、DNSをどこで名前解決するのか、各接続が最終的にどのポリシーを使うのか。この3点をログと照合すると、グローバルモードを何度も切り替えたりノードを変更したりするより、問題を特定しやすくなります。システムプロキシに従わないアプリの通信も取り込む必要がある場合に限り、TUNに必要な権限やルーティング変更を導入してください。ブラウザーや明示的なプロキシで要件を満たせるなら、従来の接続方法をそのまま使えます。