macOSでTUNモードを有効にする方法｜ターミナルや全通信をプロキシ経由にする仕組みと手順

システムプロキシとTUN：通信を取り込む場所の違い

Macでシステムプロキシを有効にするとブラウザーは接続できるのに、ターミナルのコマンドはタイムアウトすることがあります。通常、設定が効いていないのではなく、両者で通信経路が異なります。システムプロキシはHTTP、HTTPS、SOCKSのプロキシアドレスを提供し、アプリ側が設定を読み取って利用します。一方TUNは、仮想ネットワークインターフェースとルーティングを使い、対象となるIP通信をプロキシコアに転送します。

「全通信」を必ず網羅できるという意味でもありません。LAN向け通信の除外、インターフェースを明示的に指定するアプリ、別のVPNのルート、OS自身の通信などにより、実際の適用範囲は変わります。メニューバーのスイッチだけで判断せず、対象アプリの接続を確認してください。

有効にする前に：コア、ノード、現在のネットワークを確認

クライアントが実際に使用しているコアを確認する

Clashは設定やクライアントのエコシステムで広く使われる名称ですが、すべてのアプリが同じコアを採用しているわけではありません。Clash Metaは後にmihomoとして開発が続いています。特定のTUN設定項目に対応しているかは、実際に動作しているコアのバージョンとドキュメントで確認してください。まずクライアントの「バージョン情報」、コア管理画面、または起動ログで、クライアントのバージョン、コア名、バージョン番号を控えます。GUIのバージョンとコアのバージョンは別の情報であり、互いに代用できません。

まず基本の接続状態を確認する

1. サブスクリプションを更新し、利用可能なノードを選択します。システムプロキシだけを有効にした状態で、ブラウザーから確認対象のサイトにアクセスできることを確かめてください。
2. 現在のモードが「ルール」になっていることを確認し、対象ドメインがどのポリシーグループに一致するかを確認します。ノードの遅延テストに成功しても、HTTPSやUDPが使えるとは限りません。
3. 個人用VPN、通信高速化ツール、別のプロキシクライアントは一時的に切断します。組織の管理下にあるVPNは勝手にアンインストールせず、ネットワーク利用要件を先に確認してください。
4. 現在のシステムプロキシの状態とローカルのリスニングポートを控え、既存の設定もバックアップします。問題が起きたときに元の状態へ戻しやすくなります。

ポート番号はクライアントの設定画面で確認してください。たとえば、ローカルの混合ポートが実際に7890の場合に限り、127.0.0.1:7890が有効なプロキシの接続先になります。これはすべてのクライアント共通の固定値ではありません。また、TUNはシステムプロキシのポート番号を別の値に変更する機能ではありません。

許可と有効化：サービスを導入してから通信を取り込む

メニュー名はクライアントによって異なります。Clash Verge Revの一般的な画面を例にすると、「設定」→「Clash設定」を開き、「サービスモード」のインストール状況と稼働状態を確認してから「TUNモード」を有効にします。現在のバージョンで場所が変わっている場合は、画面上の「サービスモード」と「TUNモード」の設定項目を探してください。他のクライアントのメニュー手順をそのまま当てはめないでください。

1. 特権ヘルパーサービスをインストールします。サービスモードのインストールボタンをクリックします。macOSから許可を求められたら、要求元が起動したばかりのクライアントであることを確認し、システムの案内に従って管理者認証を行ってください。ターミナルからGUIアプリ全体を管理者権限で起動するのは避けてください。
2. サービスの稼働状態を確認します。インストールが完了すると、画面にサービスの準備完了が表示されます。未インストール、または接続不可のままの場合は、TUNを何度も切り替えず、先にサービスのエラーを解消してください。
3. TUNモードを有効にします。コアが設定を再読み込みするまで待ち、仮想インターフェースの作成やルートの追加に失敗したというログがないか確認します。成功時の表示はバージョンによって異なります。
4. 初回テストではルールモードのままにします。まず既存のルールを確認してください。ノードの変更、グローバルモードへの切り替え、DNS設定の変更を同時に行うと、結果に影響した変更を特定しにくくなります。
5. TUN単独の動作を確認します。サービスが安定したら、システムプロキシを一時的に無効にしてテストできます。これにより、ブラウザーが読み込んだHTTPプロキシを引き続き経由しているのではなく、TUNで通信が取り込まれているかを確認しやすくなります。

Appleシリコン搭載MacではAppleシリコン対応クライアントを、Intel Macでは対応するアーキテクチャ版を選んでください。アーキテクチャは主にアプリやヘルパープログラムが正常に動作するかに関係します。どちらの環境でも、TUN、ルーティング、ルールによる振り分けの基本的な関係は同じです。

設定項目：ルーティング、スタック、DNSの取り込み

GUIクライアントにTUNスイッチがある場合は、まず画面から設定してください。クライアントによっては、GUIの設定を実行用の設定に統合します。サブスクリプションの元ファイルを直接編集すると、更新時に上書きされる場合があります。独自の設定が必要なら、クライアントのオーバーライド機能や設定マージ機能を使い、最終的な実行設定に反映されていることを確認してください。

以下はmihomoの設定例の一部で、TUN関連の項目だけを示しています。単独で動作する完全なサブスクリプションではありません。利用可能なプロキシ、ルール、および有効化済みの内蔵DNS設定があることを前提としています。

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

• enable：TUN機能を有効にします。GUIのスイッチをオフにすると、クライアントがこの値を再生成する場合があります。
• stack: mixed：混合スタックを選択します。他の値や動作については、使用中のコアの対応状況を確認してください。通信が遅いからといって、値を手当たり次第に変更しないでください。
• auto-route：コアが関連するルートを自動設定します。カスタムルート、別のVPN、管理ポリシーによって、最終的な通信経路が変わる場合があります。
• auto-detect-interface：送信インターフェースの自動検出を試みます。Wi-FiからEthernetに切り替えた後に接続がおかしくなった場合は、コアを再起動して検出結果を確認してください。
• dns-hijack：対象となる従来型DNSリクエストを内蔵DNSに渡します。例のany:53は、「暗号化DNSをすべて取り込む」という意味ではありません。

ドメインルールでDNSが重要な理由

多くの振り分けルールはドメイン名を使いますが、TUNが受け取る基本情報はIPパケットです。コアはDNSの対応関係、接続メタデータ、または設定されたスニッフィング機能を使ってドメインを識別します。fake-ipでは内蔵DNSが対応するアドレスを返し、その後コアが本来の宛先と関連付けます。他のDNSモードでは、ドメインを関連付ける経路が異なる場合があります。

ブラウザーのセキュアDNSは通常HTTPSを使用し、通信には443番ポートを使います。53番ポートを横取りしても、暗号化DNSが自動的にコアから見える平文DNSに変わるわけではありません。ルールが想定どおりに一致しない場合は、ブラウザーのDNS設定、コアのDNSログ、実際に一致したルールを照らし合わせてください。フィールドをひとつ変更しただけで、ドメインを完全に識別できると決めつけないでください。

TUNの動作確認：インターフェース、ターミナル接続、ルールを照合する

手順1：ネットワーク状態を確認し、インターフェース名だけで判断しない

「ターミナル」を開き、次の読み取り専用コマンドを実行します。1つ目はシステムプロキシの設定、2つ目はネットワークインターフェースの一覧、3つ目は指定した宛先へのルートを表示します。

scutil --proxy
ifconfig
route -n get 1.1.1.1

macOSでは、仮想インターフェース名に数字を付けたutunがよく使われますが、システムサービスや他のVPNも同種のインターフェースを作成します。そのため、utun3が見えても、現在のクライアントが作成したものとは限りません。有効化前後の変化、クライアントのログ、ルートの結果を合わせて判断してください。特定の宛先だけを調べたルート結果は、すべての宛先を代表するものではありません。

手順2：ターミナルでアプリ層プロキシを明示的に使わない

macOS標準のcurlを使ってテストし、--noproxy '*'を指定してcurlのアプリ層プロキシを迂回します。このオプションではTUNを迂回しないため、2つの通信取り込み経路を見分けるのに役立ちます。

/usr/bin/curl --noproxy '*' --connect-timeout 10 --max-time 20 -I https://example.com

この例では、接続タイムアウトを10秒、全体のタイムアウトを20秒に設定しています。HTTPレスポンスが返っても、その宛先に接続できたことしか分からず、プロキシノードを経由した証明にはなりません。一部のネットワークでは、このサイトへもともと直接接続できる場合があります。コマンドを実行しながらクライアントの接続一覧も開き、example.comの接続を探して、一致したルール、ポリシーグループ、最終的な送信先を確認してください。

手順3：無効にしたときの動作と比較する

1. ノード、ルール、テストURLを変えずに、TUN有効時の接続ログを記録します。
2. TUNを無効にし、システムプロキシもオフのまま、同じコマンドをもう一度実行します。
3. クライアントに接続が引き続き表示されるか、一致するルールが同じか、リクエスト結果がどう変わったかを比較します。
4. 必要なスイッチを元の状態に戻します。結果が変わらない場合は、対象がもともと直接接続されていたか、別のVPNが動作していないか、テストアプリが以前の接続を再利用していないかを確認してください。

ゲームをテストする場合は、ゲームが実際に確立するUDPセッションも確認してください。Webページが開けることやTCPテストの成功だけでは、ノードがゲームに必要なUDPに対応しているとは判断できません。ログイン、データのダウンロード、対戦で異なるドメインやポートが使われることもあるため、ランチャーだけでなく、それぞれの通信を確認してください。

よくあるトラブル：権限、ルート、DNS、送信先の順に確認

TUNを有効にするとすぐオフになる、またはインターフェースの作成に失敗する

まずヘルパーサービスが稼働しているか、コアが正常に起動しているかを確認します。次に、実行設定のYAMLインデントに誤りがないか、現在のコアが未対応の項目を使っていないかを調べてください。インストーラーの更新後は、クライアントと古いヘルパーサービスの組み合わせが合わなくなることがあります。クライアントのサービス管理画面から修復し、用途の分からないシステムファイルを手動で削除するのは避けてください。

有効にすると、すべてのWebサイトに接続できなくなる

まずTUNを無効にして、通常のネットワーク接続が復旧するか確認します。その後、ノードへの接続、DNS上流への到達性、ログに表示される送信インターフェースを調べてください。VPNを同時に使っている場合は、許可されている範囲で一方を一時停止して再テストします。ルート同士が競合すると、通信が誤ったトンネルに入ったり、DNSリクエストが上流に届かなくなったりすることがあります。

IPアドレスには接続できるが、ドメイン名を解決できない

内蔵DNSが有効か、上流のリゾルバーに到達できるか、DNSリクエストが正しく取り込まれているかを重点的に確認します。ドメイン名の代わりにHTTPS接続でIPアドレスを使う方法は避けてください。証明書や仮想ホストは通常、ドメイン名を必要とします。macOSのscutil --dnsでリゾルバーの状態を確認できますが、最終的には対象アプリが実際に使う名前解決経路も調べてください。

ターミナルの通信は取り込まれるのに、特定のアプリは直接接続される

まず、「コアに取り込まれた後でDIRECTに一致している」ケースと、「そもそもコアに取り込まれていない」ケースを切り分けます。前者はルールの順序、ポリシーグループの選択、LAN向け通信の除外を確認します。後者はアプリが特定のインターフェースにバインドされていないか、別のネットワーク拡張が通信を取り込んでいないか、TUN有効化前から接続が確立していないかを調べてください。新しい接続を確認するには、ウィンドウを更新するだけでなく、対象アプリを終了して再起動するのが確実です。

スリープ復帰後やWi-Fi切り替え後に接続できなくなる

再接続を繰り返しているアプリの通信をいったん切り、コアを再起動してインターフェースの検出とルートを作り直します。頻繁に再発する場合は、切り替え前後のネットワーク種別、コアのバージョン、関連ログを記録してから問題を報告してください。ログを共有する際は、サブスクリプションURL、ノードの認証情報、その他の個人ネットワーク情報を削除してください。

無効化と復旧：いつでも再現できる手順を残す

TUNが不要になったら、まずクライアントでTUNを無効にし、通常のネットワーク接続が戻ったことを確認してからアプリを終了します。システムプロキシを有効にしていた場合は、必要に応じてこちらも無効にしてください。システムプロキシが終了済みのローカルプロセスを参照したままだと、その設定に従うアプリがネットワークに接続できないことがあります。

• Wi-Fiのプロキシ設定を確認する手順：「システム設定」→「ネットワーク」→「Wi-Fi」→「詳細」→「プロキシ」。有線接続の場合は、該当するネットワークサービスを選択します。
• VPN設定を確認する手順：「システム設定」→「VPN」。クライアントが作成する低レベルのTUNは、独立したVPN項目として表示されない場合があります。項目がないからといって、仮想インターフェースがないとは限りません。
• 異常終了後にネットワークが復旧しない場合は、まず元のクライアントを再起動し、TUNとシステムプロキシを通常の手順で無効にしてください。必要ならMacを再起動します。ルートテーブル全体をすぐに消去するのは避けてください。