TUN モードとは何か
TUN モードとは、Clash のコア（多くの場合は Mihomo／旧称 Clash Meta）が、オペレーティングシステム上に仮想のネットワークインターフェース（NIC）を作成し、そこへ向かう／そこから出る IP パケット（TCP／UDP を含む）をユーザー空間で受け取り、設定したルールとプロキシグループに従って転送する仕組みです。ブラウザが参照する「システムの HTTP／SOCKS プロキシ設定」とは別物で、アプリがプロキシを意識していなくても、ルーティングテーブルとスタックの設計次第でトラフィックを Clash 側に流し込める点が大きな違いです。
ユーザーから見ると「グローバルに全部プロキシしたい」「とにかく漏れなく出口を揃えたい」という要望に応えやすい反面、権限（管理者／システム拡張）やDNS の扱い、他社 VPN とのルート競合など、システムプロキシより踏み込んだトラブルシューティングが必要になる場面もあります。ここでは、まず概念を押さえたうえで、実際の GUI クライアント（例：Clash Verge Rev）での操作イメージと、設定ファイル側で意識すべきポイントを整理します。関連記事は ブログ一覧 からも辿れます。
システムプロキシとの違い：なぜブラウザ以外で差が出るのか
多くのデスクトップ GUI は、初期状態で「システムプロキシをオン」にすると、OS のプロキシ設定（Windows の「インターネット プロパティ」や macOS のネットワーク詳細など）へ HTTP／HTTPS／SOCKS のエンドポイントを書き込みます。これはプロキシ対応アプリにとっては便利ですが、ゲームクライアント、独自プロトコルの更新プログラム、curl や git のように環境変数や独自設定に依存する CLI などは、システムプロキシをまったく見ないことが珍しくありません。
TUN を有効にすると、対象トラフィックはより下位のレイヤでコアに届くため、「アプリがプロキシ API を呼ぶかどうか」に依存しにくくなります。結果として、「とにかくすべての通信を同じルールセットで扱いたい」という意味でのグローバル制御に近づきます。ただし万能ではなく、カーネルドライバや他 VPN のフック順、IPv6 の経路、ローカルループバックの扱いなどによっては、まだ取りこぼしや競合が起き得ます。以下ではその切り分けも含めて説明します。
「グローバルプロキシ」と TUN の関係
初心者の方が陥りやすい誤解の一つに、「TUN をオンにしたら自動的にすべての通信が海外ノードに直行する」というイメージがあります。実際には、TUN は“通し方”であり、出口ノードの選び方は別レイヤです。Clash では rules によってドメインや IP のマッチ結果がどの proxy-groups に送られるかが決まり、GLOBAL グループを選ぶか、国内向けに DIRECT を選ぶかはルールとポリシー設計次第です。
つまり、TUN を使いながらも「国内は DIRECT、海外のみプロキシ」といったルール分流は可能です。逆に、システムプロキシだけでは取りこぼしていた UDP や特定ポートを、TUN 経由で同じルールに載せられるため、体感としての“グローバル性”が上がる、と捉えると正確です。分流の考え方自体は別記事で掘り下げられていますが、本記事の文脈では「TUN＝取り込み口」「GLOBAL／RULE など＝出口の選び方」と分けて覚えると混乱が減ります。
Windows での有効化：管理者権限と仮想アダプター
Windows では、TUN 用の仮想アダプター（多くの実装で Wintun 系ドライバ）を導入するために、インストール時や初回起動時に UAC（ユーザーアカウント制御）のダイアログが出るのが一般的です。クライアントを通常ユーザー権限のまま起動していると、ドライバの作成やルートの書き換えに失敗し、「TUN をオンにした瞬間に通信が途切れる」「そもそもスイッチが戻る」といった症状につながります。
- まず ダウンロードページ から入手したクライアントを、インストーラーの指示どおりセットアップします。
- 「管理者として実行」が推奨されるクライアントでは、ショートカットのプロパティから常時管理者で起動する設定を検討します（企業ポリシーで制限されている場合は例外申請が必要になることがあります）。
- 設定画面で TUN をオンにし、デバイス マネージャーに未知のネットワーク アダプターが追加されていないか、エラーアイコンが付いていないかを確認します。
- 既に別の VPN クライアントが常駐している場合は、一時的に終了してから再度 TUN を試し、競合の有無を切り分けます。
macOS での有効化：ヘルパーとプライバシー設定
macOS では、パケットフィルタやネットワーク拡張の周辺でシステム拡張やヘルパーツールの承認が求められることが多く、初回だけログインパスワードや「プライバシーとセキュリティ」画面での許可が必要です。特に macOS 15（Sequoia）以降は、VPN／プロキシまわりのガードが厳しくなっており、許可ダイアログを見逃すと TUN が静かに失敗するケースがあります。
操作の流れはクライアントによりますが、大枠は次のとおりです。アプリの「インストール／サービス」系メニューからヘルパーを入れ直す、システム設定で関連する拡張を有効化する、再起動後にもう一度 TUN をオンにする、の順で確認するとよいでしょう。Safari だけ通るが特定アプリが直結のまま、という場合でも、まずはTUN が本当にアクティブか（ステータス表示やログ）を確認してから Chrome 側の拡張機能やキャッシュを疑うと切り分けが早くなります。
DNS と fake-ip：取り込み口を理解する
TUN を使うと DNS クエリの扱いが重要になります。Clash 系の設定では dns ブロックで fake-ip モードを使う構成がよく見られ、ドメイン解決と接続確立のタイミングがシステムの従来挙動とズレることがあります。例えば、LAN 内ホスト名や社内ドメインを誤ってリモート DNS に送ってしまうと、社内サイトだけ開けないといった事象が起きます。
対策の方向性はシンプルで、fake-ip-filter や nameserver-policy などを使って「このドメインは常に実 IP を知りたい」「このサフィックスはローカル DNS へ」といった例外を明示することです。また、IPv6 が有効な環境では、IPv4 だけを丁寧にプロキシしても IPv6 がバイパスしてしまうことがあるため、IPv6 の経路とルールもセットで見る必要があります。細かいキー構文は公式ドキュメントや配布テンプレートと併せて調整してください。
DIRECT にすべきドメインが誤ってプロキシグループへ送られていないかを確認すると、原因が「ノード障害」ではなく「ルール／DNS」である場合に早く気づけます。
よくあるトラブルと切り分け
TUN をオンにすると一切つながらない
多くは権限不足かルーティングループです。Windows では管理者としての実行、macOS ではヘルパーとシステム拡張の許可を再確認してください。また、プロキシサーバ自体がダウンしている場合、すべてのフローをそこに送っていると全体が沈黙します。一時的に DIRECT 優先のプロファイルで起動できるかを試すと切り分けが容易です。
速度だけが極端に落ちる
暗号化プロトコル自体のオーバーヘッドに加え、不要なトラフィックまで遠回りしているケースがあります。国内 CDN まで海外ノードへ送っている、巨大な更新ファイルをプロキシで転送している、など。ルールで国内 IP 帯や更新ドメインを DIRECT に落とすと改善することがあります。
他社 VPN やセキュリティ製品と併用したい
同時に複数の「パケットを握る」製品を動かすと、どちらが先にフックするかで挙動が不安定になりがちです。原則としては一方だけを有効化し、必要なら順番を変える・片方を「プロキシチェーンの上流／下流」として整理する、といった設計が必要です。企業端末ではポリシー違反になることもあるため、社内規程の確認は欠かせません。
まとめ：TUN を選ぶべき典型的な場面
システムプロキシで十分なのは、ブラウザ中心で、かつすべてのアプリが OS のプロキシ設定を尊重している場合です。一方で、ゲーム・ボイスチャット・開発用 CLI・独自更新チャネルなど、プロキシ非対応が混在する環境では TUN の価値が高まります。加えて、UDP を含むセッションを一貫してルールに載せたい場合にも有利です。
とはいえ、TUN は強い権限とルーティングへの介入を伴うため、初めて使うときはバックアップしたプロファイルで試し、動作が安定したら本番に移すのが安全です。クライアントのビルドやコアの世代によって UI 表記は変わりますが、「仮想 NIC で握る」という思想は共通しています。導入の入口としては、まず ダウンロードページ で自分の OS に合ったパッケージを選び、画面のガイドに沿って TUN 用コンポーネントを入れ切るところから始めるのがおすすめです。他ツールと比べても、ルールベースの柔軟さとコミュニティ実績のバランスが取りやすいスタックになっています。