まず実装方式を確認：TUNにシステム拡張が必要とは限らない

macOSでClashのTUNを有効にするには、コアが仮想ネットワークインターフェイスを作成し、ルーティングを変更できる権限が必要です。mihomoを使うクライアントでは、特権補助サービスをインストールし、コアからOSが提供する utun インターフェイスを操作する方法が一般的です。Apple Network Extensionを使うアプリでは、VPN構成の追加やネットワーク拡張の許可が必要になることがあります。この2つの方式は別物で、両方の手順を行う必要はありません。

この記事では、macOS 13以降の「システム設定」を基準に、補助サービスを使う方法とネットワーク拡張を使う方法を説明します。ボタン名はクライアントのバージョンによって異なるため、操作前に「情報」や「コア」の画面でクライアント、mihomo、macOSの各バージョンを確認してください。Appleシリコン搭載Macではarm64版、Intel Macではx86_64版を選びます。CPUアーキテクチャによってネットワーク権限の要件が変わることはありません。

仮想ネットワークインターフェイスが処理するのはIPトラフィックであり、すべての通信が自動的にプロキシ経由になるわけではない

TUNはレイヤー3の仮想ネットワークインターフェイスです。アプリが生成したIPパケットは、システムのルーティングに従って仮想インターフェイスへ送られ、プロキシコアが読み取ってルールに応じたプロキシノードへの転送、直接接続、または接続拒否を行います。システムのHTTPプロキシ設定を参照しない多くのアプリにも対応できますが、対象範囲はルーティング、除外リスト、IPv6の設定、ほかのVPNの影響を受けます。

そのため、「TUNを有効にすること」と「すべての通信をプロキシ経由にすること」は別々の設定です。TUNをルールモードで使う場合、DIRECT に一致した通信は直接接続されます。全般モードに切り替えても、システム側で除外された通信までコアを通るとは限りません。UDPが使えるかどうかは、選択したノードやプロトコル、サーバー側の対応状況にも左右されます。

システムプロキシとTUN：用途に応じて選ぶ

項目 システムプロキシ TUNモード
通信の入口 アプリがシステムプロキシを参照し、ローカルのプロキシポートに接続 システムのルーティングによって、条件に一致するIPパケットを仮想インターフェイスへ転送
主な用途 ブラウザー、システムプロキシに対応したデスクトップアプリ 一部のコマンドラインツール、ゲーム、プロキシ設定を参照しないアプリ
UDPの処理 一般的なHTTPプロキシではUDPを汎用的に転送できない UDPを受信できるが、接続先にもUDP転送への対応が必要
必要な権限 システムプロキシ設定の変更に許可が必要な場合がある 通常は補助サービスまたはネットワーク拡張の許可が必要
障害時の影響範囲 主にプロキシを使うアプリに影響 ルーティングやDNSに問題があると、Mac全体がネットワークに接続できなくなる場合がある

SafariでWebサイトを閲覧できれば十分な場合は、まずシステムプロキシを使いましょう。ブラウザーでは接続できるのにターミナルのツールが直接接続してしまう場合は、TUNを有効にする前にツール自体のプロキシ設定を確認してください。TUNは通信をカバーする範囲を広げる一方で、ルーティングやDNSの確認項目も増やします。遅延を改善するためのスイッチではありません。

まずシステムプロキシでノードを確認する

  1. サブスクリプションを追加して更新し、クライアントの構文チェックに通ることを確認します。
  2. ルールモードを選び、プロキシグループで利用可能なノードを指定します。
  3. システムプロキシを有効にし、ブラウザーから利用したいサービスにアクセスして、接続ログを確認します。
  4. ノードが正常に動作することを確認したら、システムプロキシを無効にしてTUNだけをテストします。2つの通信経路を混同しないようにしてください。

一部のクライアントではシステムプロキシとTUNを同時に使えますが、初回のトラブルシューティングでは入口を1つに絞るのがおすすめです。ノードのハンドシェイク自体に失敗している場合、TUNに切り替えても、期限切れのサブスクリプション、誤ったノードパスワード、サーバーへの接続不能は解決しません。

有効化する前に：設定をバックアップし、ネットワークの状態を記録する

クライアントを「アプリケーション」フォルダに移動してから、その場所から起動してください。ディスクイメージから直接実行したり、サービスをインストールした後でアプリを移動したりすると、補助サービスが参照するアプリのパスと現在のインストール先が一致しないことがあります。現在の設定、上書きファイル、プロキシグループの選択状態をバックアップしてください。サブスクリプションURLにはアクセス認証情報が含まれるため、公開の問い合わせフォームに貼り付けないでください。

  • ほかのトンネルを一時停止：ほかのVPNやTUNプロキシ、ルーティングを変更する可能性のあるネットワークツールを一時的に切断します。管理対象の端末では、組織のルールを確認し、会社から配布されたネットワーク構成を削除しないでください。
  • DNS設定を記録：「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「DNS」を開き、手動で設定したサーバーアドレスを記録します。
  • ローカルポートを確認：クライアントで実際に設定されているHTTP、SOCKS、または混合ポートを確認します。以下では 7890 を例にしますが、すべてのクライアントで同じ値とは限りません。
  • オフライン時の復旧手段を確保：あらかじめクライアントの設定画面を開き、TUNのスイッチと補助サービスの管理画面を確認しておきます。ネットワークが切断されてから復旧方法を探す事態を避けられます。

「アプリケーション」→「ユーティリティ」→「ターミナル」で以下の読み取り専用コマンドを実行すると、切り替え前の状態を記録できます。出力にはネットワークアドレスやインターフェイス情報が含まれるため、ログを共有する前に機密情報を伏せてください。

sw_vers
uname -m
scutil --proxy
scutil --dns
route -n get 1.1.1.1
ifconfig -l

uname -m は、Appleシリコン上でネイティブ起動したターミナルでは通常 arm64 を返します。Rosetta経由で起動している場合は x86_64 と表示されることがあるため、Appleメニュー→「このMacについて」でも機種を確認してください。route -n get で特定の宛先へのルートを調べると、デフォルトルートだけを見るよりTUNの動作確認に役立ちます。

方法1：補助サービスをインストールしてmihomoのTUNを有効にする

設定画面に「サービスモード」「補助サービス」「特権サービス」などが表示される場合は、通常この方法を使います。以下は一般的な手順であり、すべてのクライアントでメニュー名が共通とは限りません。実際のアプリ画面とプロジェクトの説明に従ってください。

  1. クライアントの「設定」を開き、サービス管理の項目から「インストール」または「補助サービスをインストール」を選択します。自分で操作したときに限り、システムの認証ダイアログで許可してください。
  2. 管理者アカウントで許可します。システムからパスワードの入力やTouch IDを求められる場合があります。アカウントに管理者権限がない場合は、端末の管理者に相談してください。
  3. 画面にサービスの実行状態が表示されるまで待ち、クライアントの案内に従ってコアを再起動します。インストールボタンが消えただけで、サービスが正常に起動したと判断しないでください。
  4. ネットワークまたはTUNの設定を開いてTUNモードを有効にし、初回のテストではクライアント推奨のスタックとルーティング設定をそのまま使います。
  5. 起動ログを確認し、権限不足、インターフェイスの作成失敗、ルートの追加失敗などがないことを確かめてから、実際の通信がログに記録されるか確認します。

特権補助サービスは通常、システムのサービス管理機構を通じて動作します。他社製カーネル拡張とは異なるため、この段階で「システム拡張を許可」ボタンが表示されなくても、許可手順を見落としたわけではありません。権限の問題を回避するために、グラフィカルクライアント全体を sudo で起動し続けることも避けてください。

補助サービスが起動しない場合の確認手順

  • 「アプリケーション」フォルダ内のクライアントを起動しているか確認します。ダウンロードフォルダやディスクイメージ内のコピーではないことも確かめてください。
  • アプリのアップデート後にサービスとの不一致が起きた場合は、まずクライアントに用意されたサービスのアンインストール機能と再インストール機能を使います。
  • macOS 13、14では「システム設定」→「一般」→「ログイン項目」のバックグラウンド項目を確認できます。macOS 15では「ログイン項目と機能拡張」が該当する画面です。バックグラウンド項目を登録しているアプリに限り、関連項目が表示されます。
  • 最初に失敗した時刻とエラーメッセージを記録してください。問題を切り分けるために、複数のクライアントの補助サービスを次々とインストールしないでください。

サービスの識別子、インストール先、管理コマンドはクライアントごとに異なります。他のプロジェクトの launchctl 削除コマンドをそのまま実行したり、/Library/LaunchDaemons/ 内のファイルをまとめて削除したりしないでください。

方法2：VPN構成とネットワーク拡張を許可する

クライアントがNetwork Extensionを採用しており、実際に関連する許可を求められた場合に限り、この方法を使います。AppleのNetwork Extensionフレームワークには複数の導入方式があります。VPN構成の許可、アプリ拡張、システム拡張の承認はそれぞれ別の手続きで、すべてを「ドライバーの許可」と呼ぶことはできません。

  1. クライアントでトンネル機能を有効にします。macOSからVPN構成の追加を求められた場合は、アプリ名を確認してから許可します。
  2. システム拡張がブロックされたという通知が表示されたら、案内に従って「システム設定」を開きます。macOS 13、14では通常、「プライバシーとセキュリティ」画面の下部に承認項目が表示されます。保留中の要求がある場合のみ表示される点に注意してください。
  3. macOS 15では「システム設定」→「一般」→「ログイン項目と機能拡張」→「ネットワーク機能拡張」を確認します。表示される項目はアプリが採用する拡張の種類やインストール状態によって異なります。
  4. システムまたはクライアントから求められた場合に限り、Macを再起動します。その後、アプリでトンネルに接続し、「システム設定」→「VPN」または「ネットワーク」の関連画面で接続状態を確認してください。

現在使っているクライアントとは関係のないVPN構成をまとめて削除しないでください。個人用VPN、会社のVPN、コンテンツフィルタは別々のネットワークコンポーネントの場合があります。削除前に名前と用途を記録し、まず該当アプリから切断またはアンインストールしてください。

mihomoの設定：TUN、DNS、ルールを個別に確認

多くのグラフィカルクライアントは、起動前にサブスクリプション、上書き設定、画面上の設定を統合します。サブスクリプションのキャッシュファイルを直接編集しても、次回の更新で上書きされることがあります。クライアントのTUN設定または永続化できる上書き機能を使い、最終的な実行設定を確認してください。オリジナル版Clash、旧バージョンのPremium、mihomoでは、利用できる設定機能が完全には一致しません。

以下はmihomoの部分的な設定例で、そのままインポートできるサブスクリプション全体ではありません。ノード、プロキシグループ、ルールは含まれていないため、既存の設定に統合してください。トップレベルの tun や dns キーを重複させないよう注意してください。クライアントが該当項目を生成する場合は、クライアント側の設定方法を優先します。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  • auto-route：コアがTUNへのルートを自動設定します。設定できたかどうかはログと実際のルーティングで確認してください。
  • auto-detect-interface：送信インターフェイスの自動検出を試みます。Wi-Fi、有線LAN、ほかのVPNを同時に使っている場合は、誤った出口が選ばれていないか重点的に確認します。
  • dns-hijack：TUNに入ってきた条件に合う従来型DNSリクエストを、コアのDNSに渡します。この例はUDPとTCPの53番ポートを対象としますが、あらゆる暗号化DNSを自動で復号するものではありません。
  • fake-ip-range：fake-ipの割り当てに使うアドレス範囲を指定します。プロキシサーバーのアドレスではありません。既存のネットワーク用途と競合する場合は、ネットワーク環境に応じて調整してください。

例にあるDNSの上流サーバーは、設定構造を説明するための平文DNSリゾルバーです。あらゆるネットワーク環境で推奨される設定ではありません。社内ネットワークのドメインは会社のDNSでしか解決できない場合があります。ドメインごとに nameserver-policy などを設定し、すべての名前解決先を単純にパブリックDNSへ置き換えないでください。

見落としやすい2つのポイント

IPv6は個別に確認してください。この設定例は、IPv6通信をすべてTUNに取り込むための完全な構成ではありません。IPv4とIPv6の両方が使えるネットワークでは、コアのIPv6設定、TUNのルーティング、実際の接続ログを確認します。IPv4のテストが成功しただけで、すべての通信が想定どおりに転送されていると判断しないでください。

DNSが正常でも、ルールが正しいとは限りません。ルールは通常、上から順に照合され、最初に一致した時点でポリシーが決まります。社内ドメインを直接接続するか特定の出口を使うかは、ルールに明示してください。TUN自体がルールの順序を修正したり、サブスクリプションにないルールセットを補ったりすることはありません。

動作を確認する：インターフェイス、ルーティング、接続ログをあわせて見る

TUNのスイッチがオンになっただけでは、画面上の状態が変わったことしか分かりません。utun が表示されても、使用中のクライアントが通信を正しく取り込んでいるとは限りません。macOSのサービスやほかのVPNもutunインターフェイスを作成することがあり、番号も変わります。utun0 や utun3 を常に使われる番号として扱わないでください。

ifconfig -l
route -n get 1.1.1.1
scutil --dns
scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN

有効化する前後のインターフェイス一覧を比較し、特定の宛先へのルートがクライアントの想定どおりか確認します。実装によっては、唯一のデフォルトルートを置き換えるのではなく、より具体的なルートを複数追加します。lsof コマンドは、例に示したローカルポートでプロセスが待ち受けているかを調べるだけで、TUNが有効になった証明にはなりません。

明示的なプロキシを使わずにリクエストをテストする

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

このコマンドはHTTPプロキシやSOCKSプロキシを明示的に使わないため、TUNのテストに適しています。接続タイムアウトは10秒、全体のタイムアウトは20秒に設定されており、失敗時に早く結果を確認できます。実行後、クライアントの接続画面で example.com を検索し、一致したルール、プロキシグループ、実際のノードを確認してください。HTTPレスポンスを受け取れたことだけでは、プロキシ経由で接続した証拠にはなりません。

  • まず、本来は直接接続する宛先をテストし、ログに想定どおりの直接接続ポリシーが表示されることを確認します。
  • 次に、プロキシ経由にする宛先をテストし、ルール末尾の意図しないフォールバックではなく、正しいプロキシグループに一致していることを確認します。
  • UDPを使う場合は、実際に利用するUDPアプリでテストしてください。TCPリクエストが成功しても、UDP転送が正常とは限りません。
  • Wi-Fiを切り替えた後やスリープから復帰した後にもテストし、ネットワークの変化にインターフェイスの自動検出が追従しているか確認します。

よくあるトラブルと復旧手順

有効にするとMac全体がネットワークに接続できない

まずTUNを無効にして基本のネットワーク接続が戻るか確認し、ログで最初に発生したエラーを調べます。無効化後に復旧する場合は、DNSリクエスト、ルーティング設定、送信インターフェイスを優先して確認してください。復旧しない場合は、システムプロキシが終了済みのローカルポートを参照していないか、別のVPNが接続中ではないか確認します。

システムプロキシは使えるが、TUNで権限不足と表示される

ノードを変更する前に、補助サービスの状態を確認してください。サービスがインストール済みか、現在のアプリのパスが変わっていないか、アップデート後にサービスの更新が必要かを調べます。インターフェイスの作成やルートの追加に失敗したというエラーがある場合は、そのログを保存し、使用中のクライアントに用意されたサービス管理方法に従って修復してください。

Webサイトは見られるが、ゲームや音声通話が使えない

該当する通信が実際にTUNへ入っているか、ノードがUDPに対応しているか、ルールが正しい出口を選んでいるか確認してください。特定のネットワークだけで失敗する場合は、その後でパスMTUや通信事業者側の制限を検討します。いきなり小さいMTU値をコピーして使わず、失敗する状況を記録してから一つずつ試してください。

スリープから復帰した後にドメイン名を解決できない

まずTUNに再接続し、実際の送信インターフェイスとDNSの状態を確認してください。システムのDNSキャッシュを消去する必要がある場合は、ルーティングとコアのDNSが復旧していることを確認してから、以下のコマンドを実行します。これらのコマンドで、誤ったDNS上流やルールが修正されるわけではありません。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

使用をやめるときの戻し方

  1. クライアントでTUNを無効にし、接続が切れたことを確認してからアプリを終了します。最初にコアを強制終了しないでください。
  2. システムプロキシも有効にしていた場合は、クライアントで無効にしてから scutil --proxy で設定の残りがないか確認してください。
  3. 事前に記録した手動DNS設定を元に戻します。もともとDNSを自動取得していたネットワークに、一時的なパブリックDNSを残さないでください。
  4. クライアントを使わなくなった場合は、アプリに用意された手順で補助サービスをアンインストールします。Network Extensionを使う方式では、該当アプリのアンインストール手順に従って関連する構成を削除してください。
  5. 直接接続できることを再確認し、必要に応じて現在のネットワークサービスをいったん切断して再接続します。

引き続き確認する場合はトラブルシューティングガイドをご覧ください。サブスクリプションの初回追加やプロキシグループの選択方法については、クイックスタートを参照してください。問い合わせの際は、システムのバージョン、クライアントとコアのバージョン、使用した有効化方法、機密情報を伏せた最初のエラーを添えると、スイッチのスクリーンショットだけを送るより役立ちます。