macOSでネットワーククライアントをゼロから設定する際、アプリを「アプリケーション」フォルダへ移すだけでは十分ではありません。インストール元、プロセッサーのアーキテクチャ、システム拡張機能、VPN構成、サブスクリプションの取り込み、プロキシモード、DNS経路のいずれも最終的な動作に影響します。メニューバーに「接続済み」と表示されても、クライアントが何らかの接続処理を完了したことを示すだけで、ブラウザやターミナル、その他のアプリの通信が想定した経路を通っているとは限りません。
安全な手順は、まずインストーラーと端末が適合しているか確認し、次に権限ダイアログの内容を理解してから、サブスクリプションを取り込み、適切なトラフィック処理モードを選び、最後に出口IP、DNS、ルーティング結果を個別に確認することです。異常が起きた場合も同じ経路を逆順に調べ、クライアントの再インストールやノードの頻繁な切り替えを繰り返さないようにしましょう。
クライアント、アーキテクチャ、入手元を確認する
macOSのクライアントは通常、ディスクイメージ、インストーラーパッケージ、圧縮アーカイブのいずれかで提供されます。ディスクイメージではアプリのアイコンを「アプリケーション」へドラッグし、インストーラーパッケージではシステムのインストール手順を進め、圧縮アーカイブでは先に解凍してからアプリを移動します。形式にかかわらず、ファイルはサービスの管理画面、プロジェクトの公式リリースページ、またはクライアント内蔵の更新機能から入手してください。
MacにはAppleシリコン搭載機とIntelプロセッサー搭載機があります。配布ページにアーキテクチャ別のファイルがある場合は、本体に合ったビルドをダウンロードします。Universalと記載されたビルドには通常、対応する両方のアーキテクチャが含まれます。適合しない場合、アプリが起動しなかったり、互換変換レイヤーを介して動作したりすることがあります。「このMacについて」でチップまたはプロセッサー情報を確認し、ダウンロードページの表記と照合しましょう。
| 確認項目 | 確認する内容 | 不一致の場合の症状 |
|---|---|---|
| ファイルの入手元 | サービス管理画面、クライアント公式リリースページ、アプリ内の更新入口 | 開発元を確認できない、またはアプリの挙動が公式説明と一致しない |
| プロセッサーのアーキテクチャ | Appleシリコン、Intel、またはUniversalの表記 | アプリが起動しない、予期せず終了する、追加の互換環境を求められる |
| インストール形式 | ディスクイメージ、インストーラーパッケージ、圧縮アーカイブに対応するインストール方法 | アプリがダウンロードフォルダから起動したままで、更新や権限の状態が混乱しやすい |
| システム互換性 | リリースノートに記載された最低システム要件と既知の制限 | ネットワーク拡張機能を読み込めず、設定画面がガイドの説明と異なる |
macOSが開発元を確認できないアプリを明確にブロックした場合、システムのセキュリティ機能を無効にして回避することはおすすめしません。まずダウンロード先、開発元情報、リリースノートを確認してください。入手元を確認できない場合は、信頼できる入口から再度ダウンロードします。システムの「開く」による確認は、既知の開発元によるアプリの初回起動に適した手段であり、すべての警告に対する一般的な解決策ではありません。
- ✅ インストーラーは確認可能な公式入口から入手し、ファイル名もリリースノートと一致している。
- ✅ アーキテクチャの表記が本体のチップ種別と一致している、またはUniversalビルドであることが明記されている。
- ✅ アプリを「アプリケーション」へ移動し、ディスクイメージやダウンロードフォルダから常用していない。
- ❌ 一度きりの警告を回避するために、Gatekeeperやシステム整合性保護を全面的に無効化しない。
- ❌ 入手元が不明で名前の似たクライアントのコピーを複数残さない。
システム拡張機能とネットワーク権限のダイアログを理解する
クライアントが初めてシステムプロキシ、TUN、VPNによる通信処理を有効にすると、macOSは管理者の認証を求めることがあります。「VPN構成を追加」「ネットワーク拡張機能を許可」やフィルタリングに関する通知が表示される場合もあります。ダイアログ名はシステムバージョンやクライアントの実装によって異なりますが、目的はほぼ同じで、アプリがシステム管理下のネットワーク経路を作成することを許可するものです。
「VPN構成を追加」しても、アプリがすべての個人ファイルを読み取るという意味ではありません。クライアントがシステムに認められたネットワーク構成を作成し、条件に合う通信を対応するネットワーク拡張機能へ送れるようにします。管理者認証は、このシステムレベルの変更を承認するために使われます。その後、「システム設定」のネットワーク、VPN、フィルタリング関連の項目で状態を確認したり、クライアントから構成を削除したりできます。
TUNの実装にNetwork Extensionフレームワークを使うクライアントもあれば、主にシステムプロキシを変更するクライアントもあります。両方を切り替えられるものもあります。システムから拡張機能がブロックされたと通知されたら、まずクライアントを開いたまま「プライバシーとセキュリティ」で承認待ちの項目を確認します。承認後は通常、クライアントに戻って接続を再度有効にします。アプリが再起動を明示的に求めた場合のみ、指示に従って操作してください。
システムプロキシとTUNの違い
システムプロキシはmacOSのHTTP、HTTPS、SOCKSプロキシ設定を書き換えます。システムプロキシに従うブラウザやアプリはリクエストをクライアントへ渡しますが、独自のネットワークスタックを使うアプリ、システムプロキシを無視するアプリ、特殊な通信方式を使うアプリは迂回することがあります。この方式は変更範囲が比較的小さく、まずWebアクセスと基本的なルーティングを確認したい場合に適しています。
TUNモードでは仮想ネットワークインターフェースを作成し、クライアントがより広い範囲のIP通信を受け取り、ルールに応じてプロキシ、直接接続、遮断を判断します。ターミナルツールや開発環境、システムプロキシを参照しないアプリまで対象にしたい場合に適していますが、他のVPN、フィルター、セキュリティソフト、企業向けネットワーク拡張機能とは競合しやすくなります。
| 通信処理方式 | 主な対象範囲 | よくある制限 | 適した切り分け場面 |
|---|---|---|---|
| システムプロキシ | macOSのプロキシ設定を参照するアプリ | 一部のターミナルプログラムや独自ネットワークスタックは従わないことがある | まずブラウザと基本ルールが正常か確認する |
| TUN | 仮想インターフェースに入り、ルールで処理される通信 | 他のネットワーク拡張機能やフィルターと競合することがある | ブラウザは正常だが、他のアプリで反映されない |
| 手動プロキシ | プロキシアドレスを個別に入力する指定アプリ | 設定が分散し、アプリごとに状態が一致しない | 特定アプリのプロキシ対応を切り分けて確認する |
サブスクリプションを取り込み、プロトコルと接続先の項目を確認する
権限設定が終わったら、サービス管理画面からサブスクリプションURLをコピーし、クライアントの「サブスクリプション」「設定」「リモート設定」「Profiles」などの入口から取り込みます。クライアントによってボタン名は異なりますが、基本操作はリモートURLを保存し、設定をダウンロードして接続先を解析することです。クリップボードから取り込める場合は、完全なURLだけが入っていることを確認してください。前後の空白や改行、チャットアプリが付けた句読点も取り除きます。
取り込みに成功したら、まず一度更新して、接続先、プロキシグループ、ルールが表示されるか確認します。サブスクリプション名だけ表示され、選択できる接続先がない場合は、ダウンロード失敗、形式の非互換、リモート内容の解析失敗が考えられます。クライアントのログでHTTPステータス、解析エラー、設定項目に関する通知を確認し、同じURLを繰り返し貼り付けないでください。
- アカウント管理画面から現在有効なサブスクリプションURLをコピーし、公開ページで開いたり転送したりしない。
- クライアントのサブスクリプションまたはリモート設定を開き、URLを貼り付けて保存する。
- 設定を手動で更新し、接続先、プロキシグループ、ルーティングルールの読み込み完了を待つ。
- 現在の用途に合うプロキシグループを選び、具体的な出口接続先を指定する。
- システムプロキシまたはTUNを有効にし、メニューバーの状態とシステム設定のネットワーク構成が一致することを確認する。
- 出口IP、DNS、アプリごとの動作を確認してから、自動更新やログイン時の起動を有効にする。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC
これらは異なるプロキシプロトコルまたは通信方式を示す名称であり、接続品質のランクではありません。Shadowsocksは暗号化プロキシとして通信を転送し、通常はサーバー、ポート、暗号化方式、認証情報を設定します。VMessとVLESSは互換コアで処理されることが多く、異なるトランスポートやTLS設定を組み合わせられます。Trojanは通常、TLSに見せかけた形でプロキシ接続を運びます。Hysteria2とTUICはQUIC系の通信設計を採用しており、クライアントコアとネットワーク環境にそれぞれ要件があります。
プロトコル名だけを見て、サブスクリプション内のポート、トランスポート層、安全設定、サーバー名を手動で書き換えないでください。利用できるかどうかは、クライアントコアが必要な項目を完全にサポートしているか、またサーバー側の設定と一致しているかで決まります。サブスクリプション形式に対応していても、含まれるすべてのプロトコルに対応しているとは限りません。取り込み後に「不明な種類」や項目の解析失敗が表示された場合は、該当プロトコルに対応するクライアントのビルドへ変更するか、サービスが提供する互換形式のサブスクリプションを使用してください。
直接接続、中継、IEPL専用線
直接接続はクライアントから接続先の入口へ直接つなぐ方式で、経路はシンプルですが、品質は利用中の通信事業者から入口までの相互接続状況に左右されます。中継回線ではまず中継接続先に入り、そこから出口へ転送します。サービス側はこれによって一部の経路を調整できます。IEPL専用線は国際接続向けの専用アクセス形態で、経路の制御と出口の処理は引き続きサーバー側で行われます。
macOSクライアントでは、こうした違いは通常すでに接続先設定へ反映されています。クライアントは指定された入口へ接続するだけで、TUNを有効にしたからといって通常の直接接続が専用線に変わるわけではありません。接続先を選ぶ際は、サブスクリプションの表記、対象地域、実際の用途を基準にし、プロトコル名から直接接続、中継、IEPLかどうかを推測しないでください。
グローバル、ルール、直接接続モードを選ぶ
一般的なクライアントには、グローバル、ルール、直接接続の各モードがあります。グローバルモードは、クライアントが処理している通信を一括してプロキシ設定へ渡すため、ルールのマッチングを短時間切り分けたい場合に適しています。ルールモードは、ドメイン、IP、プロセス、ルールセットに応じてプロキシと直接接続を決める、日常利用で一般的な方式です。直接接続モードでは、処理対象になった通信もそのまま接続し、ローカルネットワークの復旧や異常がプロキシ経路に起因するかの確認に使います。
「グローバル」は、クライアントが処理対象にした通信の扱い方を示すだけで、端末上のすべての接続がクライアントを通るとは限りません。システムプロキシだけを有効にしている場合、システムプロキシを参照しないアプリは迂回することがあります。一方、TUNで通信を処理していても、ルールモードならローカルサイト、LAN上のリソース、指定アプリを直接接続にできます。
ルーティングルールではマッチング順序に注意します。具体的なドメインルールを広範なルールより先に適用し、最後のフォールバックルールで前の条件に一致しなかったリクエストを処理します。同じドメインが複数のルールセットに含まれる場合、通常は設定順に最初に一致した結果が採用されます。ルールを変更したら設定を再読み込みし、アプリ内の既存接続も切断して、古い経路が使われ続けないようにしてください。
- ✅ ブラウザで対象サービスへアクセスした際に想定したプロキシグループが選ばれ、ログにも該当ルールが表示される。
- ✅ ローカルサイトとLAN上のリソースはルールどおり直接接続され、不要に遠隔へ送られていない。
- ✅ 現在の通信処理モードで、ターミナルツールにもブラウザと一致する、または説明可能な結果が返る。
- ❌ 「グローバルモード」ならすべてのプロセスが必ず処理対象になると考えない。
- ❌ 複数のクライアントにシステムプロキシの変更や重複するTUNインターフェースの作成を同時に行わせない。
出口IP、DNS、アプリごとの結果を確認する
接続確認はネットワーク層からアプリ層へ進めます。まず出口IPが選択した地域に切り替わったかを確認し、次にDNSリクエストの処理元を調べ、最後にブラウザ、ターミナル、実際に使うアプリを個別に開きます。これにより、「トンネルが確立していない」「一部のアプリだけが処理対象になっている」「DNS経路が一致していない」「対象サービス側の制限」といった問題を切り分けられます。
出口IPを確認する
接続前後に、信頼できるIP確認ページで公開出口を確認します。結果が選択した接続先の地域と一致することを確認し、ブラウザキャッシュ、古いタブ、既存の長時間接続の影響も除外します。元のページを閉じて開き直すか、新しいプライベートブラウジングウィンドウでリクエストを送ってください。クライアントのログでは接続成功になっているのに出口が変わらない場合は、まずシステムプロキシまたはTUNが実際に有効かを確認し、次にブラウザが独自プロキシやセキュアDNSを設定していないか調べます。
DNSリークと名前解決経路を確認する
DNSリークとは通常、通信本体はプロキシを通っているのに、ドメイン検索だけが想定外のローカルリゾルバーへ送られ、名前解決経路と出口経路が分離する状態を指します。システムプロキシモードでは、アプリがシステムDNSを使い続けることがあります。TUNモードでは、クライアントがより多くのDNS通信を処理できますが、実際に処理されるかは設定、ルール、アプリ独自の暗号化DNS設定によって異なります。
確認時は、リゾルバー名だけを見ないでください。リクエストがクライアントのDNSルールに一致しているか、名前解決結果が改変されていないか、プロキシ用ドメインがトンネル確立前に正しく解決されているかも確認します。ブラウザ内蔵のセキュアDNS、企業ネットワーク設定、他のネットワークフィルターも結果を変えることがあります。不一致が見つかったら、まず重複するDNS処理元を無効にし、クライアントのドキュメントに従ってシステム解決、リモート解決、ルールベースの解決方法を選びます。
scutil --proxy
scutil --dns
scutil --nwi
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"scutil --proxy で現在のシステムプロキシ状態を確認でき、scutil --dns ではシステムリゾルバーの設定を確認できます。scutil --nwi はネットワークインターフェース情報の確認に役立ちます。コマンド結果が示すのは現在のシステム設定だけで、特定のアプリが厳密に従っていることを単独で証明するものではありません。クライアントログと実際のリクエストも合わせて確認してください。
アプリごとに確認する
ブラウザで成功しても、ターミナル、開発ツール、デスクトップアプリが同じように動くとは限りません。ブラウザは通常システムプロキシに従いますが、独自のプロキシ拡張機能を使うこともあります。ターミナルのコマンドラインプログラムには環境変数を読むものもあれば、直接接続するものもあります。QUIC、自前のDNS、長時間接続を使うアプリも挙動が異なる場合があります。対象アプリ内で接続を再確立し、クライアントログに該当ドメイン、対象IP、適用ルールが記録されているか確認してください。
よくある権限エラーと確認手順
権限エラーは、残った拡張機能、複数のクライアント、システム状態の同期不良によって起きることがあります。最も効果的なのは、一度に一つの要因だけを処理することです。まず他のネットワーククライアントやフィルターツールを終了し、現在のアプリが「アプリケーション」フォルダにあることを確認します。次にシステム設定に古いVPN構成やネットワーク拡張機能が残っていないか調べます。複数のクライアントを同時に動かしたまま許可を何度もクリックすると、どのアプリのダイアログか判断しにくくなります。
承認後も認証を繰り返し求められる
アプリのコピー場所が変わった、旧バージョンの拡張機能が残っている、インストール完了に必要な管理者認証をクライアントが取得できていない場合によく起こります。まずアプリを完全に終了し、ディスクイメージから起動しているコピーを削除して、「アプリケーション」内の正式なコピーだけを残します。続いてシステム設定のVPNとフィルターの状態を確認し、旧クライアントに明らかに属し、すでに無効になっている構成を削除してから、現在のクライアントを開き直します。
システム設定では拡張機能が許可されているのに、クライアントが未読み込みと表示する場合は、該当機能をいったん無効にしてから再度有効にし、アプリに状態を再確認させます。システムの再起動は、クライアントのリリースノートで明示的に求められている場合だけ行ってください。アプリを削除するだけではネットワーク拡張機能やVPN構成が消えないことがあるため、クライアントのアンインストール機能または構成削除機能を使って整理します。
接続成功と表示されるのにWebページを開けない
まず直接接続モードへ切り替え、ローカルネットワーク自体が使えるか確認します。直接接続でも失敗する場合は、接続先を変え続けるのではなく、現在のWi-Fi、企業ネットワークの認証、システムDNSを確認します。直接接続は正常でプロキシだけ失敗する場合は、接続先とのハンドシェイク、サブスクリプションの有効性、プロトコルの互換性、DNSログを確認します。一部のドメインだけ失敗するなら、ルーティングルールと名前解決結果を調べ、回線全体が使えないと決めつけないでください。
ブラウザは使えるのにターミナルで反映されない
ブラウザはシステムプロキシを読み込む一方、ターミナルのプログラムは読み込んでいない可能性があります。クライアントが対応している場合はTUNモードを有効にして比較するか、コマンドラインツールのドキュメントに従ってプロキシ環境変数を設定します。TUNを有効にするとターミナルが使えるなら、問題は遠隔の接続先ではなく処理対象の範囲にあります。それでも改善しない場合は、そのツールが独自DNS、UDP、特殊なネットワークインターフェースを固定使用していないか確認します。
スリープ復帰後に接続が失われる
Macの復帰後は、ネットワークインターフェースが切り替わったり、アドレスを再取得したり、古い接続を復元したりすることがあります。まずクライアントを切断して再接続し、ルート、DNS、仮想インターフェースを再読み込みさせます。問題が続く場合は、クライアントに自動再接続の設定があるか確認し、復帰後に別のツールがシステムプロキシを上書きしていないか調べます。頻発する場合は、復帰前後のログを保存し、インターフェースとDNSの状態変化を比較してください。
- ✅ 他のVPN、プロキシクライアント、ネットワークフィルターツールを終了し、現在のクライアントだけを動かす。
- ✅ システム設定で、現在のVPN構成とネットワーク拡張機能がクライアント名と対応していることを確認する。
- ✅ サブスクリプションを更新して解析ログを確認し、プロトコルに対応したクライアントへの変更が必要か判断する。
- ✅ 直接接続、システムプロキシ、TUNをそれぞれ比較し、問題が接続先か処理範囲かを特定する。
- ❌ アプリの再インストール、設定削除、接続先変更、DNS変更を同時に行わない。切り分けの手がかりが失われます。
- ❌ ハンドシェイク失敗、DNS失敗、ルールの誤マッチをすべて「クライアントの故障」と決めつけない。
安定運用前の最終チェック
設定が正常だと確認してから、ログイン時の起動、サブスクリプションの自動更新、ネットワーク変更後の自動再接続を有効にするか決めます。自動化機能は検証済みの設定を前提にしてください。そうでないと、システム起動時に誤ったルールや無効な拡張機能が繰り返し読み込まれます。サブスクリプションの更新で接続先名やプロキシグループの内容が変わることもあるため、更新後は既存のグループが想定した接続先を指しているか確認します。
必要なトラブル記録を残すと、後から原因を特定しやすくなります。クライアントのバージョン、macOSのバージョン、通信処理モード、選択したプロキシ設定、エラー発生時刻、個人情報を伏せたログの一部などを記録してください。ログに含まれるサブスクリプションURL、認証情報、サーバー資格情報、個人用パスは提出前に削除します。問題を説明する際は、「どのアプリで、どのモードを使い、どの手順で失敗したか」を明記すると、「接続できない」だけの場合より正確に判断できます。
端末が学校や企業の管理下にある場合、構成プロファイルによってVPN、プロキシ、ネットワーク拡張機能が制限されることがあります。この種の制限は通常、一般的な管理者認証では解除できないため、端末管理者のネットワークポリシーに従ってください。個人端末では、使用を停止したクライアントが残したプロキシ設定やネットワーク拡張機能を定期的に整理し、複数のネットワークコンポーネントが同じ経路を奪い合わないようにします。