macOS VPN おすすめ:Apple シリコン対応とシステム権限実測比較

macOS の VPN 選びで難しいのは、どのクライアントを入れるかではなく、入れた後にシステムが権限を渡してくれるかどうかだ。M シリーズチップの Mac では、クライアントはシステム拡張とネットワーク拡張で utun インターフェースを引き受けるか、ローカルループバックアドレスだけを待ち受けるアプリケーション層プロキシに退化するかのどちらかになる。前者はすべての App をカバーし、後者はプロキシを使う設定にしたソフトしか通らない。本記事ではチップ構成と OS バージョンごとにこの二つの経路を分け、承認手順、プロトコルの選び方、そして接続はできているのに通信できない場合のチェックリストを示す。

macOS クライアントの3 つの形態

macOS で海外サービスにアクセスする方法は、システムレベルでは 3 つしかない。違いは、トラフィックの行き先を誰が決めるかだ。

ネットワーク拡張は NetworkExtension フレームワークの NEPacketTunnelProvider で、システム内に utun の仮想ネットワークインターフェースを作り、クライアントがトラフィックをトンネルに流し込む。この経路には 2 段階の承認が要る。まず開発者のシステム拡張をシステムに受け入れさせ、次にクライアントによる VPN 構成の追加を許可する。承認は一度済ませれば長く有効だが、OS のメジャーアップデートをまたぐと再確認を求められることがある。

アプリケーション層プロキシは、ローカルループバックアドレス上にポートを 1 つ開くだけだ。よくある形は 127.0.0.1 上の SOCKS5 か HTTP プロキシで、プロキシに対応した App が自分から接続しに行く。システム権限は一切不要で、管理された端末にインストールしても承認ダイアログは出ない。代わりに、コマンドラインツールやシステムのプロキシ設定を読まないアプリは個別に設定が必要になり、バックグラウンド更新のようなトラフィックはプロキシを通らない。

カーネル拡張は macOS 10.15 以降、段階的に廃止された古い方式だ。Apple シリコンの Mac は標準ではサードパーティ製 kext の読み込みを許さず、有効にするにはリカバリモードで起動セキュリティを下げる必要がある。現在の正規クライアントはこの経路を使わない。システム整合性保護(SIP)の無効化を求めてくるインストーラは、その時点で除外してよい。

Apple シリコン対応:実測で見えた 4 つのつまずき

M シリーズチップでは、インストールできるかどうかと、入れた後に使えるかどうかは別問題になる。実測で出現頻度が高かった 4 つのつまずきを挙げる。

1. アーキテクチャ:ネイティブ arm64 と Rosetta 翻訳。アクティビティモニタの「種類」列を見れば判別でき、Intel と表示されていればクライアントは Rosetta 2 の翻訳層で動いている。翻訳版でも接続はできるが、ネットワーク拡張が翻訳層の下ではハンドシェイクが遅れたり、常駐メモリが高めになったりすることがある。ネイティブ arm64 のインストーラを選べば、不確定要素が 1 つ減る。
2. 署名と公証。署名も公証もないパッケージは初回起動時に止められ、開発元を検証できないと表示される。「システム設定 → プライバシーとセキュリティ」の下部にある「このまま開く」を押せば起動できるが、OS のメジャーアップデート後に再度止められることがある。正規に配布されるインストーラは公証済みなので、この表示が繰り返し出ることはないはずだ。
3. システム拡張の承認が 1 段階抜けている。クライアントは接続済みと表示するのに utun インターフェースができていない場合、多くはシステム拡張のスイッチが入っていない。「システム設定 → 一般 → ログイン項目と拡張機能 → ネットワーク拡張」にあり、古いバージョンでは「プライバシーとセキュリティ → 拡張機能」にある。オンにした後、クライアント側で一度完了を押して初めて承認が完了する。
4. ローカルネットワークの権限。新しい macOS では、App が初めて LAN 上の機器にアクセスすると「ローカルネットワーク」の許可を求められる。拒否するとルーターの管理画面、NAS、プリンターへのアクセスが制限されるが、海外サーバーとの通信自体は影響を受けない。迷ったらまず許可し、あとで「プライバシーとセキュリティ → ローカルネットワーク」で切ればよい。

初回起動:権限付与の手順

この順番で一度通せば、手戻りのほとんどは避けられる。

1. インストーラを「アプリケーション」フォルダにドラッグしてから起動する。ディスクイメージ内でそのままダブルクリックして動かすと、パスが読み取り専用のため後の自動更新が失敗する。
2. 初回起動で Gatekeeper に止められたら「プライバシーとセキュリティ」で許可する。このときシステムはログインパスワードの入力か Touch ID の確認を求めてくる。
3. クライアントが VPN 構成の追加を求めてきたら許可を押す。この操作は実質的にネットワーク拡張を 1 つの VPN 構成として登録するもので、断ってしまうとシステム設定から手動で追加するしかなくなる。
4. 案内に従ってシステム拡張のスイッチを入れ、クライアントに戻って確認する。この時点で「システム設定 → VPN」の一覧に、クライアントが管理する構成が 1 件表示されているはずだ。
5. ユーザー名とパスワードでログインする。メールアドレスは不要だ。同じアカウントで台数の制限はなく、Mac、iPhone、Windows を同時にオンラインにできる。ログイン後にサブスクリプション URL を読み込むと、サーバー一覧が自動で取得される。
6. 回線を 1 つ選んで接続し、後述のコマンドで DNS とデフォルトルートが本当にトンネルに入ったか確認する。

iCloud サービスとの共存で注意したい点

iCloud プライベートリレー

プライベートリレーもサードパーティ製クライアントもネットワーク拡張であり、システムは同時に 1 つの経路しかトラフィックに使わせない。よくあるのは、クライアントを有効にするとプライベートリレーが使えなくなる、あるいは逆にプライベートリレーがクライアントのトンネルを押しのけてしまうケースだ。どちらかを選ぶしかない。出口の地域を固定したい、ドメイン単位で振り分けたいという場合は、「システム設定 → Apple アカウント → iCloud → プライベートリレー」でオフにする。

Handoff、AirDrop、ユニバーサルクリップボード

これらの機能は Bluetooth とピアツーピアの Wi-Fi を使い、utun 仮想インターフェースを通らない。通常は加速をオンにしてもオフにしても同じように使える。例外は、オンデマンド接続を全トラフィックの引き受けに設定し、さらに LAN のセグメントまでトンネルに入れている場合で、このときはデバイスの検出が遅くなる。192.168 のようなプライベートセグメントと .local ドメインを直接接続にすれば解消する。

iCloud ドライブと地域の判定

iCloud ドライブや写真の同期は通常の HTTPS トラフィックなので、トンネルを通る。回線の帯域が限られている場合は、大きなファイルの同期と加速を使う時間帯をずらせばよい。もう 1 つよくある誤解が、出口を変えれば App Store の地域が変わるというものだ。アカウントの地域は Apple アカウントの請求情報で決まり、出口 IP とは関係がない。回線を変えてもストアの内容は変わらない。

プロトコルと回線:macOS での使い分け

プロトコルはクライアントがどうやってトラフィックをトンネルに流し込むかを決め、回線は流し込んだ後にどの経路を通るかを決める。この 2 つは分けて考える。

TCP 系のプロトコルは macOS ではネットワーク拡張が一括して引き受けるため、すべての App に効き、互換性の問題も最も少ない。Hysteria2 と TUIC は QUIC 上で動くので、UDP の転送経路の影響を受けやすい。回線の UDP 品質が悪いと、Web ページは開けるのに動画がカクつくというのが典型的な症状だ。これらは既定ではなく候補として扱うほうが安定する。

回線の種類について。IEPL 専用線は端から端まで専用のリンクで、夜のピーク時間でもジッターが小さい。中継は第三の拠点を経由して転送するためコストが低い代わりに経路が長い。直接接続の遅延はほぼ物理距離で決まる。どれを選ぶかは名前ではなく、目的のサービスがどの地域にあるかで決める。目的がアメリカ西海岸ならロサンゼルス方面の出口、日本なら東京を選ぶ。トンネル内の暗号化は方式を問わず共通で、プロトコル間の違いは暗号強度ではなく転送方式にある。

分割ルールは一度きちんと調整する価値がある。macOS のクライアントは通常、ドメインのサフィックス、IP レンジ、プロセス名の 3 通りで振り分けを判断できる。中国本土のサイトと LAN は直接接続にし、必要なドメインだけをトンネルに通せば、帯域の節約にも DNS の遠回りの削減にもなる。ルールの書き間違いは、接続はできているのに特定のサイトだけ開けない原因の第 1 位だ。

接続できているのに通信できない:切り分けチェックリスト

クライアントが接続済みと表示していても、トラフィックが本当にトンネルに入っているとは限らない。次の順番で確認すれば、多くの問題は 2 分以内に特定できる。

• ❌ システム拡張のスイッチが入っておらず、utun インターフェースができていない。「接続済み」は画面の表示だけの状態。
• ❌ 分割ルールが目的のドメインを直接接続と判定している。クライアントのログでルールのヒット記録を見る。
• ❌ DNS がルーターやプロバイダを向いたまま。トンネルはできているのに名前解決が外で行われ、一部のサイトが開かない。
• ✅ 別の回線に替えて再テストする。同じ地域で IEPL 専用線と中継をそれぞれ試せば、回線側の問題かローカル設定の問題かを切り分けられる。
• ✅ iCloud プライベートリレーや他の VPN 構成が同時に有効になっていないか確認する。2 つのトンネルは同じデフォルトルートを取り合う。
• ✅ サブスクリプション URL を読み込み直し、ローカルのサーバー一覧が古い可能性を除外する。

# 1. 現在有効な DNS サーバー
scutil --dns | grep 'nameserver\[[0-9]\]'

# 2. デフォルトルートがトンネルインターフェースにあるか
route -n get default | grep interface

1 つ目のコマンドは、システムが現在使っている DNS を一覧表示する。最初の nameserver がルーターのアドレスやプロバイダのアドレスなら、名前解決はトンネルに入っていない。2 つ目のコマンドの出力で interface が utun で始まっていれば、デフォルトルートは引き受けられている。en0 のままなら、トラフィックはトンネルをまったく通っていない。

結論:実行できる選定手順

VPNEH の macOS クライアントはシステム拡張 + ネットワーク拡張の経路を使い、プロトコルは Shadowsocks、VMess、VLESS、Trojan、Hysteria2、TUIC に対応する。回線は IEPL 専用線、中継、直接接続の 3 種類で、合計 90+ の国・地域 / 190+ の回線を用意している。登録はユーザー名とパスワードだけで、メールアドレスは不要。同じアカウントで台数の制限はなく、Mac とスマートフォンを同時にオンラインにできる。初回のお支払いから 14 日以内なら、理由を問わず全額返金を申請できる。