まずv2rayNのローカル待ち受けポートを確認し、macOSで現在使用中のネットワークサービスのプロキシ設定を調べます。ブラウザは拡張機能の影響を切り分け、ターミナルはcurlと環境変数で個別に確認します。クライアントは接続済みなのにアプリによって動作が異なる場合に、原因を段階的に特定できます。
まず切り分ける：クライアント、システムプロキシ、アプリ
v2rayNでノードが選択されていても、すべてのアプリがそのノードを使うとは限りません。アプリからローカルのプロキシポートへリクエストを送ることで、v2rayNが後続の接続を処理します。macOSのシステムプロキシは、主にシステムのネットワーク設定に従うアプリに接続先を提供します。一方、ターミナルのコマンドラインツールは環境変数を参照したり、プロキシを明示的に指定したりする場合があります。
確認を始める前に、v2rayNでローカルHTTPおよびSOCKSの待ち受けアドレスを確認し、コアが起動していることを確かめてください。以下の数値は入力例であり、実際の環境で使われるポートとは限りません。以降のコマンドやシステム設定には、クライアントに現在表示されている値を使用してください。
まず障害の範囲を切り分ける
ブラウザとターミナルの両方で失敗する場合は、まずコアとローカルポートを確認します。ブラウザだけ失敗するならシステムプロキシと拡張機能、ターミナルだけ失敗するならコマンドがプロキシ設定を読み取っているかを確認してください。待ち受けポートを確認する前に、ノードを何度も切り替えるのは避けましょう。
macOSで現在使用中のネットワークサービスのプロキシ設定を確認する
まずv2rayNのシステムプロキシメニューで「システムプロキシを自動設定」が選択されていることを確認し、macOSで現在使用中のネットワークサービスに設定が反映されているか調べます。設定画面の場所はmacOSのバージョンやWi-Fi・Ethernetの接続方法によって異なります。新しいバージョンでは通常、「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」から確認できます。
コアの動作を確認する
v2rayNのメイン画面の状態とログを確認します。コアが起動していない場合、システムにプロキシアドレスが設定されていてもローカルポートには接続できません。
待ち受けポートを確認する
v2rayNの「設定」→「パラメーター設定」でローカルプロキシポートを確認し、現在の画面とログに表示された待ち受け情報を基準にしてください。HTTPポートとSOCKSポートを区別し、取り違えないようにしましょう。
システムプロキシを選択する
v2rayNのシステムプロキシメニューで「システムプロキシを自動設定」を選び、その後macOSの「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」でアドレスとポートを確認します。
ネットワークサービスを確認する
Ethernetを使用中の場合、Wi-Fiのプロキシ設定だけを確認しても不十分です。ネットワーク接続を切り替えた場合は、現在のサービスを改めて確認してください。以前の自動プロキシ設定や、別の手動プロキシが有効になっていないかも確認しましょう。
手動で設定する場合、HTTPプロキシとセキュアWebプロキシには実際のHTTP待ち受けポートを、SOCKSプロキシには実際のSOCKS待ち受けポートを指定します。例のアドレス 127.0.0.1 はこのMac自身を指します。リモートノードのアドレスをシステムプロキシ欄に入力しないでください。クライアントが自動プロキシ設定を生成する場合は、その状態を確認し、設定用アドレスを通常のHTTPプロキシサーバーと混同しないようにしましょう。
ターミナルで次の読み取り専用コマンドを実行し、システムに現在設定されているプロキシを確認する方法もあります。出力に古いアドレスやポートが表示された場合は、現在のネットワークサービスの設定画面で修正してから、テストするアプリを再起動してください。
scutil --proxy
networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"ブラウザで使えない場合：独自プロキシ設定と拡張機能の競合を確認する
ブラウザでWebページが開けても、現在の接続経路が使えることを示すだけで、v2rayNが使われている証拠にはなりません。反対に、ほかのアプリが正常でもブラウザだけ開けないことがあります。まず同じURLで再テストし、すべてのサイトで失敗するのか、特定のサイトだけなのかを記録してください。
- ブラウザ独自のプロキシ設定を確認：ブラウザにプロキシ設定項目がある場合、以前設定した手動サーバーではなく、macOSのシステムプロキシを使う設定になっているか確認します。
- プロキシを書き換える拡張機能を一時的に無効化：特に、プロキシ切り替えやリクエスト転送を行う拡張機能に注意してください。無効化したら新しいウィンドウでテストし、拡張機能とシステム設定を同時に変更しないようにします。
- 現在のネットワークとログイン状態を確認：ネットワークを切り替えた場合は、該当するサービスのプロキシ設定を確認し直してください。ログイン画面が必要な公衆ネットワークでは、まずネットワーク側の接続手続きを完了します。
- 通常のウィンドウと新しいセッションを比較：元のウィンドウだけで問題が起きる場合は、サイトのキャッシュ、ブラウザ設定、拡張機能を確認します。v2rayNのノード設定をすぐに変更しないでください。
ブラウザに「プロキシサーバーが接続を拒否しました」と表示される場合は、システムプロキシのローカルアドレスとポート、コアの待ち受け状態を優先して確認します。ページへの接続後、特定のサイトだけで証明書エラーやアクセス失敗が起きる場合は、そのサイトまたはブラウザ固有の問題として調べてください。エラーを隠すために証明書検証を無効にしてはいけません。
別のリクエストで照合する
ブラウザでの結果がはっきりしない場合は、次のセクションのcurl -xを使い、同じローカルポートを明示して接続します。明示的なリクエストは成功するのにブラウザで失敗するなら、確認範囲をブラウザ設定、拡張機能、macOSで現在使用中のネットワークサービスに絞れます。
ターミナルで使えない場合：プロキシの明示指定と環境変数を個別に確認する
ターミナルのコマンドは、すべて同じネットワーククライアントではありません。curl、パッケージ管理ツール、その他のコマンドでは、プロキシ設定の参照方法が異なります。まずシステム設定を介さず、curlからv2rayNのHTTPポートの例へ直接接続します。実際のHTTPポートが10809でない場合は、コマンド内の数値を必ず置き換えてください。
curl -v -x http://127.0.0.1:10809 -I https://example.com出力に表示されるプロキシアドレス、HTTP CONNECTの処理、最終的な応答またはエラーを確認します。接続が拒否される場合、通常はそのポートで待ち受けるプログラムがないか、ポート番号が間違っています。リクエストがプロキシに届いているのに応答がない場合は、v2rayNのログ、ノード設定、接続先サイトを確認します。-Iはレスポンスヘッダーだけをリクエストします。サイトによってはこのリクエストへの応答が異なるため、-Iを付けずに再テストしてください。
プロキシを明示的に指定する
まず上記の
curl -xコマンドを実行します。シェルにプロキシ変数が設定されているかどうかに関係なく、ローカルHTTPポートでリクエストを処理できるか確認できます。環境変数を確認する
env | grep -i proxyを実行し、古いアドレスや誤ったポート、または接続先ドメインをプロキシ経由にしないNO_PROXYの設定が残っていないか確認します。現在のセッションに設定する
プロキシを明示したリクエストが成功したら、以下の例に従って現在のターミナルセッションに環境変数を設定し、
-xなしのcurlで結果を比較します。ツールごとに確認する
ほかのコマンドで引き続き接続できない場合は、そのツール独自のプロキシ設定や設定ファイルを確認します。
curlの動作を、すべてのコマンドラインアプリの動作に当てはめないでください。
env | grep -i proxy
export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809
curl -v -I https://example.comhttps_proxyの値がhttp://でも、接続先サイトが暗号化されていないHTTPに切り替わるわけではありません。これはローカルHTTPプロキシへの接続方式を示しており、HTTPSの接続先とは通常CONNECTでトンネルを確立します。SOCKSポートしか使えない場合は、curl --socks5-hostname 127.0.0.1:10808 -I https://example.comのように、SOCKS対応ツールのオプションを使います。ここで--socks5-hostnameを指定すると、ドメイン名の解決をSOCKSプロキシに任せられます。
エラーから原因を特定する：ポート、アドレス、証明書
エラーの原文から、リクエストがどの段階で止まっているかを判断できます。以下の例も前述のアドレスとポートを使用しています。OSやツールによって表示内容が異なる場合があるため、実際のコマンド出力とv2rayNのログをあわせて確認してください。
エラー：curl: (7) Failed to connect to 127.0.0.1 port 10809: Connection refused
原因と対処：リクエストがプロキシ処理に到達していません。v2rayNのコアが起動しているか、実際のHTTP待ち受けポートが10809か、コマンドでSOCKSポートを誤って指定していないか確認してください。
エラー：curl: (5) Could not resolve proxy: proxy.invalid
原因と対処：コマンドまたは環境変数で、名前解決できないプロキシホストが指定されています。env | grep -i proxyとツール独自の設定を確認し、古いプロキシアドレスを実際のローカル待ち受けアドレスに変更してください。
エラー：curl: (60) SSL certificate problem: unable to get local issuer certificate
原因と対処：接続は証明書の検証段階まで進んでいます。このエラーだけでローカルプロキシポートの故障とは判断できません。システム時刻、接続先サイトの証明書、ネットワーク環境を確認し、証明書検証を有効にしたまま再テストしてください。
curl -xでは成功し、-xを付けない同じコマンドで失敗する場合は、環境変数、NO_PROXY、コマンド独自のプロキシ設定を確認してください。どちらも失敗する場合は、今回のリクエストがv2rayNのログに記録されているかを確認します。記録がなければ、まず待ち受けアドレスとポートを再確認してください。
ネットワークを切り替えたりシステムプロキシを変更したりした後は、リクエストを再送信してログを確認します。以前の接続記録を今回のテスト結果と混同しないでください。また、ノード、ブラウザ拡張機能、シェル設定を一度に変更すると、復旧しても原因を特定しにくくなるため、変更は一つずつ行いましょう。
設定を戻し、段階ごとに再テストする
確認後は、設定経路をわかりやすく整理しておきましょう。ブラウザでは必要に応じてmacOSのシステムプロキシを使い、ターミナルのツールでは必要に応じて各ツールのプロキシオプションや環境変数を使います。一時的なテストであれば、例のポートをすべてのターミナルセッションに恒久的に設定する必要はありません。
- まずクライアントをテスト：v2rayNのコアが動作していることを確認し、現在のHTTP・SOCKS待ち受けポートを控え、新しいリクエストがログに記録されるか確認します。
- 次にシステムとブラウザをテスト：現在のネットワークサービスのプロキシ設定を確認し、競合する拡張機能を無効にしてから、新しいウィンドウで同じテストURLにアクセスします。
- 最後にターミナルをテスト：ポートを明示した
curl -xを実行し、成功したら環境変数と実際に使うコマンドをテストします。 - 一時的な環境変数を削除：今回のシェルテスト用の設定が不要になったら、
unset http_proxy https_proxyを実行します。ほかのプロキシ変数も設定した場合は、実際の変数名を指定して個別に削除してください。
この順序で確認すれば、「ローカルポートが使えるか」「アプリがシステム設定を読み込むか」「コマンドに独自のプロキシ設定があるか」を切り分けて検証できます。ポートと明示的なリクエストが正常なら、ノードを最初から再設定する必要はありません。明示的なリクエストも失敗する場合は、クライアントのログとノード設定を引き続き確認してください。