macOS VPN 完全ガイド：インストール・インポート・権限設定

macOS VPNの設定は、サブスクリプションURLをクライアントに貼り付けるだけでは完了しません。クライアントの入手元の確認、ネットワーク拡張の許可、システムプロキシと仮想ネットワークインターフェースの違いの理解、サブスクリプションのインポートと更新、適切なノードの選択、DNSとルーティングの動作確認までが必要です。一部だけ設定すると、「接続済みなのにブラウザーでアクセスできない」「一部のアプリだけローカルネットワークを使い続ける」といった問題が起こりがちです。

この記事では、特定のクライアント名に依存しない設定方法を説明します。クライアントによってボタンの位置は異なりますが、基本的な流れは共通しています。まずプロセッサーのアーキテクチャとクライアントの互換性を確認し、システムの許可を完了します。次にサービス提供元のサブスクリプションをインポートし、最後にアドレス、DNS、ルーティング、アプリの動作を確認します。異常が起きたときは、削除と再インストールを繰り返すのではなく、データの経路に沿って段階的に調べましょう。

インストール前にクライアントの種類と動作モードを確認する

macOSのプロキシクライアントは、大きくシステムプロキシ型と仮想ネットワークインターフェース型に分けられます。システムプロキシ型はmacOSのプロキシ設定を変更し、システムプロキシに従うブラウザーやアプリからのリクエストをローカルクライアントに渡します。仮想ネットワークインターフェース型は通常、システムのネットワーク拡張を使ってより多くの通信を取り込み、ルールに応じてプロキシまたは直接接続に振り分けます。両方のモードに対応するクライアントも多い一方、必要な権限、互換性、トラブルシューティングの方法は異なります。

Web閲覧だけを扱う場合は、システムプロキシモードのほうが動作を確認しやすいでしょう。クライアントのプロキシをオフにすると、システムのプロキシ設定も元に戻るはずです。オンにすると、システムプロキシに対応するアプリがルール判定の対象になります。システムプロキシを読み取らないアプリ、一部のコマンドラインプログラム、より複雑なDNS経路まで処理したい場合は、仮想ネットワークインターフェースモードを検討できます。ただし、このモードが本質的に高速という意味ではありません。対象となる通信範囲が広く、ネットワーク拡張の権限やルーティング設定への依存が大きいという特徴があります。

プロセッサーのアーキテクチャと入手元を確認する

クライアントをダウンロードする前に、「このMacについて」でチップ情報を確認し、端末のアーキテクチャに合ったバージョンを選びます。ユニバーサルビルドは複数のアーキテクチャに対応できますが、個別に提供されているビルドは端末に合わせてください。クライアントはプロジェクトの公式リリースページ、サービス提供元の管理画面にあるリンク、またはシステムのアプリストアから入手し、出所の不明な再パッケージ版は避けましょう。

Webからダウンロードしたアプリを初めて開くと、macOSから開発元の確認を求められることがあります。システムが明確にブロックした場合は、まずダウンロード元と署名情報を確認し、システムのセキュリティチェックを恒久的に無効化することをインストール手順にしないでください。クライアントによっては初回起動時に補助コンポーネントをインストールし、システムプロキシの書き込み、ネットワーク拡張の作成、設定の保存を行います。このとき求められるMacの管理者資格情報はローカルの許可手続きに使うもので、サブスクリプションサービスのログインパスワードではありません。

主要プロトコルとクライアントの互換性を理解する

サブスクリプションには、Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどのプロトコルが含まれる場合があります。プロトコル名はクライアントとリモートノードの間でセッションを確立する方法を示すもので、回線品質を意味するものではありません。ノードを解析して接続を開始するには、クライアントが該当プロトコルを実装している必要があります。サブスクリプションのテキストをインポートできても、含まれるすべてのノードに対応しているとは限りません。

サブスクリプションは更新できるのに、特定の種類のノードだけ起動できない場合は、まずクライアントのコアがそのプロトコルと通信方式の組み合わせに対応しているか確認します。現在のネットワークでHysteria2またはTUICだけが失敗し、ほかのプロトコルは接続できるなら、ローカルルーター、公衆ネットワーク、または上位ネットワークがUDPを制限している可能性があります。サブスクリプション全体が無効だとすぐに判断しないでください。

macOSのネットワーク拡張とプロキシの権限を許可する

クライアントで初めて仮想ネットワークインターフェースを有効にすると、macOSにVPN構成の追加やネットワーク拡張の許可を求めるシステムダイアログが表示されることがあります。確認する前に、要求元のアプリ名を確認してください。許可すると、システム設定のネットワークまたはVPN関連の項目に対応する構成が表示されます。クライアント終了後も構成を残すかどうかは実装によって異なりますが、構成が存在するだけで通信中とは限りません。クライアントの状態と実際の接続結果を基準に判断しましょう。

許可ダイアログを閉じたり拒否したりすると、クライアントが起動中のまま進まない、またはインターフェースを作成できないと表示されることがあります。まずクライアントを終了し、システム設定の「プライバシーとセキュリティ」「ネットワーク」「VPN」またはフィルター関連の項目で、許可待ちの項目がないか確認します。システム設定内の名称はmacOSのバージョンやクライアントの実装によって変わるため、アプリ名、ネットワーク拡張の状態、対応するスイッチを確認することが重要です。特定のメニュー名を機械的に探す必要はありません。

システムプロキシモードで確認すること

システムプロキシを有効にした後は、macOSのネットワーク設定で現在のネットワークサービスのプロキシ状態を確認できます。クライアントは通常、プロキシアドレスをローカルループバックアドレスに設定し、クライアントが待ち受けるローカルポートを使います。このポートをリモートサーバーのポートに手動で変更しないでください。ローカルポートは、アプリからのリクエストを起動中のクライアントへ先に渡すためのものです。

クライアント終了後にWebページが突然開けなくなった場合は、システムプロキシが正しく復元されていない可能性があります。クライアントを再起動し、システムプロキシのスイッチを通常の手順でオフにするほうが、ネットワークサービスを直接削除するより安全です。システム設定でHTTP、HTTPS、SOCKSプロキシが、すでに待ち受けを停止したローカルアドレスを指していないか確認することもできます。残ったプロキシ設定を消去してから、クライアントを経由しない基本ネットワークをテストしてください。

仮想ネットワークインターフェースモードで確認すること

仮想ネットワークインターフェースモードでは、ネットワーク拡張が管理する論理インターフェースを作成し、条件に合う通信をクライアントへ送ります。有効にする際は、デフォルトルート、DNS、ネットワークフィルタールールを変更するほかのツールを同時に動かさないでください。複数のネットワーク拡張が同じデータ経路を奪い合う可能性があります。接続がループする、ネットワークが何度も切り替わる、スリープ復帰後に使えないといった場合は、まず現在のクライアントだけを残して接続を再確立します。

サブスクリプションURLをインポートして更新結果を確認する

サブスクリプションURLは通常、サービスの管理画面で発行され、クライアントがそのURLからノード、プロトコルパラメーター、グループ情報を取得します。インポートにはクライアントの「URLからインポート」「サブスクリプションを追加」などの項目を使い、URL全体を単一のサーバーアドレスとして入力しないでください。クリップボードから認識できるクライアントでも、認識後にサブスクリプション名とノード一覧が正しく表示されるか確認します。

サブスクリプションURLをコピーするときは、前後の空白、改行、チャットアプリが追加したエスケープ文字が混入しないよう注意します。ブラウザーでエンコードされたテキストが表示されても、サブスクリプションに問題があるとは限りません。多くのサブスクリプションは人が読むWebページではなく、クライアントが解析するデータとして提供されています。ブラウザーがログインページやエラーページへ移動する場合は、URLが不完全、資格情報が失効、または現在のネットワークによってリクエストが書き換えられている可能性があります。

インポート後はすぐ接続せず、まず設定を確認する

• サブスクリプション名がサービス管理画面の項目と一致しているか確認する。
• ノード一覧が空ではなく、地域名とプロトコルの種類が表示されることを確認する。
• クライアントが未対応のフィールドやプロトコルを報告していないか確認する。
• 手動更新を一度実行し、認証エラーや解析エラーが発生していないことを確認する。
• 自動更新によって、自分で管理しているローカルのルーティングルールが上書きされないことを確認する。

サブスクリプションの更新では、サービス側が管理するノード情報が置き換えられます。クライアントでサブスクリプション内のノードを編集できる場合でも、手動変更は次回更新時に失われる可能性があります。独自のルールが必要なときは、クライアントが提供するローカル上書き、ルールセット、設定統合機能を使い、サービス側のノードとローカルポリシーを分けて管理するのが適切です。

サブスクリプションURLは資格情報として扱ってください。公開すると設定を第三者に取得されたり、サービス側のセキュリティ対応が発動したりする可能性があります。別のMacで使う場合は、自分のサービス管理画面から再度コピーし、公開短縮URLやオンライン変換ツールを経由しないでください。古いクライアントの使用をやめる前に、保存されているサブスクリプションとキャッシュ設定を削除しておくのもよいでしょう。

ノードの選び方：地域は出発点、重要なのは経路

インポートに成功したら、まず目的のサービス地域に近く、経路を把握しやすいノードでテストします。ノード名の国名や都市名は通常、出口の場所を示しますが、ローカルから出口までの完全な経路を単独で判断できるものではありません。実際の使用感は、ローカル通信事業者のネットワーク、入口の場所、中継方式、出口の混雑、目的サイトのルーティングにも左右されます。

直通回線は、クライアントが比較的直接リモートノードへ接続するため経路が単純ですが、国際区間の品質は公衆ネットワークに大きく依存します。中継回線は近い入口に接続してから、中継ネットワークを通じて出口へ送る方式で、一部のネットワーク環境における経路の安定性を改善することを目的とします。IEPL専用線は通常、国際通信を専用の経路で運び、一般的な公衆ネットワークの直通接続とは異なるルーティングを行います。ただし、どのアプリもどのネットワークでも必ず高速になるわけではなく、現在の接続環境と目的地域を組み合わせて確認する必要があります。

回線を選ぶときは、クライアントに表示される遅延ラベルだけを見ないでください。遅延テストが測定しているのは、入口、プロキシのハンドシェイク、特定の探測アドレスなどであり、実際のWebサイトとのTLSセッション確立、リソースのダウンロード、継続的な通信とは異なる場合があります。より確実なのは、同じ地域の異なる回線を選び、目的サイトを開いてログインし、一定時間連続して操作して比較する方法です。安定して動作する回線を残しましょう。

ルーティングルールを設定し、すべての通信を同じ経路に送らない

ルーティングルールは、特定のドメイン、アドレス、アプリからのリクエストをプロキシ、直接接続、拒否のどれにするか決めます。macOSの日常利用では、グローバルプロキシよりルールモードのほうが、ローカルサービスと海外サイトの互換性を保ちやすいことがあります。グローバルモードは短時間の診断に向いています。ルールモードではアクセスできず、グローバルモードではアクセスできるなら、原因はノードではなく、ルールの一致、DNS解決、ルールセットの更新にある可能性が高いでしょう。

ルール判定の基準には、ドメインのサフィックス、完全修飾ドメイン名、宛先アドレスの範囲、プロセス情報などがあります。ドメインルールは読みやすい一方、クライアントがドメイン名を取得できることが前提です。リクエストが早い段階でアドレスに解決されると、その後はアドレスルールでしか処理できないことがあります。プロセスルールはクライアントの権限と実装に依存し、すべてのシステムプロキシ型クライアントが各アプリを安定して識別できるとは限りません。

設定時は、まずサブスクリプションに付属するクライアントの既定ルールを使い、基本接続が正常になってからローカル上書きを追加します。最初から出所不明の大規模なルールセットを複数導入すると、重複、優先順位の衝突、期限切れドメインによって調査が難しくなります。社内ネットワーク、ローカルプリンター、LAN機器を直接接続にしたい場合は、ローカルアドレスと内部ドメインの直接接続経路を明示的に残してください。

システムプロキシとコマンドラインアプリの違い

ブラウザーは通常システムプロキシに従いますが、ターミナルのコマンドラインツールは独自の環境変数や設定ファイルを参照したり、完全に直接接続したりすることがあります。そのため、ブラウザーでアクセスできても、ターミナルの通信がクライアントを経由しているとは限りません。クライアントがローカルHTTPまたはSOCKSの待ち受けアドレスを提供している場合は、各ツールのドキュメントに従ってプロキシ環境を設定します。テスト専用の環境変数は終了後に消去し、クライアント終了後もコマンドが無効なポートを参照し続けないようにしてください。

一部のデスクトップアプリは独自のネットワークスタックを実装しており、システムプロキシを無視することがあります。このようなアプリでは、ブラウザー設定を何度も変更するのではなく、まず仮想ネットワークインターフェースモードを試します。モード切り替え後に復旧したなら、ノードとサブスクリプションはおそらく利用可能で、違いはアプリがシステムプロキシに従うかどうかにあります。

DNS経路と考えられるDNSリークを確認する

DNSはドメイン名をアドレスに変換します。クライアントが接続済みでも、ドメイン名が適切でないローカルリゾルバーによって処理されていると、出口地域と一致しない解決結果になる、ドメインを解決できない、ルーティングルールが正しいドメイン情報を取得できないといった問題が起こります。DNSリークとは通常、本来プロキシポリシーで処理すべきクエリがローカルネットワーク指定のリゾルバーへ送信され、想定と異なるDNS経路になる状態を指します。

システムプロキシモードでDNSをプロキシに処理させるかどうかは、クライアントの実装、ブラウザーの設定、プロトコルの機能によって異なります。仮想ネットワークインターフェースモードはDNSを一元的に取り込みやすい一方、macOSの暗号化DNS、企業ネットワークの設定、ほかのフィルター拡張と競合することもあります。調査時は追加のDNS変更ツールを一時的に停止し、クライアントの既定設定だけを残して、ドメイン解決が戻るか確認してください。

目的サイトが地域によって異なるアドレスを返す場合、DNSの出口とプロキシの出口が一致しないと接続結果に影響することがあります。クライアントでリモートDNS、ルールDNS、仮想アドレスマッピングなどが有効になっていないか確認してください。仮想アドレスモードではドメインに内部マッピングアドレスを割り当て、クライアントがドメインを復元してルールを実行します。このアドレスを実際のリモートアドレスとして長期設定に保存しないでください。

接続後の確認手順を完了する

クライアントに「接続済み」と表示されても、ローカルコンポーネントとリモートセッションが確立した可能性を示すだけで、エンドツーエンドの確認にはなりません。基本ネットワーク、出口の変化、目的サービス、DNS、スリープ復帰を確認する必要があります。一度に変更する変数を1つにすれば、原因がノード、プロトコル、ルール、本体の権限のどこにあるか判断できます。

• クライアントをオフにした状態で、普段使うサイトにローカルネットワークから正常にアクセスできることを確認する。
• クライアントを起動し、目的のWebサイトで接続を確立してリソースをすべて読み込めるか確認する。
• 同じ地域の別の回線に切り替え、特定ノードの異常かどうか比較する。
• ルールモードとグローバルモードをそれぞれテストし、ルーティングが障害に関係しているか判断する。
• ブラウザーをいったん終了して再起動し、古い接続やDNSキャッシュの影響を除外する。
• Macを一度スリープさせて復帰し、ネットワーク拡張がセッションを再確立できることを確認する。

Webサイトのトップページは開けるのに、ログイン、画像、動画などのリソースが失敗する場合は、それらが別のドメインから配信されていないか確認します。メインドメインはプロキシルールに一致していても、静的リソースのドメインが誤って直接接続になっている可能性があります。ドメインルールを追加するかルールセットを更新し、トップページが開けるだけで設定全体が正常だと判断しないでください。

ノードを切り替えても目的サイトに以前の地域結果が残る場合は、ブラウザーのセッション、サイトキャッシュ、アカウントの地域設定、既存の接続が影響している可能性があります。まずプライベートウィンドウで比較し、その後にサイトデータを消去するか判断します。地域コンテンツは出口アドレスだけで決まるわけではないため、出口が変わってもサービス側のアカウント設定がすぐ変わるとは限りません。

よくあるトラブル：データ経路に沿って段階的に対処する

クライアントが開かない、またはシステムにブロックされる

まずアプリの入手元、端末のアーキテクチャ、システムの互換性要件を確認します。アプリファイルが破損している場合は、元のリリースページから再度ダウンロードしてください。開発元や署名に関する警告が表示された場合は、入手元を確認したうえで、システムが案内するセキュリティ設定に従って対処します。出所を確認できないインストーラーを回避するために、システムチェックを恒久的に無効にしないでください。

サブスクリプションのインポートは成功したのにノード一覧が空

まず手動更新を実行し、エラーメッセージを確認します。認証に失敗する場合は、サービス管理画面からサブスクリプションURLを再取得します。解析に失敗する原因として、クライアントが古い、サブスクリプション形式に対応していない、URLのコピーが不完全などが考えられます。ブラウザーでURLを開いたときにログインページが表示される場合は、コピーしたのがサブスクリプションの入口なのか、管理画面のページURLなのかも確認してください。

接続をクリックしても起動中のまま進まない

システムプロキシモードでは、ローカルの待ち受けポートがほかのプログラムに使用されていないか確認します。仮想ネットワークインターフェースモードでは、ネットワーク拡張の権限と既存のVPN構成を確認してください。その後、サブスクリプション内の別のプロトコルの回線を試します。UDPに依存するプロトコルだけが失敗する場合は、現在のネットワークによるUDP制限を検討し、別のプロトコルと比較してください。

接続後、すべてのWebサイトにアクセスできない

まずクライアントを閉じて基本ネットワークが復旧することを確認し、システムプロキシが残っていないか調べます。再接続後はグローバルモードでテストします。グローバルモードも失敗する場合は、ノード、プロトコル、システム時刻、ネットワーク拡張を重点的に確認します。グローバルモードは使えるのにルールモードが失敗する場合は、ルールとDNSを確認してください。クライアントの再インストール、サブスクリプションの交換、DNS変更を同時に行うと比較条件を失うため、避けましょう。

一部のアプリがプロキシを経由しない

そのアプリがシステムプロキシに従うか確認します。従わない場合は、仮想ネットワークインターフェースモード、またはアプリ自身が対応するプロキシ設定を試します。企業管理端末では、組織が配布したネットワークフィルターやVPNポリシーが存在することもあります。このような設定は一般ユーザーが上書きできないことが多いため、許可されている接続方法を端末の管理者に確認してください。

スリープ復帰後に接続が戻らない

まずクライアント内で切断してから再接続し、すぐに強制終了しないでください。問題が繰り返し発生する場合は、複数のネットワーク拡張を同時に有効にしていないか確認し、クライアントを公式提供の安定版へ更新します。Wi-Fiから別の接続方式へ切り替えたときは、既存のセッションやルートが無効になり、クライアントが接続を再作成する必要がある場合があります。

最終確認：保守しやすい設定に整える

インストール後は、大量のルールを積み重ねるより、シンプルで再現可能な設定を1つ維持することが重要です。クライアントはサブスクリプションの受信とポリシーの実行を担い、サブスクリプションはノードパラメーターを配布し、ローカルルールは端末固有の例外を処理します。この3つを分けて管理すれば、更新時に互いを上書きしにくくなります。問題が起きても、クライアント、サービス設定、ローカルネットワークのどこを調べるべきか明確になります。

日常利用では、定期的にサブスクリプションを手動更新して結果を確認できますが、設定を頻繁に削除する必要はありません。クライアントのアップグレード後に異常が起きたら、まずネットワーク拡張の許可が維持されているか確認し、次に設定の移行とプロトコルコアの変更を調べます。公衆ネットワークへ切り替えるときは、まず普段使うサイトで基本ネットワークを確認してからクライアントを有効にすると、接続環境の障害とプロキシ設定の障害を切り分けやすくなります。