macOS で TUN がシステム拡張とセットになる理由

Linux のようにカーネルモジュールをユーザーが自由に差し込めるわけではなく、macOS では仮想ネットワークインターフェースやパケット処理の多くが Network Extension などユーザ空間の拡張として配布・署名されます。Clash 系クライアントが TUN モードを有効にするとき、単にアプリ内のトグルを ON にするだけで終わらず、システムに拡張機能の読み込み許可が必要になるのはこのためです。Gatekeeper や公証と別軸で、「誰がネットワークスタックに介入するか」をユーザーが明示的に承認する設計になっています。

その結果、初回は「拡張がブロックされた」「再起動が必要」といったメッセージが出て、システム設定側の操作がセットになります。ここを飛ばすと TUN インターフェースが立ち上がらず、ルールやノード以前にそもそもトラフィックが掴めない状態が続きます。Linux 向けの手順（Ubuntu での TUN と systemd）とは前提が異なる点を押さえておくと、同じ「TUN が効かない」でも切り分けが速くなります。

概念の整理は TUN モードの詳解 と併読すると、ルール・DNS・fake-ip の話と接続できます。

ℹ 先に決めること：TUN を主経路にするなら、ブラウザや OS の「システムプロキシを Clash が書き換える」機能と役割が重ならないよう設計します。後述の「二重化」が、体感では「謎の遅延」「一部だけ直結」の典型原因です。

「システム拡張がブロックされた」ときの承認手順

代表的な流れは次のとおりです。（表示文言は macOS のバージョンやクライアントの梱包形態で多少異なります。）

  1. クライアントが TUN を初めて要求した直後、画面上にセキュリティでブロックされた旨の通知が出る。
  2. システム設定 → プライバシーとセキュリティ（旧バージョンでは「セキュリティとプライバシー」）を開き、画面下部付近のシステム拡張または開発者ツールまわりに、該当ベンダ名・説明文とともに許可ボタンが表示される。
  3. 指示どおり再起動またはログアウト／ログインを行い、再度クライアントで TUN を有効化する。

許可ボタンが見当たらないときは、一度クライアントを終了し、拡張を要求し直すと表示が出ることがあります。複数の VPN やフィルタ製品を入れていると、別の拡張の承認待ちと混線することもあるため、一覧に残る項目を上から順に整理します。

企業管理下の Mac では MDM プロファイルで拡張の許可が制限されている場合があります。その場合は個人設定だけでは解決せず、管理者ポリシーの確認が必要です。

システムプロキシと TUN：二重化が起きるパターン

システムプロキシは、HTTP/HTTPS/SOCKS の宛先を OS の設定（および一部クライアントがそれを書き換える動作）としてアプリに伝える方式です。多くのブラウザや対応アプリはこれに従います。一方 TUN は仮想インターフェースとルーティング／ポリシールーティングを通じて、より広い範囲のトラフィックをコア側へ誘導する発想です。

問題は、クライアント設定で「システムプロキシを自動設定する」を ON にしたまま TUN も ON にし、さらにルールや DNS が二系統で競合するケースです。見た目は「プロキシも有効、TUN も有効」ですが、実際には同じフローを二重に触っている、あるいは一方が期待と違う宛先へ書き換えていることがあります。症状としては、ブラウザだけ異常に遅い、ターミナルだけ直結する、といったアプリごとの差が出やすいです。

実務的には、TUN を主に使うならシステムプロキシの自動設定をオフにする、またはクライアントの「システムプロキシへ反映」をオフにして TUN のみに寄せる、のどちらかに寄せ切るのが安定しやすいです。どちらを残すかは、社内プロキシ必須のブラウザだけ例外にしたい等の要件次第です。クライアントの選定と UI の持ち方は クライアントの選び方 も参照してください。

config.yaml の TUN 断片（参考）

実際のキー名はコアのバージョンによります。下記はイメージです。GUI クライアントが設定を上書きする場合は、ファイルを直編集しても画面のトグルと矛盾しないよう注意してください。

YAML fragment (adjust for your core version)

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

auto-route は他の VPN や仮想化ソフトとルートを奪い合うことがあります。複数を常時併用する場合は、起動順や「どちらがデフォルトルートを握るか」を意識します。DNS 周りは FAQ の DNS／接続性の説明と合わせて読むと、TUN 単体では説明しきれない「名前は解けるが繋がらない」を減らせます。

一部アプリだけプロキシを通らないとき

TUN が有効でもすべてが必ず同じ経路になるわけではありません。サンドボックスされたアプリ、独自のネットワークスタックを持つソフト、証明書ピン留めや固定エンドポイントへ直に出る更新チャネルなどが典型です。また、Split Tunnel 型の別 VPN と併用していると、宛先プレフィックスによってはそちら側のルートが優先されます。

切り分けは「そのアプリの接続が、Clash のライブ接続一覧に現れるか」から始めるのが早いです。現れないなら、TUN 以前にそのプロセスのトラフィックが仮想インターフェースに乗っていない可能性が高いです。現れるのに期待したポリシーに乗らないなら、ルール順・MATCH・GEOIP の行が先に当たっていないかを疑います。ルール全般の整理は ルール分流のベストプラクティス を参照してください。

観測とログで順に切り分ける

ターミナルで scutil --proxy を実行し、HTTP/HTTPS/SOCKS に値が入っているかを確認すると、システムプロキシが生きているかのスナップショットが取れます。TUN 一本に寄せる方針なら、ここが空に近い／期待と一致しているかを見ます。併せて Clash 側のログで、TUN 起動エラー・権限・ルート追加失敗が出ていないかを確認します。接続段階の読み方は timeout と TLS のログ解説 も活用できます。

変更は一度に一つずつ。TUN ON／システムプロキシ OFF／DNS モード固定、のように差分を分けて試すと、総入れ替えより早く原因に辿り着きます。

⚠ コンプライアンス：職場・学校・公共ネットワークではプロキシやトンネル利用が禁止されていることがあります。本稿は許可された環境でのトラブルシュートであり、セキュリティ制限の回避を助長する意図はありません。

チェックリスト

  1. システム設定でシステム拡張の承認が完了し、必要なら再起動済みか。
  2. TUN とシステムプロキシ自動設定が二重になっていないか（方針を一つに寄せたか）。
  3. 別 VPN／フィルタとルート競合していないか。
  4. config.yaml の tun と GUI の表示が矛盾していないか。
  5. 問題アプリの接続が Clash ログに現れるか（現れなければスタック／権限側を疑う）。
  6. DNS モード・fake-ip・ルール順が整合しているか（FAQ 参照）。

まとめ

macOS で Clash の TUN を使うときのつまずきは、しばしばシステム拡張の承認とシステムプロキシ設定の重なりの二点に集約されます。前者は OS のセキュリティ設計に沿って一度だけ丁寧に通し、後者は「どちらを主経路にするか」を決めて二重操作をやめる——この順序が再現性のある運用につながります。

Linux 向けの TUN 記事と違い、macOS では Network Extension とプライバシー設定が表に出ます。エラーメッセージをそのまま検索語にし、クライアントの公式ドキュメントと突き合わせると、バージョン差によるキー名の違いも吸収しやすくなります。

→ Clash を無料ダウンロードし、拡張の許可とプロキシ設定を揃えたうえで、ルールとログに集中できる環境から始めましょう。