システムプロキシとTUN：通信の入口が異なる

ブラウザーはネットにつながるのに、コマンドラインツールやゲームなどがClashの接続一覧に表示されない場合は、まず通信の入口を確認しましょう。システムプロキシは、たとえば 127.0.0.1:7890 のようなプロキシアドレスをアプリに知らせる仕組みです。アプリがその設定を使って初めて、リクエストがローカルプロキシへ送られます。直接接続するアプリや、環境変数だけを参照するアプリ、独自のネットワーク設定を使うプログラムは、システムプロキシを利用しないことがあります。

TUNはレイヤー3の仮想ネットワークデバイスです。OSはルーティングテーブルに従ってIPパケットを仮想NICへ送り、mihomoがパケットを読み取って接続を識別し、振り分けルールを適用します。アプリごとにHTTPプロキシやSOCKSプロキシへの対応を求めないため、通常は直接接続するアプリのTCP・UDP通信も取り込みやすくなります。

比較項目システムプロキシTUN仮想NIC
接続方式アプリがローカルのプロキシポートに接続システムのルーティングでIPパケットを転送
アプリ側の要件プロキシ設定の利用が必要一般的なIPアプリは個別設定不要
UDPHTTPシステムプロキシだけでは通常カバーできない取り込み可能。ただしノードとプロトコルの対応が必要
権限通常、ネットワークデバイスの作成は不要デスクトップでは通常、管理者権限またはバックグラウンドサービスが必要
トラブル時の確認項目プロキシアドレス、ポート、アプリの設定NIC、ルート、DNS、権限、振り分けルール

有効化前の確認：カーネル、サブスクリプション、権限

Clashはクライアントやカーネルを含むエコシステムの総称として使われますが、すべてのインストーラーが同じTUN設定に対応するわけではありません。この記事のYAML例はmihomo（一般にClash Metaカーネルと呼ばれるもの）を対象としています。旧版Clash、別のフォーク、モバイルアプリでは、項目名や設定方法が異なる場合があります。ソフトウェア名だけで互換性を判断しないでください。

  1. カーネルを確認する。クライアントの「バージョン情報」「カーネル情報」または実行ログでmihomoの表示を確認します。画面にTUNのスイッチがない場合は、まずクライアントの対応状況を調べましょう。不明な設定をむやみに追加するのは避けてください。
  2. サブスクリプションを先に確認する。システムプロキシで少なくとも1つのノードに接続できること、またポリシーグループで利用可能なノードが選ばれていることを確認します。TUNが解決するのは通信の入口の問題であり、無効なサブスクリプションやノードの認証エラーではありません。
  3. 現在の設定を記録する。システムプロキシのポート、現在のDNS、使用中のVPN、LANのサブネットを控えておきます。初回設定ではローカルで操作できる手段を残し、リモートSSH接続中にデフォルトルートを直接変更しないでください。
  4. システム権限を準備する。Windowsでは通常、サービスモードまたは管理者権限が必要です。macOSではクライアントの案内に従って特権ヘルパーをインストールします。Linuxでは /dev/net/tun へのアクセスとネットワーク管理権限が必要です。

まず、仮想NICを使用するほかのVPNを終了してからClash TUNを試してください。複数のクライアントが同時にデフォルトルートを追加したりDNSを変更したりすると、通信経路が切り替わり続けることがあります。併用が必要な場合は、単独での動作を確認してから、除外ルートと出口インターフェースを個別に設計してください。

gvisor・system・mixedネットワークスタック

tun.stack は仮想NICの通信を処理するネットワークスタックを指定する項目で、ノードのプロトコルを選ぶ設定ではありません。TrojanノードをVLESSノードに変更するものでもありません。mihomoでは一般に gvisor、system、mixed を指定できますが、対応状況は使用するカーネルのビルドによって異なります。

  • gvisor：ユーザー空間のネットワークスタックで接続を処理します。互換性を調べる際の比較対象として使えますが、すべてのOSでより安定するとは限りません。
  • system：OSのネットワークスタックで接続を処理します。性能や互換性はOS、ドライバー、ネットワーク環境によって異なり、すべての端末で高速とは限りません。
  • mixed：mihomoで2つの処理方式を組み合わせ、TCPにはsystem、UDPにはgvisorを使います。ネットワークスタックの組み合わせであり、HTTPとSOCKSの両方を受け付ける mixed-port とは関係ありません。

ネットワークスタックを切り替える判断基準

一度に変更するのは1項目だけにし、その都度カーネルを再起動して新しい接続でテストします。Webページは開けるのに通話やゲームが失敗する場合は、まずノードのUDP対応とルールの適用状況を確認し、その後でネットワークスタックを比較します。すべての接続がパネルに表示されない場合は、権限とルートを先に確認してください。この段階でgvisorとsystemを何度も切り替えても、根本原因の特定にはつながりません。

mihomoのTUN設定：ルーティングとDNSをまとめて構成

以下は既存の設定に追加する断片で、サブスクリプション全体ではありません。ノード、ポリシーグループ、振り分けルールは含まれていないため、動作する完全な設定の代わりにはなりません。すでにトップレベルに tun または dns がある場合は、キーの重複による上書きを避けるため、項目を統合してください。

config.yaml · TUN・DNS設定例
mixed-port: 7890
allow-lan: false
mode: rule

tun:
  enable: true
  stack: gvisor
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

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

例にある2つの上流DNSアドレスは設定例であり、すべてのネットワークに推奨するものではありません。利用環境から到達でき、用途に合ったDNSサービスを選んでください。サブスクリプションにDNSポリシーがすでに設定されている場合は、上流DNSとドメイン振り分けの設計を維持し、必要なTUN項目だけを追加するのがおすすめです。

auto-routeとauto-detect-interface

auto-route: true は、通信をTUNへ流すルートをカーネルが自動設定します。auto-detect-interface: true は実際の出口インターフェースを自動検出し、プロキシ接続を物理ネットワーク経由で送ることで、自身のTUNへ再び入り込むのを防ぐための設定です。複数NIC、仮想マシンのブリッジ、企業VPN、Wi-Fiと有線LANの併用環境では誤検出もあり得るため、ログも確認してください。

ルーティングテーブルに 0.0.0.0/0 があるかどうかだけで判断しないでください。プラットフォームによっては、より細かい分割ルートや別のルーティングテーブル、ポリシールーティングで通信を取り込みます。ルート検索の結果とクライアントの接続記録を合わせて、動作を確認しましょう。

dns-hijack、1053、fake-ip

dns-hijack は、条件に一致するDNS通信をmihomo内蔵DNSへ転送します。例の any:53 は一般的なUDP 53番ポートの問い合わせ向けです。TCP 53番ポートも処理する必要がある場合は、カーネルの対応を確認して tcp://any:53 を追加できます。すべての名前解決プロトコルを制御する設定ではなく、ブラウザーがHTTPSで送信するDoHリクエストを直接検出して横取りすることもできません。

127.0.0.1:1053 はDNSの待ち受けアドレスの例であり、システムDNSにポート番号付きの文字列を設定するという意味ではありません。多くのOSのDNS設定で指定できるのはIPアドレスのみです。TUNによる通信の取り込み、DNSの待ち受けポート、システムDNSの設定は、それぞれ別のものとして考えてください。

fake-ip はドメインに仮想IPアドレスを割り当て、カーネルがドメインと接続の対応関係を保持します。例のアドレスプール 198.18.0.1/16 はテスト用に予約された範囲です。この範囲のアドレスが返ってきても、DNSエラーとは限りません。実際の名前解決が必要なLANサービスには、すべてのドメインを除外するのではなく、適切な fake-ip-filter とDNS振り分けを設定してください。

Windows・macOS・LinuxでTUNを有効にする

クライアントによってメニュー名は異なるため、以下では機能ごとに手順を説明します。画面にTUN、ネットワークスタック、DNSの取り込み設定がある場合は、まずその機能を使ってください。クライアントによっては実行時に設定を再生成するため、生成ファイルを直接編集しても次回起動時に変更が失われることがあります。サブスクリプションの更新で手動設定が上書きされる場合もあるため、クライアントの永続化可能なオーバーライドやマージ機能を利用してください。

Windows：サービス権限と仮想NIC

  1. サブスクリプションを読み込み、システムプロキシで対象サービスに接続できることを確認してから、ほかのVPNを一時的に終了します。
  2. クライアント設定からサービスモードを開き、案内に従ってサービスをインストールして起動します。別の権限昇格方式を採用している場合は、クライアントの説明に従って管理者権限を付与してください。
  3. TUNを有効にし、カーネルが対応するネットワークスタックを選択して設定を適用します。ドライバーのインストールやネットワークデバイスの使用許可が表示されたら、現在使用しているクライアントからの確認であることを確かめてください。
  4. PowerShellを開き、新しい仮想NICとIPv4ルートを確認します。あわせてクライアントのログで、権限不足、デバイス作成失敗、ルート追加失敗などのエラーがないか調べてください。
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Format-Table DestinationPrefix,InterfaceAlias,NextHop,RouteMetric

NICの名前はクライアントと設定によって異なるため、必ずClashという名前になるとは限りません。NICが存在していても、アプリの通信がプロキシポリシーに適用されたことまでは確認できません。

macOS：ヘルパーとutunインターフェース

  1. 使用するクライアントとカーネルがTUNに対応していることを確認し、必要な特権ヘルパーをインストールします。
  2. クライアントでTUNまたは同等の仮想NIC機能を有効にし、システムの許可を求められたら案内に従って承認します。
  3. 以下のコマンドでインターフェース、ルート、システムDNSを確認し、有効化前の状態と比較します。
ifconfig
netstat -rn -f inet
scutil --dns

macOSでは複数の utun インターフェースが存在する場合があり、ほかのVPNやシステム機能も作成します。utunが見つかっただけでClashのものと判断したり、同種のインターフェースをすべて手動で削除したりしないでください。有効化・無効化の前後差、ルート、ログを照合して、どの機能に属するか確認します。

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

デスクトップクライアントでは通常、サービスプロセスが権限を昇格します。コマンドラインで実行する場合は、少なくともTUNの作成とルート管理に必要な権限が必要で、一般に CAP_NET_ADMIN が関係します。カーネル機能、サービスの制限、実行方法に応じて、ほかの権限も確認してください。任意のcapabilities一覧をそのまま適用するのは避けましょう。

test -c /dev/net/tun && echo "TUN device available"
ip link show
ip rule show
ip route show table all
resolvectl status

resolvectl はsystemd-resolvedを使うシステム向けです。コマンドが見つからなくても、TUNの障害とは限りません。コンテナで実行する場合は、ホスト側からTUNデバイスと必要なネットワーク権限を利用できるようにする必要があります。コンテナ内でrootに変更するだけでは不十分な場合があります。初回テストはローカルで行い、ルート変更によってリモート管理接続が切れないようにしてください。

Android・iOS：システムVPNの許可

Androidアプリは通常、システムVPNインターフェースを使って通信を取り込むため、デスクトップ向けのNICドライバー導入手順をそのまま適用する必要はありません。対応する設定を読み込んだら、VPNまたは仮想NICモードを選択し、初回接続時にシステムVPNの利用を許可します。アプリごとのプロキシ設定を有効にしている場合は、対象アプリが取り込み対象に含まれているか確認してください。対象外のアプリが、デスクトップ向け設定例で auto-route を有効にしただけで自動的に含まれることはありません。

iOSアプリは通常、システムのネットワーク拡張機能を利用します。まずアプリが対象の設定形式に対応していることを確認し、システムVPNの設定を追加して接続を許可してください。デスクトップ版mihomoのTUN設定項目がすべてiOS共通の設定になるわけではありません。また、Clashのサブスクリプションに対応するアプリがすべてmihomoカーネルを実行しているとは限りません。

モバイル端末では、通常、同種のVPNトンネルを2つ同時に有効にできません。接続直後に切断される場合は、ノードのプロトコルを何度も変更するのではなく、ほかのVPN、オンデマンド接続ルール、バックグラウンド動作の制限を確認してください。

通信の取り込みを確認：接続記録、DNS、UDP

システムプロキシによる誤判定を防ぐ

TUNは有効のまま、クライアントのシステムプロキシを一時的に無効にします。通常プロキシを設定していないアプリから新しいリクエストを送信し、接続パネルでプロセス、接続先、適用ルール、出力ポリシーを確認してください。以下のコマンドでcurlに明示的なプロキシを使わせない方法もあります。ただし、これはそのリクエストが明示プロキシを使わないことを確かめるだけで、TUNによる取り込みを単独で証明するものではありません。

curl --noproxy '*' -I https://example.com

ページにアクセスでき、接続記録にも該当リクエストが表示されたら、適用されたポリシーを確認します。DIRECTに一致するのは通常のルール判定であり、TUNの障害ではありません。ノード切り替え後も既存の長時間接続は以前の経路を使い続けることがあります。確認時は新しい接続を作成してください。

DNSとUDPを個別に確認する

  • DNS：システムの名前解決ツールでキャッシュされていないドメインを検索し、カーネルのログを確認します。ブラウザーでセキュアDNSが有効な場合、システムのUDP 53番ポートを経由しないことがあります。
  • UDP：実際に使う通話・ゲーム・QUICアプリで接続一覧を確認します。WebページがTCP 443で開けても、UDP 443が使えるとは限りません。
  • IPv6：デュアルスタック環境ではIPv4とIPv6を個別に確認します。IPv4だけを取り込む設定だと、一部のアプリがIPv6経由の別ルートを優先する場合があります。
  • LAN：ルーターの管理画面、プリンター、イントラネットのドメインにアクセスできるか確認します。直接接続が必要な宛先には明確なルールを設定し、特殊なネットワークではルートの除外も検討してください。

TUN有効化後にネットにつながらない場合：段階的な確認と復旧

症状まず確認する項目対処方法
仮想NICが作成されないサービス、許可、デバイスへのアクセス権限を修正してカーネルを再起動し、起動時の最初のエラーを確認する
NICはあるが接続一覧が空ルート、アプリごとの除外、IPv6実際のリクエストが取り込み経路に入っているか確認する
ドメインにアクセスできない上流DNS、通信の取り込み、キャッシュ名前解決サービスへの到達を確認し、次にfake-ipの設定を調べる
Webは見られるがゲームがつながらないノードのUDP対応と振り分け対象ルールを確認してからネットワークスタックを比較する
ネットワーク切り替え後につながらない出口インターフェースと古いルートTUNを再作成し、カーネルに出口を再検出させる
LAN内のデバイスに接続できないプライベートネットワークのルール、ルート競合、LAN内DNS直接接続と除外範囲を明示し、LAN内の名前解決を維持する

復旧する際は、まずクライアントでTUNを無効にし、クライアントを通常終了します。システムプロキシがまだ 127.0.0.1:7890 を指していないか確認してください。プロキシプロセスが停止した後もシステムプロキシが有効だと、ブラウザーで接続エラーが続くことがあります。これはTUNルートの残留とは別の問題です。

次に、記録しておいたDNS設定へ戻し、現在のネットワークをいったん切断して再接続します。それでもルートに問題がある場合は、バックグラウンドサービスが動作しているか確認し、必要に応じてシステムを再起動してネットワーク状態を復旧してください。用途の分からないルートやNICをまとめて削除しないでください。企業ネットワーク、仮想マシン、ほかのVPNが使用している可能性があります。

設定の構成を詳しく知りたい場合はClash設定ガイドをご覧ください。クライアントがまだ決まっていない場合は、クライアントの選び方ガイドで、OSとカーネルの対応状況を確認してください。