ClashのTUNモード設定方法｜仮想ネットワークインターフェースで全通信を取り込む仕組み

TUNとシステムプロキシ：通信を取り込む場所の違い

ブラウザーでは接続できるのに、ターミナルやゲーム、特定のデスクトップアプリではつながらない場合、アプリがシステムプロキシを参照していないことがあります。システムプロキシは、対応アプリにHTTPまたはSOCKSの接続先を指定する仕組みです。アプリが独自に接続したり、プロキシ設定を無視したり、設定対象外のUDP通信を使ったりする場合、システムプロキシを有効にするだけでは不十分です。

TUNはシステムにレイヤー3の仮想ネットワークインターフェースを作成し、ルーティングによって条件に合うIPパケットをコアへ転送します。mihomoは受け取ったデータを宛先アドレスやドメイン情報、ルールに基づいて判定し、直接接続するかプロキシ経由にするかを決めます。そのため、通常はアプリごとにプロキシアドレスを設定する必要はありませんが、コアにはインターフェースの作成とルート変更の権限が必要です。

比較項目	システムプロキシ	TUNモード
通信の取り込み口	アプリがプロキシプロトコルで待ち受けポートに接続	システムのルーティングでIPパケットを仮想インターフェースへ転送
アプリ側の対応	アプリの対応または手動設定が必要	通常、アプリがプロキシ設定を認識する必要はない
権限	通常、ネットワークインターフェースの作成権限は不要	デスクトップでは通常、管理者権限、root権限、または権限付きサービスが必要
UDP	アプリとプロキシの接続先による	取り込みは可能。ただし、プロキシノードとプロトコルの対応も必要
適用範囲の制約	プロキシを使用しない接続は迂回する可能性がある	ルーティング、除外設定、IPv6、他のVPNの影響を受ける

有効化する前に：コア、ノード、復旧手段を確認

「Clashクライアント」はインターフェースの呼称であり、搭載コアがすべて同じとは限りません。この記事のYAML設定はmihomo向けです。オリジナル版Clashや古いPremiumコアの共通設定として、そのまま使わないでください。まずクライアントの「バージョン情報」や「コア情報」で実際のコアを確認します。単体で実行している場合は、バージョン表示で確認できます。

mihomo -v
mihomo -t -f config.yaml

2つ目のコマンドは、現在のコアで設定を解析できるか確認するものです。ノードの利用可否やルーティングの正しさを証明するものではありません。コマンドでプログラムが見つからない場合は、実際の実行ファイルのパスを指定してください。Windows PowerShellでは、カレントディレクトリのプログラムは通常 .\mihomo.exe と記述します。

現在動作している設定とオーバーライドファイルを保存してください。サブスクリプションの更新で直接編集した内容が上書きされることがあるため、クライアントにマージ機能やオーバーライド機能があれば、そちらを使いましょう。
まずシステムプロキシモードでノードが使えることを確認します。少なくとも一度はWebページへのアクセスをテストしてください。ゲームや音声通話、QUICが必要な場合は、ノードがUDPに対応していることも確認します。
ほかのVPN、通信高速化ツール、古いプロキシコアを一時停止します。最初のテストでは、複数のツールに同時にデフォルトルートを変更させないでください。
TUNを無効にする手順を確認しておきます。リモートサーバーを管理している場合は、ルート変更で唯一のSSH接続が切れないよう、コンソールなど別の復旧手段を事前に用意してください。

mihomo TUNの基本設定と各項目の意味

以下は、動作確認済みの設定に追加するトップレベルの設定例です。ノードやプロキシグループを含む完全なサブスクリプションではありません。既存の tun または dns セクションがある場合は項目を統合し、同じトップレベルキーを重複して追加しないでください。初回の確認ではIPv4のみを対象にし、接続を確認してからIPv6を個別にテストします。

mode: rule
log-level: info
ipv6: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - 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

ここに記載した2つのDNSアドレスは、一般的なDNS上流の書き方を示す例です。利用するネットワークから到達できるアドレスに調整してください。通常のDNSクエリは暗号化されません。DNSの振り分けやノードのドメイン解決をすでに適切に設定している場合は、既存の設計を維持し、この入門用設定で丸ごと置き換えないでください。

項目	役割と確認ポイント
`enable`	TUNの起動を要求します。起動できるかどうかは、権限やインターフェース、ログも確認してください。
`auto-route`	TUNへ通信を送るルートを自動設定します。すべての除外経路がなくなるわけではありません。
`auto-detect-interface`	実際の送信インターフェースを自動判別します。複数のネットワークインターフェースや他のVPNがある場合は、判別結果を確認してください。
`dns-hijack`	TUNに入る宛先ポート53のUDP DNSを捕捉する例です。暗号化DNSをすべて捕捉する設定ではありません。
`listen`	ローカルDNSの待ち受けアドレスです。1053はポートの例であり、システムDNSに設定するポートではありません。
`fake-ip-range`	ドメインのマッピングに使うアドレスを割り当てます。アプリがこれらのアドレスを取得しても、通信は引き続きコアを経由する必要があります。

198.18.0.1/16のアドレス範囲はベンチマーク用です。接続先Webサイトの実際のIPアドレスでも、一般的なパブリックIPのノードアドレスでもありません。アプリにFake-IPがキャッシュされていると、コアを停止した後もそのアドレスを使い続け、一時的に接続できなくなることがあります。関連アプリを終了し、DNSキャッシュを消去してから再試行してください。

stackの選び方：system、gvisor、mixed

system：主にシステムのネットワークスタックで接続を処理します。まずはクライアントの推奨値で試す方法が適していますが、実際の動作はOSやネットワーク環境によって異なります。
gvisor：ユーザー空間のネットワークスタックを使用します。特定のアプリで互換性の問題がある場合に比較用として試せますが、速度や安定性が必ず向上するわけではありません。
mixed：TCPはsystem、UDPはgVisorの経路で処理します。これは処理方式を組み合わせるもので、プロキシ設定を2つ同時に実行するものではありません。

stackの対応状況や制限は、プラットフォームやコアのバージョンによって異なります。変更後は設定を検証してから起動ログを確認してください。stack、DNS上流、ノードを一度に変更すると、接続が復旧してもどの変更が効いたのか判断しにくくなります。

Windows：まずコアにネットワークインターフェースの作成権限を与える

ほかのプロキシクライアントを終了し、現在のノードが通常のシステムプロキシ経由で使えることを確認します。
クライアントにサービスモードがある場合は、画面の案内に従ってサービスをインストールし、起動してください。サービスモードがない場合は、プログラムの入手元を信頼できることを確認したうえで、管理者としてクライアントを起動し、一度テストします。
クライアントのTUN設定で仮想ネットワークインターフェースによる通信の取り込みを有効にし、インターフェースやルートの作成成功、または具体的なエラーがログに記録されているか確認します。クライアントによってメニュー名は異なるため、スイッチの色だけで成功と判断しないでください。
Win + Rを押して ncpa.cpl を実行し、ネットワークアダプターを確認します。インターフェース名はクライアントや設定によって決まり、必ずしもClashという名前ではありません。

動作確認では、ブラウザーがシステムプロキシ経由で接続してTUNの問題を隠さないよう、クライアントのシステムプロキシをオフにしてTUNだけを有効にします。Windows 11の「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシの状態を確認できます。組織管理のデバイスでは、管理ポリシーを無断で変更しないでください。

route print
ipconfig /all
curl.exe --noproxy "*" -I https://example.com

route printでルートを確認できますが、TUNを指す従来型のデフォルトルートが必ず表示されるとは限りません。より具体的なネットワーク範囲を使って通信を取り込む実装もあります。テスト中はクライアントの接続一覧も確認し、対象の通信がコアに入り、想定したルールに一致しているかを確認してください。HTTPレスポンスが返っただけでは、宛先に到達できたことしか分からず、プロキシノードを経由した証明にはなりません。

macOSとLinux：権限、ルート、DNSを確認

macOSでの有効化手順

mihomo TUNに対応したクライアントを使い、画面の案内に従って補助サービスをインストールまたは許可します。通常のユーザープロセスだけでは、必要なネットワーク設定をすべて行えない場合があります。
TUNを有効にしたらログを確認し、ターミナルで ifconfig と netstat -rn を実行します。システムに複数の utun インターフェースが存在することがあるため、utunが見つかっただけでは現在のクライアントのものとは限りません。
「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」を開き、古い手動プロキシ設定が残っていないか確認します。メニュー名や場所はOSのバージョンによって異なります。
システムプロキシをオフにし、明示的なプロキシ設定のないアプリから新しい接続を試します。コアの接続一覧でも照合してください。

Webページは表示できるのにLAN内のデバイスへアクセスできない場合は、LAN向け通信に適用されるルールとルートを確認してから、除外するネットワーク範囲の調整が必要か判断します。LAN全体へのプロキシ接続失敗を、DNS障害と決めつけないでください。

Linuxでの有効化手順

Linuxでは通常、root権限または同等のネットワーク管理権限が必要で、システムにTUNデバイスが用意されている必要があります。まず /dev/net/tun が存在するか確認してください。コンテナや軽量システムではデバイスへのアクセスが制限されることがあり、rootで実行していてもインターフェースを作成できるとは限りません。

ls -l /dev/net/tun
mihomo -t -f config.yaml
sudo mihomo -f config.yaml

# 別のターミナルで確認
ip link
ip rule
ip route show table all
resolvectl status

最初に失敗する手順を確認しやすいため、初回はフォアグラウンドで起動してください。常時稼働させる場合は、管理されたサービス設定を使います。トラブルシューティングのために、ディレクトリ内のすべてのプログラムへ一括で権限を付与しないでください。resolvectlが使えるのはsystemd-resolvedを利用するシステムです。ほかのディストリビューションでは、実際に使われているDNS管理方式を確認してください。

AndroidとiOS：システムのVPN権限を使用

Androidクライアントは通常、システムのVPNインターフェースを使って通信を取り込みます。初回接続時にVPNの使用を許可し、クライアントのアプリ除外設定やアプリごとのプロキシ設定も確認してください。除外されたアプリは、TUNを有効にしても自動的にルール処理へ入りません。Androidの「設定」→「ネットワークとインターネット」→「VPN」で現在の接続を確認できます。メーカー独自のOSでは「接続と共有」などにある場合もあります。

Androidでは通常、同じユーザーまたはプロファイルで同時に動作できるVPNサービスは1つです。ローカルファイアウォール、広告ブロックツール、ほかのVPNが同じ接続を取り合う場合があります。「常時接続VPN」や「VPN未接続時に通信をブロック」を設定している場合は、クライアントを終了したときの通信への影響を確認してください。AndroidのプライベートDNSは暗号化通信を使うため、ポート53のハイジャックルールで処理されるとは限りません。

iOSでは、対応する設定を利用できるクライアントを使い、システムのVPN権限を許可してトンネルを確立します。「設定」→「一般」→「VPNとデバイス管理」で状態を確認してください。iOSクライアントはmihomoを使用するとは限らず、上記のYAML項目に対応しているとも限りません。アプリ固有の設定形式に従い、デスクトップ用の設定をそのまま読み込める共通手順と考えないでください。

DNS、IPv6、UDP：見落としやすい3つの確認点

ポート53のハイジャックではDoHやDoTを処理できない

例の any:53 は通常のUDP DNSを処理します。DNS over TLSは通常TCP 853、DNS over HTTPSは通常HTTPSの443番ポートを使うため、この設定だけで自動的にコアのDNSクエリへ切り替わるわけではありません。トラブルシューティング時は、ブラウザーのセキュアDNSを一時的に無効にして比較し、確認後に最終的な名前解決方法を決めてください。

テストでは「ドメイン名を解決できるか」と「通信がコアに入っているか」を別々に確認します。たとえば nslookup example.com で名前解決の結果を確認できますが、ブラウザーも同じ経路で名前解決しているとは限りません。ドメインルールが一致するかどうかは、コアがその接続に対応するドメイン情報を取得できるかにも左右されます。

AAAA応答を無効にしても、システムのIPv6が無効になるわけではない

例のIPv6設定は初回の診断を簡単にするためのもので、システム全体で通信の迂回を防ぐ保証ではありません。アプリがキャッシュ済みのIPv6アドレスやIPアドレスの直接指定、別のリゾルバーを使う可能性があります。IPv6を使う場合は、コアのIPv6設定、TUNルート、DNS応答、ノードの対応状況をあわせて確認してください。使わない場合も、システムに未対応のIPv6経路が残っていないか確認します。

UDPを取り込めても、利用可能な送信先が必要

通話やゲームで問題が起きたら、まず接続一覧に対象のUDPセッションが表示されるか確認し、ルールで選ばれたノードがUDPに対応しているか調べます。ブラウザーのQUICもUDPを使用します。TCPにフォールバックしてWebページが開けても、UDP経路が正常とは限りません。Webの速度測定だけで判断せず、ゲームや通話アプリ自体でも確認してください。

よくあるトラブル：権限、ルート、DNS、送信先の順に確認

症状	まず確認する項目	次の手順
有効にしてすぐ無効になる	設定の解析エラー、サービス未起動、権限不足	設定を検証し、最初に記録されたインターフェース作成エラーを確認します。
有効にするとすべての通信が切れる	送信インターフェースの誤選択、他のVPNとの競合、ノードに到達できない	TUNを無効にして通信を復旧し、通信を取り込むツールを1つだけにします。
IPアドレスには接続できるが、ドメイン名では失敗する	DNS上流に到達できない、待ち受けポートの競合、DNS経路が取り込まれていない	1053番ポートの待ち受けとDNSログを確認します。最初からすべてのルールを変更しないでください。
Webは使えるがゲームに接続できない	UDPの送信経路、ルールのポリシー、アプリの除外設定	UDPセッションと実際に選択されたノードを確認します。
Wi-Fiを切り替えると接続できなくなる	ネットワークの切り替え後、送信インターフェースやルートが更新されていない	TUNセッションを再起動し、物理ネットワークインターフェースが再判別されているか確認します。
無効にした後もインターネットにつながらない	システムプロキシやルート、Fake-IPのキャッシュが残っている	まずクライアントを終了し、プロキシ設定とルートを確認してからキャッシュを消去します。

MTUが原因と考えられる場合に限り、個別に調整してください。小さなリクエストは通るのに、大きなレスポンスや特定のサイトで停止するのが典型ですが、ノードや回線に問題がある可能性もあります。現在の値を記録してから mtu: 1400 を比較用に試せます。この値は診断の出発点であり、すべての固定回線、モバイル回線、VPN併用環境に最適とは限りません。

DNSキャッシュが原因と確認できた場合、Windowsでは ipconfig /flushdns、systemd-resolvedを使うLinuxでは sudo resolvectl flush-caches を実行します。キャッシュの消去では、誤ったルートの復旧やノードの障害には対処できません。調査後は一時的なデバッグログを info に戻してください。ログを共有する前に、サブスクリプションURLやトークンなどの機密情報を削除します。

完了の目安：1つの接続で一連の動作を確認

システムプロキシとアプリ内の明示的なプロキシ設定を無効にし、新しい接続を開始します。
コアで該当する接続を見つけ、宛先、TCPまたはUDPの種別、一致したルール、送信ポリシーを確認します。
直接接続されるはずの宛先と、プロキシ経由になるはずの宛先をそれぞれテストします。1つのWebページだけで判断しないでください。
LANへのアクセス、ネットワーク切り替え、TUN無効化後の復旧を確認します。

この4項目を確認できれば、通信の取り込み、ルール、送信経路が基本的に動作していると判断できます。その後、IPv6やアプリの除外、詳細なルート設定を追加する場合は、一度に1項目だけ変更し、元に戻せるよう記録を残してください。各項目の詳しい説明は設定ガイドのTUN設定とDNS設定をご覧ください。