v2rayNが起動し、ノードを選択しているのに、macOSのブラウザーでWebページが開けない場合に役立ちます。まず通信がローカルプロキシに届いているかを確認し、次に外向き接続と名前解決を調べます。同じURLで比較し、設定は一度に一つだけ変更しましょう。システムプロキシが適用されていない、ポートが待ち受けていない、ルーティングの誤設定、DNSの異常、ブラウザー独自の設定という5つの原因を切り分けられます。
1. 「接続済み」がどの段階を指すか確認する
クライアントのメイン画面が開く、ノードが選択されている、遅延テストに結果が出る――これだけでは、ブラウザーがそのノード経由でWebサイトにアクセスできているとは限りません。V2RayとXrayはプロキシコアで、v2rayNは設定を管理してコアを起動します。システムプロキシは、対応アプリの通信をローカルの入口へ送ります。どこか一つでも途切れると、「クライアントは正常なのにWebページがタイムアウトする」ことがあります。
- まず通常のネット接続を確認：プロキシを経由しない状態にして、普段直接アクセスできるサイトを開きます。それでも失敗する場合は、Wi-Fi、認証ページ、ネットワーク自体を先に確認してください。
- 次にコアを確認：v2rayNのログを開き、起動後にポート競合や設定の解析エラーなどがないか確認します。メイン画面が表示されるだけでは、コアが正常に起動したとは言えません。
- 最後にリクエストを確認：対象ページを再読み込みし、アクセスログに該当ドメインの記録が出るか確認します。アクセスログが無効の場合、記録がないだけでリクエストがコアに届いていないとは判断できません。
2. macOSのシステムプロキシと現在のネットワークサービスを確認する
システムプロキシの設定はネットワークサービスごとに保存されます。Wi-Fiで正しく設定していても、Ethernetに切り替えた後も有効とは限りません。VPNやネットワーク管理アプリが設定を書き換えることもあります。まずv2rayNの「システムプロキシ」で「システムプロキシを自動設定」を選び、その後macOSの設定で反映状況を確認します。バージョンによってメニューの場所が異なる場合があるため、現在の画面表示に従ってください。
-
ネットワーク設定を開く
macOSの「システム設定」→「ネットワーク」→現在使用中のWi-FiまたはEthernetサービス→「詳細」→「プロキシ」の順に開きます。実際にネット接続に使っているサービスを確認してください。
-
プロキシの接続先を確認する
手動プロキシの接続先は通常、
127.0.0.1です。HTTP、HTTPS、SOCKSのポートは、クライアントが実際に待ち受けているポートに合わせます。ノードのリモートサーバー側ポートを入力しないでください。 -
プロキシの適用方式を確認する
自動プロキシ設定を使う場合は、設定ファイルのアドレスとクライアントのモードが一致しているか確認します。手動プロキシの場合は、該当するスイッチを確認してください。出所の分からない古い自動プロキシ設定と手動設定を、同時に有効にしたままテストしないでください。
-
リクエストを再試行する
設定を保存したら、対象ページを開き直します。変化がなければブラウザーを終了して再起動し、ターミナルで
scutil --proxyを実行して、有効な設定のアドレス、ポート、オン・オフの状態を確認します。
scutil --proxyの出力にあるHTTPEnable、HTTPSEnable、SOCKSEnableで、手動プロキシが有効か確認できます。自動設定の場合はProxyAutoConfigEnableと設定アドレスも確認してください。このコマンドで分かるのはシステム設定であり、すべてのアプリがその設定に従うとは限りません。ターミナルツールやブラウザーによっては、独自のプロキシ設定が使われます。
3. ローカルポートの待ち受けを確認して、プロキシを指定してテストする
まずv2rayNの「設定」→「パラメータ設定」で、ローカルの待ち受けポートを確認します。バージョンによって項目名が異なる場合があります。以下では、SOCKSに対応していることを確認済みの10808を例にします。すべての環境でこの値に変更するという意味ではありません。入口がHTTPのみの場合は、対応するHTTPプロキシの方法でテストしてください。
# ポートのTCP待ち受けを確認
lsof -nP -iTCP:10808 -sTCP:LISTEN
# SOCKS経由でアクセスし、接続先ドメイン名をプロキシ側で解決
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 5 --max-time 15 -I https://example.com/lsofに出力がある場合は、そのプロセスが使用中のコアに該当するか確認します。別のプログラムが同じポートを使用していても出力されます。何も表示されない場合は、ポートの入力間違い、コアの終了、想定どおりのアドレスで待ち受けているかを確認してください。問題が起きたからといって、すぐにLANからの接続を許可する必要はありません。ブラウザーからローカルプロキシに接続するだけなら通常不要です。
テスト用URLには説明専用の予約済みドメインを使っています。実際の調査では、アクセスできると分かっているHTTPSのURLに置き換えてください。HTTPレスポンスヘッダーを受信できれば、そのリクエストでは少なくともプロキシへの接続とHTTPS通信が完了しています。ステータスコードが403でも、接続タイムアウトとは異なります。一つのURLで成功しても、すべてのサイトやルーティングが正常とは限りません。
判断の目安：コマンドは成功するが、ブラウザーでは失敗する
現在のノードとDNS設定はそのままにし、すぐにプロトコルを変更しないでください。プロキシを明示したテストが成功する場合は、まずシステムプロキシの適用状況、ブラウザー独自のプロキシ設定、拡張機能を確認します。明示的なプロキシ接続も失敗する場合は、外向き接続と名前解決を調べます。
4. ルーティングを比較して誤振り分けを特定する
ルーティングによって、通信が直接接続、プロキシ経由、またはブロックのいずれになるかが決まります。ルールの「直接接続」は「利用できる経路を自動選択する」という意味ではありません。対象ドメインが誤って直接接続に振り分けられ、現在のネットワークからアクセスできなければ、通信は失敗します。グローバルプロキシにしても、すべての通信が取り込まれた証明にはなりません。影響するのはコアに届いたリクエストだけです。
| 比較結果 | まず疑う原因 | 次の手順 |
|---|---|---|
| ルールモードでは失敗し、グローバルプロキシでは成功 | ドメインまたはIPが直接接続に振り分けられている、または外向き接続がブロックされている | 該当したルールと出力タグを確認し、修正後にルールモードへ戻す |
| どちらのモードでも失敗 | ローカルの入口、ノードの外向き接続、またはDNS | プロキシを指定したコマンドを実行し、同じ時刻のエラーログを確認する |
| Webページは開くが、特定のアプリでは失敗 | アプリがシステムプロキシを使っていない、または独自の設定がある | アプリのプロキシ設定を確認し、必要に応じてTUNを検討する |
| 一部のドメインだけ失敗 | サイト側の制限、ルール、または特定の名前解決結果 | 別のドメインでも比較し、ノード全体の障害と早合点しない |
v2rayNのルーティング選択で一時的に「グローバル」へ切り替えて比較し、テスト後は元のモードに戻します。設定の出力タグにproxy、direct、blockを使っている場合は、アクセスログで該当するタグを確認してください。カスタム設定では別の名前が使われることがあります。タグの文字だけで動作を推測しないでください。
5. ローカル、プロキシ側、ブラウザーのDNSを切り分ける
DNSは一つの場所で処理されるとは限りません。macOSのリゾルバー、ブラウザーのセキュアDNS、コアのDNS、プロキシサーバー側の名前解決が関わることがあります。システムDNSを変えても、プロキシ側の結果が変わるとは限りません。また、ブラウザーでセキュアDNSを有効にしても、ノードサーバーのアドレスが必ず正しく解決されるわけではありません。
以下のコマンドは、SOCKSリクエストの接続先ドメイン名をどこで解決するかだけを切り替えます。1つ目はローカルで名前解決し、2つ目はドメイン名をプロキシ側に渡します。同じノード、URL、ポートで比較し、ローカルの入口がSOCKSに対応していることを確認してください。
# 接続先ドメイン名をローカルで解決
curl --noproxy "" --proxy socks5://127.0.0.1:10808 \
--connect-timeout 5 --max-time 15 -I https://example.com/
# 接続先ドメイン名をプロキシ側で解決
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 5 --max-time 15 -I https://example.com/
# macOSの現在のリゾルバー設定を確認
scutil --dns- ローカルでの名前解決は失敗し、プロキシ側では成功：システムのリゾルバー、ネットワークから配布されたDNS、ローカルキャッシュを優先して確認します。これは切り分けの手掛かりであり、一度のテストだけでDNS汚染と断定できるわけではありません。
- ローカルでは成功し、プロキシ側では失敗：コアからサーバーまでの名前解決経路、リモートDNSへの接続性、関連するDNSリクエストの出力先を確認します。
- どちらも失敗：ローカルプロキシへの接続、ノードへの接続、接続先とのTLSハンドシェイクのどの段階で失敗したかを確認します。すべてのタイムアウトをDNSの問題と決めつけないでください。
- ブラウザーだけ失敗：セキュアDNSの元の設定を記録し、一時的にシステム設定に従うよう変更して再試行します。テスト後は必要に応じて元に戻してください。複数のDNS設定を同時に変更しないでください。
名前解決の設定を変更した後、sudo dscacheutil -flushcacheとsudo killall -HUP mDNSResponderを実行すると、macOSのDNSキャッシュを消去できます。その後、ブラウザーを再起動してください。実行には管理者の許可が必要です。ネットワーク設定自体に誤りがある場合、キャッシュを消去しても解決しません。DNSやTLSの問題を回避するために、証明書の検証を無効にしないでください。
6. 「タイムアウト」だけでなく、実際のエラー内容を確認する
失敗時のエラー行を省略せずに記録し、少なくともローカル接続、ドメイン名の解決、証明書のどこで失敗したかを区別します。以下はcurlでよく見られるエラーの冒頭部分です。実際の出力にはポート、ホスト名、証明書についての詳細も表示されるため、後続の内容もあわせて判断してください。
エラー：curl: (7) Failed to connect
原因と対処：指定したアドレスへの接続に失敗しています。続く説明に127.0.0.1が示されている場合は、ローカルポートとコアの待ち受けを確認します。リモートアドレスが示されている場合は、実際の通信経路と外向き接続を調べてください。
エラー：curl: (6) Could not resolve host
原因と対処：ローカルでの名前解決に失敗しています。URLの入力を確認し、scutil --dnsでリゾルバーを調べてから、socks5hを使ったテスト結果と比較してください。
エラー：curl: (28) Operation timed out
原因と対処：設定した時間内にリクエストが完了しませんでした。ただし、このエラーだけでは失敗した段階を特定できません。-vを付けて再試行し、ログで最後に完了した接続段階を確認してください。タイムアウト時間を延ばすだけで問題を覆い隠さないようにしましょう。
エラー：curl: (60) SSL certificate problem
原因と対処：証明書の検証に失敗しています。まずmacOSの「システム設定」→「一般」→「日付と時刻」を確認し、次に接続先ドメイン、証明書チェーン、ネットワークによる妨害の有無を調べます。検証をスキップするオプションを恒久的な対処法として使わないでください。
ログを共有する前に、サブスクリプションURL、認証情報、ノードアドレス、アクセス記録に含まれる機密情報を隠してください。エラーの種類、発生時刻、コア名、必要なバージョン情報だけを残します。VMess、VLESS、Trojanなどのノードのプロトコル設定はサーバー側で決まります。プロトコル、TLS、SNIをむやみに変更すると、新たなハンドシェイクエラーを招くことがあります。
7. ブラウザーの競合を確認し、復旧後に再チェックする
プロキシを指定したテストが成功したら、ブラウザー側を調べます。まず新しい一時プロファイルで試し、履歴データをすべて消去するのは後にしてください。プライベートブラウズでも、すべての拡張機能が無効になるとは限りません。プライベートモードでの実行を許可された拡張機能や、プロキシ設定を固定する組織の管理ポリシーにも注意してください。
ターミナルではアクセスできるのに、ブラウザーで開けない場合
まずプロキシ切り替え拡張機能を無効にし、ブラウザーがシステムプロキシを使っていることを確認してから、一時プロファイルで同じURLにアクセスします。Firefoxでは「設定」→「一般」→「ネットワーク設定」を開き、システムプロキシ設定を使用しているか確認してください。古いポートを参照したままになっていないかもチェックします。
ノードを変えたら直りました。DNSも変更すべきですか？
まず変更せず、同じURLを使って2つのノードをそれぞれプロキシ指定でテストします。一方のノードだけ失敗する場合は、端末全体のDNS設定を変更するのではなく、そのノードの接続状況、プロトコル設定、外向き接続のログを優先して確認してください。
v2rayNを終了したら、ネットにまったくつながらなくなった場合
macOSで現在使用中のネットワークサービスから「詳細」→「プロキシ」を開き、すでに停止したローカルポートが接続先として残っていないか確認します。残ったプロキシ設定を解除し、直接接続をテストしてください。次回からは終了前にクライアントで「システムプロキシを解除」を選びます。
Androidでも接続済みなのにネットにつながらない場合
v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。まずシステムVPNの許可、ほかのVPNとの競合、アプリのルーティング設定でブラウザーが除外されていないかを確認してください。macOSのローカルポート設定をAndroidにそのまま適用しないでください。
- 普段使っているルールモードに戻し、直接接続するサイトとプロキシが必要なサイトをそれぞれ一つずつテストします。
- 一時的なデバッグログを無効にし、調査前に記録したブラウザーのDNS設定と拡張機能の設定に戻します。特定の設定が原因だった場合は、修正後の状態を維持してください。
- クライアントとブラウザーを再起動し、システムプロキシが正しく適用されることを確認します。次にクライアントを終了し、システムプロキシが正しく解除されることを確認してください。
- 有効なローカルポート、ルーティングモード、修正した項目を記録します。再発時はすべての設定を変更し直すのではなく、直近の変更から確認してください。