Clash TUNモードをWindows 11とmacOSで有効にする：システムプロキシとの違いと接続不通のトラブルシュート

TUN が「変えるもの」：ユーザ空間プロキシから、OSのルーティングへ

多くの Clash 系 GUI は、既定で HTTP／SOCKS のローカルリスナ を立て、あわせて OS の システムプロキシ をそのポートに向けます。ブラウザのほとんどはこれに従いますが、次のようなプロセスは システムプロキシ設定を読まない ことがあります。第一に、独自のネットワークスタックを持つゲームクライアント。第二に、環境変数 HTTP_PROXY を見ない古い CLI ツール。第三に、管理者権限やサンドボックスにより、ユーザレベルのプロキシ設定から隔離されたサービスです。

TUN モード は、OS に 仮想ネットワークアダプタ（仮想NIC） を追加し、既定ルートや DNS の取り扱いを Clash 側のポリシーに寄せることで、「プロキシを知らないアプリ」もトラフィックの入口で捕捉 しやすくします。言い換えると、捕捉の責務が「各アプリがプロキシを尊重するか」から「OS がパケットをどこへ送るか」へ移ります。その分、設定ミスや権限不足があると マシン全体が一瞬でオフライン に見える副作用もあります。だからこそ、オンにする前に「システムプロキシで十分なのか／TUN が必要なのか」を押さえておく価値があります。

対照表：TUN とシステムプロキシ（＋手動プロキシ指定）

以下は実務で迷いやすい点だけを抜き出した対照です。クライアント名は製品版リネームの影響を受けるため、画面では TUN／Virtual Adapter／Enhance Mode／システムプロキシ などの語を手がかりにしてください。

Windows 11 での有効化：管理者権限、サービス、WFP／スタックの確認

Windows では TUN 実装が カーネル側のパケット処理（WFP 等） に触れるため、管理者として起動 できないクライアントではトグルがグレーアウトしていたり、オンにしてもすぐ無効に戻ることがあります。まず Clash 本体を 管理者権限で実行 できるか確認し、SmartScreen や企業ポリシーでブロックされていないかを見ます。

続いて GUI の TUN／仮想アダプタ をオンにします。項目名は派生版ごとに異なりますが、多くの場合 スタック（gVisor／system など）や 自動ルート、厳密ルート（strict route） のチェックが並びます。初期導入では、クライアントのドキュメントが推奨する既定スタックから外さないのが安全です。オンにした直後、ネットワークとインターネット → 高度なネットワーク設定 → ネットワークアダプタのオプション を開き、Clash が作成した 仮想イーサネット が「有効」になっているかをざっと確認すると、ドライバ未適用の切り分けが早くなります。

まったく通信できなくなった場合は、まず TUN をオフに戻し、システムプロキシのみ でブラウザが復帰するかを見ます。復帰するなら原因は TUN 周辺に集中します。Windows ファイアウォール が Clash の実行ファイルをブロックしていないか、他社 VPN やフィルタ製品が同じレイヤを占有していないかも、よくある衝突ポイントです。競合する VPN を一時停止して再試行するのは有効な切り分けです。

macOS での有効化：管理者パスワード、ネットワーク拡張、プロファイル

macOS では TUN 相当の機能が Network Extension や システム拡張 として提供されることが多く、初回オン時に 管理者パスワード と セキュリティ設定の許可 を求められます。システム設定 → プライバシーとセキュリティ にバナーが出ていないか確認し、ブロックされていれば許可してからクライアントを再起動します。Apple Silicon と Intel でドライバパスが異なるため、古い手順記事をそのまま踏襲せず、利用中のクライアントの公式ドキュメントを優先してください。

仮想インタフェースが作成されると、ネットワーク設定 に新しいサービスが現れます。ここが「オフ」のままや、優先度の競合で変なルートが残ると、ブラウザだけ不通というより 名前解決から詰まる パターンが出やすいです。トラブル時は TUN をオフにしたうえで、不要な古い VPN プロファイルを削除し、DNS サーバ が意図せず固定されていないかを確認します。

macOS の ローカルホストや *.local を開発用に使う場合、TUN 有効化で取り込みすぎないよう、クライアントの 除外ルート／bypass と YAML 側の DIRECT ルールの両面を意識します。ルールの書き方は YAML 分流ガイド の DIRECT や IP-CIDR の節を参照してください。

仮想NICと DNS：fake-ip・redir-host・リークの見え方

TUN を使うと、DNS クエリの扱いがシステムプロキシ時よりも Clash の DNS セクションに依存 しやすくなります。fake-ip を有効にしている構成では、見かけ上の IP がクライアント内で生成され、アプリやキャプチャツールからは「妙なアドレスに繋いでいる」ように見えることがあります。これは攻撃ではなく仕様側の挙動ですが、誤って キャプチャ除外 や ルールの順序 をいじると、名前は解けるのに接続だけ失敗するなどの不整合が出ます。

切り分けの基本は、クライアントのログで DNS と connection の行を分けて読むことです。DNS がタイムアウトなら upstream の DoH／DoT、ネットワークのブロック、企業フィルタを疑います。DNS は成功しているのに TCP が失敗するなら、ノードやプロトコル、あるいは UDP が遮断 されている可能性が上がります。購読自体の取得不安定さは別問題なので、購読自動更新のチェックリスト と混同しないようにしてください。

「TUN をオンにしたら丸ごと断」：よくある原因を順に潰す

次の順で見ると手戻りが少ないです。第一に、選択中のプロファイル／ポリシー が実際に出口に到達できるか。ノードがすべて赤いまま TUN だけ有効にしても、ルートを吸い上げた結果として全体が沈黙します。第二に、strict route や auto-route 系オプションが、自宅ルータのサブネットまで巻き込んでいないか。第三に、IPv6 が有効な回線で、IPv6 だけが規制外に出て挙動が不整合になっていないか。第四に、キルスイッチ的な挙動 をするクライアント設定で、意図せず「プロキシ不通時は完全遮断」になっていないかです。

Windows と macOS の両方で共通するのは、他 VPN との二重フック です。別 VPN が既にデフォルトルートを握っている状態で Clash TUN を重ねると、どちらも半分だけ効いて不安定になります。試験時は一方だけに限定してください。また、セキュリティスイートの HTTPS スキャン がローカルプロキシと競合し、証明書警告や接続リセットを誘発することもあります。症状がブラウザに偏るときはその線も疑います。

それでも戻らないときは、落ち着いて TUN オフ → クライアント終了 → 仮想アダプタの残骸確認 → 再起動 の順が安全です。設定ファイル側で tun ブロックを一時コメントアウトできるなら、GUI より再現性のある切り分けができます。YAML の編集全般に不安があれば、まずは GUI のトグルとログに絞って原因を特定し、安定後に ルールと DNS の整理 へ進むと負荷が少ないです。

「一部のソフトだけ直結」が残るとき：プロセス単位、bypass、管理者権限

TUN でも取りこぼす代表例があります。第一に、カーネル近傍で動く独自ドライバを持つ通信。第二に、プロキシ無効がバイナリ埋め込み の更新プログラム。第三に、別ユーザコンテキスト で動くサービスで、仮想アダプタの名前空間に乗らないケースです。対策は、クライアントが提供する プロセス／ドメイン別の bypass 一覧 を確認し、必要なら YAML で明示的に DIRECT か特定ポリシーへ割り当てます。

また、ブラウザ拡張の 独自 VPN が内部で別経路を張っていると、OS ルートをすり抜けて見えることがあります。拡張をオフにして挙動が揃うかを試してください。ターミナル系は curl の --proxy や、シェルに export した変数が優先されるため、環境変数の残りも確認します。

設定ファイル側の最低限：tun ブロックと競合しやすい項目

実装によりキー名は異なりますが、多くの Meta 系は tun: 以下に enable、stack、auto-route、strict-route、dns-hijack などが並びます。GUI のトグルは最終的にここへ反映されます。手編集する場合は、インデントと重複キー に注意してください。YAML の一般的な落とし穴は 分流ガイド の説明と共通です。

enhanced-mode や古いドキュメントの用語が、現行クライアントでは TUN 設定へ統合されている場合もあります。見つからないときは「設定画面の語彙」と「実ファイルの tun:」を突き合わせ、意味が一致しているかを確認してください。

まとめ

Clash の TUN モード は、Windows 11 や macOS のデスクトップで、システムプロキシを読まないアプリ まで含めてトラフィックを束ねたいときの強力な手段です。その代わり、仮想NIC・権限／ドライバ・DNS（fake-ip 含む）・他 VPN との競合 といったレイヤが一気に表に出ます。操作としては、まず システムプロキシで足りる範囲 を切り出し、必要なら TUN を 管理者権限と公式手順 で有効化し、断が出たら TUN オフでの復帰確認 → DNS／ルート／競合製品 の順に潰すと安全です。

コアやクライアントの世代が古いと、TUN スタックや DNS 実装の差で「記事どおりのトグルが無い」こともあります。長期利用なら Meta コアの更新 を前提に、画面と設定ファイルをあわせて読み解くのがおすすめです。実行ファイルの入手や各 OS 向けパッケージの比較は、ダウンロードページ でまとめて確認できます。

関連：YAML ルール分流、開発者向け分流、技術コラム一覧。