TUN モードで「何が」変わるか
TUN（ネットワークスタックにおける仮想インターフェース）は、Clash がオペレーティングシステムに対して「ここから出ていく IP パケットを、まず私に渡してほしい」と頼むための仕組みです。ブラウザが HTTP プロキシ設定を尊重するかどうかに依存しないため、システムプロキシ非対応のアプリや、独自にソケットを張るプロセスのトラフィックも、ルールに従って DIRECT または指定のプロキシへ振り分けやすくなります。いわゆる「端末まるごと」に近い粒度でトラフィックを扱うモード、と捉えると理解しやすいでしょう。
多くの現行クライアントでは、コアが mihomo（旧 Clash Meta）系である場合と、レガシーな Clash 系である場合で、TUN 周りのオプション名や既定値が若干異なります。本稿の説明は概念を優先しつつ、設定ファイルでは tun セクションや DNS モード（fake-ip / redir-host など）の存在を意識してください。用語の整理は ドキュメントページ も参照すると、設定項目と対応しやすくなります。
「透明プロキシ」と呼ばれる理由
利用者のアプリ側から見ると、接続先のホスト名やポートを書き換えずに通信できるため、従来の「プロキシサーバのホストとポートをアプリに明示する」方式と比べて透過的に見えます。OS のルーティングや仮想アダプタ経由でパケットがコアに入り、そこでルールマッチとプロキシ選択が行われる、という流れです。ただし「ユーザーが何も意識しない」という意味での完全な透明性ではなく、管理者権限・仮想 NIC の作成・ファイアウォールルールなど、環境側の許可が前提になる点には注意が必要です。
日本語の技術文脈では「透明プロキシ」「透過プロキシ」が混在しますが、ここではいずれも「アプリケーション設定を変えずにトラフィックを中継側へ引き込む」イメージで読み替えて問題ありません。Clash の文脈では、TUN と組み合わせた DNS の扱いが実質的な「見え方」を左右するため、次節以降で詳しく触れます。
システムプロキシとの違いと使い分け
システムプロキシは、OS が提供する HTTP/HTTPS（および環境によって SOCKS）のプロキシ設定に従うアプリに効果を発揮します。ブラウザや一部のデスクトップアプリはこれに追従しますが、プロキシを無視する実装や、ターミナル上のツール、ゲームクライアント、一部のストアアプリなどは設定だけではカバーできません。そこで TUN が「レイヤの手前でパケットを拾う」役割を担います。
運用上の目安としては、まずシステムプロキシでブラウザの挙動を確認し、必要なら TUN を有効化する、という順序が負荷と切り分けの両面で扱いやすいです。企業ネットワークや他社 VPN が常時接続されている環境では、デフォルトルートや DNS の奪い合いが起きやすいため、TUN をオンにした瞬間に通信が不安定になることもあります。その場合は一時的に他 VPN を切る、スプリットトンネリングを確認する、など競合の切り分けを先に行うとよいでしょう。
DNS・fake-ip とルールの連動
TUN を使うと、名前解決の経路もコアの設計に巻き込まれます。fake-ip モードでは、一時的な仮想 IP を返すことで、どの接続がどのドメイン由来かをコア側で追いやすくする、という狙いがあります。一方で、国内 CDN や銀行アプリなど、実 IP でないと挙動が変わるサービスでは、fake-ip-filter やドメイン除外のチューニングが必要になることがあります。redir-host 系のモードではトレードオフが異なるため、プロバイダが配布する推奨 DNS 設定や、自前のリスト更新頻度とセットで考えるのが安全です。
ルール側では DOMAIN、DOMAIN-SUFFIX、GEOIP などが順に評価されます。DNS がコア外で先に解決されてしまうと「意図せず DIRECT で実 IP に直行する」すなわち漏れに近い挙動が起きることがあるため、TUN 利用時はDNS もコアの管轄に収める、という設計思想がよく採られます。詳細なルール記法は ルール分流の解説記事 と併読すると、設定の全体像が掴みやすくなります。
プラットフォームごとの注意点
Windows では、TUN 用の仮想アダプタや WFP／フィルタドライバが絡むことがあり、他セキュリティ製品と競合すると接続が不安定になる例があります。管理者権限でクライアントを起動する必要が示される場合は、その旨に従ってください。macOS ではネットワーク拡張やプロファイルの許可が求められることがあり、初回のみシステム設定で許可が必要です。Linux では権限モデルや iptables / nftables と併用する構成もあり、ディストリビューションによって手順が異なります。いずれも「公式クライアントの案内に従い、カーネルやセキュリティソフトのログを確認する」が基本です。
設定ファイル上のイメージ（tun セクション）
実際のキー名はコアのバージョンとクライアントの変換レイヤに依存しますが、概念としては tun 以下で スタック（ユーザ空間とカーネルスタックの選択など）、自動ルート、インターフェース名、MTU などを指定し、グローバルな dns や profile と組み合わせます。GUI クライアントでは「TUN モードをオン」に相当するトグル一つで有効化できる一方、YAML を直接編集する場合はインデントや重複キーに注意してください。
変更後は必ず設定の検証（文法チェック）と、ブラウザだけでなく ping や特定アプリでの疎通確認を行うと安心です。期待どおりに振り分けられないときは、まず「TUN が本当に有効か」「DNS がどのサーバを見ているか」「ルールの先頭で意図せずマッチしていないか」を順に疑ってください。
よくあるトラブルと切り分け
有効にするとネット全体が不通になる
デフォルトゲートウェイのループや、DNS のみがループしているケースがあります。他 VPN の全トラフィック転送、企業プロキシ、セキュリティ製品の HTTPS インスペクションと重なると発生しやすいです。いったん TUN をオフにし、システムプロキシのみで最小構成に戻してから、競合を一つずつ外して再現条件を絞り込んでください。
名前は解決するが一部だけ繋がらない
fake-ip と実サービスの前提が食い違っている、あるいはルールで望まない経路に流れている可能性があります。該当ドメインをフィルタに追加する、ルールセットを更新する、プロバイダの告知を確認する、の順で調べるとよいでしょう。
遅延や CPU 負荷が高い
ルール数や Geo データの規模、暗号化プロキシの選択、そもそもの回線品質が要因になります。TUN 自体が必ずしも遅延の主因ではありませんが、不要なプロセスまでプロキシに流していないか、url-test グループのテスト間隔が短すぎないか、など運用面もあわせて見てください。
まとめ
Clash の TUN モードは、システムレベルでトラフィックをルールエンジンに引き込むための強力な手段であり、システムプロキシの補完として理解すると運用が安定します。透明プロキシに近い見え方を得られる一方、DNS 設計と権限・競合の管理がセットであることも忘れないでください。同種のツールをいくつか試したことがある方なら、挙動の予測しやすさとルール表現力のバランスにおいて、Clash エコシステムの価値を実感しやすいはずです。
クライアントの入手と各 OS 向けパッケージの案内は、配布元の情報とあわせて本サイトの ダウンロードページ から確認できます。オープンソースのライセンスやソースコードを知りたい場合は、リポジトリを別途参照し、実行ファイルの入手経路としてはサイトの導線を優先すると、説明とバージョンの対応が取りやすくなります。
Clash クライアントを無料でダウンロードする → 複数プラットフォーム向けのビルドを揃えており、画面の案内に沿えば短時間で初期設定まで進められます。