1. TUN が必要になる状況と限界
Clash Verge Rev は裏側で Mihomo（Clash Meta） 系のコアを動かし、購読から落ちてきた YAML に従ってルール分流します。そのうえでトラフィックをコアへ載せる方法として、代表的なのがシステムプロキシ（HTTP／SOCKS へのアプリケーション挙動）と、より下位から経路を捕まえる TUN モードです。ブラウザ中心でよく、かつクライアントがプロキシ設定をうまく書き換えられるならシステムプロキシだけでも足りることが多いのですが、プロキシ非対応の CLI ツールや独自スタックのアプリまで含めて同じ方針で扱いたいときは、TUN 側にトラフィックを載せる考え方が現実的になります。
一方で macOS では TUN を扱うコンポーネントが システム拡張やネットワーク拡張の枠に乗るため、UI で「オン」にしただけでは完結せず、プライバシーとセキュリティやログイン項目と拡張機能の画面で開発元を許可する工程が挟まるのが普通です。初回だけ通ればあとは楽になる一方、企業端末の MDM や管理者ポリシーで止まる場合もある点は押さえておいてください。
2. 始める前の確認
作業は短くても、順番が崩れると「許可したはずが効いていない」ように見えます。まずアプリ本体を最新系に近づけることと、使用中のプロファイルが購読と整合していることを確認してください。Mihomo ログに致命的な構文エラーがある状態で TUN を足しても、期待した経路には乗りません。
次に、同時常駐する VPN や広告ブロッカー型の仮想ドライバ、パケットを握るタイプのセキュリティ製品があれば、切り分けのためにいったん止めるのが安全です。macOS は複数の拡張がルートやインターフェースを奪い合うと、どれが有効かログを読まないと分からなくなります。他社 VPN と Clash の二重化は、意図した挙動にならない典型例です。
管理付き Mac では、システム拡張の承認自体がユーザー操作でも許可されないケースがあります。その場合は IT ポリシーの確認が先で、アプリ側の設定以前の問題になります。
3. Verge Rev で TUN をオンにする
Clash Verge Rev の具体的なメニュー名はリリースで多少変わりますが、考え方は一定です。設定または詳細オプションに相当する画面で、TUN／仮想インタフェース／システムスタック強化などと書かれたトグルを探し、コアが再起動してもエラーなく立ち上がるかを見ます。ここでオンにした瞬間に macOS 側から「拡張機能を許可してください」という導線が出ることも多いので、先に許可画面を閉じないようにしてください。
コアの起動ログを併読する
TUN をオンにしたあと、Mihomo のログに Start TUN listening やインターフェース名（utun 系）に関する行が増えるかを確認すると、UI と実体のズレを早く潰せます。逆に権限不足やスタック指定不整合のときは、ここでエラーが一度に出ることがあります。
既に TUN をオフに戻したい場合も、トグルを切ったうえでログにリスナ停止が出るかを一度見ておくと、次回の起動時の迷子が減ります。
4. システム拡張と Network Extension を許可する
macOS Ventura 以降の新しい設定画面では、プライバシーとセキュリティのなかにシステム拡張や開発元の許可に関する項目がまとまりがちです。従来の「セキュリティ」セクションでのブロック解除や、復旧／Reduced Security まわりの文言はハードウェア世代によって違うため、画面に出た Apple 公式の案内に従うのがもっとも安全です。
初回に「許可」を押し損ねると、あとから設定を開いてもどのアプリの拡張を有効にするかが分かりにくい、という事象があり得ます。いったん Clash Verge Rev を終了し、システム設定で拡張機能の一覧を開き、該当エントリをオンにしてからアプリを再起動する流れが安定しやすいです。必要であれば Mac を再起動してからもう一度トグルを操作してください。
ログイン項目と拡張機能に関連する画面で、バックグラウンド実行が制限されていると、スリープ復帰後にだけ TUN が死ぬ、というパターンもあります。システムプロキシ記事 で触れたログイン項目の話と同じく、省電力・常駐方針が絡みます。
5. YAML の tun ブロックを確認する
GUI のトグルがmixinや上書きレイヤによって tun: を自動注入する設計の場合、ファイル上に無いままでも動くことがあります。しかし期待どおりに立ち上がらないときは、実際にコアへ渡っている合成後の設定を確認し、必要なら購読側かローカル上書きに tun を明示します。Mihomo 系では典型的に enable、stack、auto-route、dns-hijack などが議論の中心になります。
ダイアログやドキュメントの用語は 公式ドキュメント と突き合わせると安全です。特に strict-route や DNS の取り扱いは、Fake-IP 構成と組み合わさったときに体感が大きく変わります。
次はあくまで一般的な例示です。自宅のプロファイルに合わせて値は変えてください。
tun:
enable: true
stack: system
auto-route: true
strict-route: false
dns-hijack:
- any:53stack を gvisor や mixed へ変える運用もありますが、CPU 負荷と互換性のトレードオフがあります。段階的に試すなら、まずは環境依存の少ない指定からが無難です。
6. ルートと疎通で効いたか検証する
TUN が生きているかは、クライアントのログとOS のルーティングの突き合わせが本命です。ターミナルから netstat -nr や route -n get default（環境によりコマンドが異なります）で、デフォルト経路や utun 系インターフェース周辺の変化を眺めると、思ったより早く「勝ち／負け」が分かります。GUI だけでは見えないレイヤなので、ここを飛ばさないのがコツです。
外向き疎通では、ブラウザの IP 確認ページに限らず、同名のホストを CLI から curl して挙動を比べると、プロキシ非対応ツールが TUN に載ったかを切り分けやすくなります。ターミナルとプロキシ環境変数 の記事では HTTP プロキシ前提の話が多いですが、TUN を使う場合は「環境変数を増やさずに端末アプリも同じ出口へ」の確認として読み替えられます。
| 見ている指標 | よい兆候／次に見る場所 |
|---|---|
| コアのログ | TUN 関連の開始／停止行が操作に同期する。不可解な権限エラーが消えている。 |
| ルートと interface | 期待する utun 経由の記述が増減する。別 VPN がデフォルトを奪っていない。 |
| ブラウザと CLI の差 | 同宛先への curl とブラウザの出口が極端に食い違わない。 |
| DNS の挙動 | Fake-IP／redir-host とクライアントの DNS 設定が矛盾しておらず、名前解決がループしていない。 |
ここで出口は合っているのに特定サービスだけ失敗する場合は、多くがルール順と SNI、あるいはプロバイダ側の都合です。TUN 以前のレイヤとして DNS を疑ってください。
7. システムプロキシとの関係
TUN をオンにしたからといって、常にシステムプロキシをオフにしろ、というルールはありません。実際の運用ではどちらか一方だけに絞るチームと、ブラウザはプロキシ・その他は TUN という住み分けをするチームの両方が見られます。大事なのは、同じ接続が二重に別々の経路へ衝突しないようにすることと、トラブル時に切り分けの変数を一つずつにすることです。
システムプロキシが有効なまま TUN も動く局面では、ログ上の policy と実際のアプリ挙動の対応を丁寧に見ないと混乱します。迷ったらいったんシステムプロキシのみ／TUN のみ、と単純化して再現テストするのが早道です。
8. よくある質問
TUN をオンにするとシステムプロキシは不要ですか？
排他的ではありません。載せたいアプリ集合と DNS／ルール設計に応じて選びます。併用するならログで挙動を一緒に見てください。
拡張機能を許可したのに TUN が立ちません。
競合ソフト、権限ダイアログの取りこぼし、MDM 制限を疑います。Clash Verge Rev と OS を再起動し、拡張の一覧から該当エントリを再確認してください。
YAML に tun が無いのですが。
mixin で後付けされている可能性があります。合成結果を確認するか、明示的に tun: を書き、他セクションとのポート衝突を避けてください。
9. まとめ
Clash Verge Rev で macOS の TUN モードを実用に乗せるには、UI のトグルに加えてシステム拡張／Network Extensionの承認、YAML の tun 定義、そしてルーティングとログの突き合わせまでを一連の作業として扱うのが近道です。片方だけ片付けても「オンなのに挙動が変わらない」ように見えやすく、権限と設定ファイルの両方を短いサイクルで回すほど安定感は上がります。
汎用の小さなプロキシツールは手早い一方、購読のマージやルールプロバイダ、DNS、Fake-IP の整合まで含めると設定が散らばりがちです。Clash／Mihomo のようなルールエンジン一体型では、同じ YAML を GUI とファイルの両方から扱え、ログも追いやすいため、TUN のように OS レイヤへ手を入れるモードほど「結果の説明可能性」が効いてきます。外向き経路を固めたあとは、用途別のドメイン分流や ヘルプ に挙がる高度なポリシーへ進めます。