v2rayNを起動している、またはv2rayNGが実行中と表示されるのにWebページを開けない場合に向けたチェックリストです。まず、コアの起動、アプリからの接続、ノードの利用可否を切り分けます。ローカルポート、プロキシを指定したリクエスト、ログを使って原因を特定しましょう。一度に変更する設定は1つに絞り、失敗した条件を記録してください。DNS、ルーティング、ノードを同時に変更すると、原因を判断しにくくなります。
1. 接続済み表示でも、リクエストが止まっている箇所を確認
v2rayNのコア起動メッセージやv2rayNGの実行中表示から分かるのは、該当プロセスまたはローカルVPNサービスが起動していることだけです。ブラウザーのリクエストがプロキシに届いているとも、リモートサーバーとのプロトコルハンドシェイクが完了しているとも限りません。ノードの遅延表示も、テスト方式を確認しましょう。TCP接続テストで確認できるのはポートへの接続であり、プロキシとして正常に動作するかまでは検証できません。
まず、ダウンロードやバックグラウンド同期を一時停止し、ノード、ブラウザー、テスト用URLをそれぞれ1つに絞ります。デスクトップでは、TUNとシステムプロキシを同時に使わず、通常のローカルプロキシだけで試してください。AndroidではVPNモードになっていること、ブラウザーがアプリ別ルールで除外されていないことを確認します。
- すべてのアプリで失敗する：コア、ローカル待ち受け、ノード接続を優先して確認します。
- ブラウザーだけ失敗する：システムプロキシ、ブラウザー独自のプロキシ設定、拡張機能を確認します。
- 一部のドメインだけ失敗する：DNS、分岐ルール、IPv6の接続先を優先して確認します。
- 特定のノードだけ失敗する：そのノードのログを記録し、利用できるノードと比較します。
2. システム時刻と基本ネットワークを確認
まずプロキシを無効にし、通常は直接アクセスできるWebサイトにローカルネットワークから接続できるか確認します。この状態でも接続できない場合は、Wi-Fiのログイン画面、ゲートウェイ、ネットワーク権限、回線接続を先に確認してください。プロキシクライアントで、切断された基本ネットワークを修復することはできません。公共Wi-Fiの利用認証が済んでいないと、ノードへの接続もタイムアウトし続けることがあります。
システムの日付、時刻、タイムゾーンを確認してください。TLS証明書の有効期間チェックには正確な時刻が必要で、VMessの認証も時刻のずれに影響されます。「表示されているタイムゾーンが違う」だけで故障と判断しないでください。重要なのは、画面上のタイムゾーン表示ではなく、端末の実時刻が正しいかどうかです。
- Windows：「設定」→「時刻と言語」→「日付と時刻」を開き、時刻を自動的に設定する機能を有効にしてから、「今すぐ同期」を実行します。
- Linux：
timedatectl statusを実行し、現在時刻とSystem clock synchronizedの状態を確認します。同期されていない場合は、ディストリビューションの時刻サービス設定を修正してください。 - Android：システム設定で「日付と時刻」を検索し、日付と時刻の自動設定を有効にします。メニューの場所はシステムによって異なります。
- ネットワークの比較：Wi-Fiとモバイルネットワークを切り替えて試します。同じノードが一方のネットワークだけで失敗する場合は、そのネットワークの接続制限やDNSを確認してください。
3. ローカルポートでコアの待ち受けを確認
v2rayNのウィンドウが開いていても、プロキシの接続口が用意されているとは限りません。「設定」→「パラメーター設定」を開き、ローカルの待ち受けアドレス、ポート、接続口の種類を確認します。項目名はデスクトップ版によって異なる場合があります。以下では127.0.0.1:10808を例にします。実際には画面に表示されている値に置き換えてください。旧設定ではSOCKSとHTTPのポートが別々の場合があり、新しい設定では混合接続口を使うこともあります。
Windows PowerShellまたはLinuxのターミナルで、該当するコマンドを実行します。確認するのはTCPの待ち受け状態であり、ノードのアドレスではありません。ループバックアドレスで待ち受けていれば、通常はローカル端末から利用できます。トラブル対処のために、すべてのネットワークインターフェースで待ち受ける設定に変える必要はありません。
# Windows PowerShell：10808のTCP待ち受けプロセスを確認
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
# Linux：同じポートとプロセスを確認
ss -lntp 'sport = :10808'| 確認結果 | 説明 | 次の手順 |
|---|---|---|
| 待ち受けが見つからない | ポートの指定ミス、またはコアの起動失敗 | 設定を確認し、起動時のログを確認する |
| 別のプログラムが待ち受けている | ローカルポートが競合している | 競合するプロセスを終了するか、空いているポートに変更する |
| コアのプロセスが正常に待ち受けている | ローカル接続口が確立している | プロキシを指定したリクエストテストに進む |
ポートを変更したら、システムプロキシ、ブラウザー独自の設定、ターミナルの環境変数も合わせて更新してください。クライアントのポートだけを10808から10818に変更し、アプリが古いポートへ接続したままだと、コアは正常に動作しているのにWebページを開けない状態になります。ポートの競合が見つかっても、すぐにファイアウォールを無効にしないでください。まず、競合するプロセスが別のコアの実行インスタンスではないか確認します。
4. システムプロキシを確認し、接続口とノードの問題を切り分ける
デスクトップでは、v2rayNの「システムプロキシ」メニューから「システムプロキシを自動設定」を選び、OSに登録されたプロキシアドレスを確認します。Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。HTTPプロキシ欄にはHTTPまたは混合接続口を指定してください。SOCKS専用ポートをHTTPポートとして使うことはできません。
システムプロキシがすべてのアプリを透過的に処理するわけではありません。一部のコマンドラインツール、ゲーム、ブラウザー拡張機能は独自のプロキシ設定を使い、システム設定を無視することもあります。この違いを切り分けるには、curlからローカルのSOCKS接続口へ直接接続します。以下のテスト用ドメインはリクエスト経路の確認に使います。返されたステータスコードは、応答内容と合わせて判断してください。
# Windows：curl.exeを呼び出し、旧版PowerShellの同名エイリアスを回避
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
# Linux：ローカルSOCKS接続口から同じリクエストを送信
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/socks5hでは、宛先ドメイン名の解決をSOCKSプロキシ側に任せます。実際にコア内蔵DNSを使うか、リモート側で解決するかは設定によって異なります。接続タイムアウト10秒、全体のタイムアウト20秒は診断用の値であり、性能を保証するものではありません。HTTP接続口しか使えない場合は、プロキシ指定を--proxy http://127.0.0.1:10808に変更し、実際のHTTPポートを指定してください。
判定：プロキシを指定した接続が成功するなら、まずアプリ側の接続設定を修正
curlが有効なHTTPレスポンスを受け取るのにブラウザーだけ失敗する場合は、ブラウザーのプロキシ拡張機能、システムプロキシのアドレス、プロキシを使わないアドレスの一覧を確認してください。この時点ですぐにノードを変更したり、DNSを設定し直したりする必要はありません。サーバーによってはHEADリクエストを受け付けず405を返しますが、それだけでプロキシ接続の失敗とは判断できません。
- ローカルポートへの接続が拒否される：前のセクションに戻り、待ち受けアドレスと接続口の種類を確認します。
- ローカルポートには接続できるが、リクエストがタイムアウトする：同じ時刻のノードとのハンドシェイクログとアウトバウンドログを確認します。
- ページの応答はあるが、特定のWebサイトだけ異常：ルーティング先、Webサイト側の制限、DNSの結果を比較します。
5. v2rayNGでVPN権限とアプリ別プロキシを確認
Androidでは、デスクトップのシステムプロキシと同じ方法で切り分けることはできません。v2rayNGのVPNモードはAndroid VPNサービスを通じてアプリの通信を取り込みますが、実行中の表示だけでは、すべてのアプリが対象になっているとは限りません。メイン画面でサービスを起動し、システムからVPN権限が付与されていること、別のVPNサービスが接続を使用していないことを確認してください。
- 動作モードを確認：v2rayNGの「設定」を開き、VPNモードが選択されていることを確認します。プロキシモードだけでは、すべてのアプリの通信は自動的に取り込まれません。
- 対象アプリを確認：「設定」で「アプリ別プロキシ」を開き、ブラウザーが除外されていないか確認します。「選択したアプリのみプロキシ」を使う場合はブラウザーを選択します。除外モードの場合は設定が逆になります。
- システムVPNを確認：システム設定で「VPN」を検索し、v2rayNGが現在有効になっていることを確認します。「常時接続」や「VPNを使用しない接続をブロック」などの設定が意図どおりかも確認してください。
- バックグラウンド制限を確認：画面ロック後に接続が切れる場合は、アプリ情報のバッテリー設定でバックグラウンド実行を許可してから、再度ロックして試します。権限の名称は端末によって異なります。
ノードの接続テストに成功しても、アプリ別設定が正しいとは限りません。テストがクライアント自身から実行され、ブラウザーは除外されている可能性があります。v2rayNGはXrayコアを使用します。別の端末でV2flyコアのv2flyNGを使っている場合は、プロトコルの対応状況とノードのパラメーターも個別に確認してください。サブスクリプション名が同じだからといって、実際の設定も同じとは限りません。
6. コアのログを確認し、実際のエラーから原因を特定
古いログを消去してから、失敗するリクエストを1回だけ送信し、v2rayNのコアログまたはv2rayNGのログ画面を確認します。発生時刻、接続段階、エラーの前後を記録してください。コアのバージョンによってエラーの形式は異なります。以下はよく見られる断片であり、毎回同じ内容が出るとは限りません。
エラー：address already in use
原因：待ち受けアドレスとポートがすでに使用されているため、コアがバインドできません。
対処：ポート確認コマンドで該当プロセスを特定し、重複したインスタンスを終了するか、空いているポートに変更します。アプリのプロキシ設定も合わせて更新してください。
エラー：connection refused
原因：接続先がリクエストを明示的に拒否しています。接続先はローカルの接続口の場合も、リモートノードの場合もあります。
対処：まずログに記録されたアドレスを確認します。ローカルアドレスなら待ち受け状態を、リモートアドレスならノードのポートとサービスの稼働状況を確認してください。
エラー：i/o timeout
原因：接続または読み書きが制限時間内に完了していません。通信経路、サーバー、ハンドシェイクの段階に問題がある可能性があります。
対処：別のネットワークや利用できるノードと比較し、前後のログを保存します。接続時のタイムアウトか、接続後の読み取りタイムアウトかを切り分けてください。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間を確認できません。端末の時刻が間違っている場合や、サーバー証明書に問題がある場合に発生します。
対処：まずシステム時刻を同期し、次にサーバー証明書の状態を確認します。証明書検証の無効化を恒久的な対処として使わないでください。
エラー：no such host
原因：ドメイン名の解決で利用可能な結果が得られていません。ノードのドメイン名とWebサイトのドメイン名を分けて確認してください。
対処：ドメイン名の入力と実際に使われるDNS経路を確認します。ノードのドメイン名を解決できない場合は、まずプロキシ接続を確立する前の名前解決を修復してください。
ログ上ではノードに接続できているのに、その後のハンドシェイクに失敗する場合は、サブスクリプションの有効期限、認証情報、トランスポートの種類、パス、TLSサーバー名などを確認します。VLESSノードでREALITYを有効にしている場合は、公開鍵、short ID、フローの設定も確認してください。VMess、VLESS、トランスポートの設定を手当たり次第に入れ替えず、サーバーから提供された設定一式を基準にします。
7. DNSとルーティングを確認し、一部のWebサイトが開けない問題を解決
ローカルの接続口と、プロキシを指定したリクエストが少なくとも1つ成功してから、DNSと分岐ルールを調べます。Windowsのnslookup example.comやLinuxのgetent ahosts example.comでシステム側の名前解決を確認できますが、コア内蔵DNSが正常だと直接証明するものではありません。ブラウザーのセキュアDNSが有効になっていると、別の名前解決経路も加わります。
同じドメイン名について、システム経由の名前解決とプロキシを指定したリクエストの結果を比較します。DNSを変更するときは元の設定を記録し、一度に変更するのは1か所だけにしてください。ノード接続に使うサーバーのドメイン名は、接続確立前に解決する必要があります。その名前解決に、接続先ノード経由でしか利用できないDNSを使うと、起動時に循環依存が発生する場合があります。
| 症状 | 優先して確認する項目 | 比較方法 |
|---|---|---|
| システムでの名前解決は失敗するが、プロキシ経由のリクエストは成功する | システムDNSまたはブラウザーの名前解決経路 | アプリがドメイン名をプロキシに渡しているか確認する |
| グローバルプロキシでは成功するが、ルールベースでは失敗する | 直結ルール、カテゴリデータ、ルールの順序 | ログで該当リクエストのアウトバウンドタグを確認する |
| ドメイン名にAAAAレコードがあると失敗する | IPv6の接続性と接続先の対応状況 | 実際の接続先アドレスを確認し、一時的にIPv4と比較する |
| ブラウザーだけ失敗し、他のアプリは正常 | ブラウザーのセキュアDNSと独自のプロキシ設定 | 関連する拡張機能を一時停止し、同じURLで再テストする |
クライアントの「ルーティング」メニューで一時的にグローバルプロキシへ切り替え、同じURLで試したら元の設定に戻す方法もあります。グローバルプロキシで変わるのは、コアに届いた通信の接続先です。もともとシステムプロキシを無視するアプリが自動的に接続されるわけではありません。グローバルでは成功し、ルールベースでは失敗する場合は、範囲の広い直結ルールが先に適用されていないか確認します。V2Ray/Xrayのルーティングルールは順番に評価され、先に一致したルールが後続の判定に影響します。
8. 再テストとよくある質問：必要最小限の情報を記録
修正したら、基本ネットワーク、ローカルの待ち受け、プロキシを指定したリクエスト、ブラウザー、以前失敗したWebサイトの順に、同じ条件で再テストします。一度に変更する項目を1つにすれば、安定した結果をもとに原因を特定しやすくなります。サブスクリプションの更新とノードへの接続は別の問題です。更新に失敗しても登録済みノードが使えなくなるとは限らず、ノードが使えてもサブスクリプションURLに現在アクセスできるとは限りません。
ノードの遅延は表示されるのに、Webページを開けないのはなぜ？
遅延テストがTCP接続の確認だけではないか調べます。続いて、プロキシを指定したリクエストを実行し、ハンドシェイクのログを確認してください。ポートに接続できても、認証、TLS、トランスポートの設定が一致していない場合があります。
v2rayNを終了したら、ブラウザーがネットにつながらなくなったのはなぜ？
クライアントを再起動し、「システムプロキシ」メニューから「システムプロキシを解除」を選びます。その後、システムプロキシのアドレスがローカルポートを指したままになっていないか確認してください。組織の管理下にあるPCでは、元のプロキシ設定を先に確認しましょう。
v2rayNGは実行中なのに、ブラウザーだけ接続できない場合は？
「設定」で「アプリ別プロキシ」の対象アプリまたは除外アプリの設定を確認し、ブラウザーが通信の取り込み対象になるよう変更します。その後、ブラウザーを終了して再起動し、別のVPNサービスが接続を使用していないか確認してください。
DNSを変更しても直らない場合、再インストールすべき？
まずDNS設定を元に戻し、リクエストがコアに届いているか、ログのどの段階で失敗しているかを確認します。再インストールする前に、設定とバージョン情報を保存してください。ローカルの待ち受け、システムプロキシ、サーバー側の設定に問題がある場合、再インストールしても原因の特定にはなりません。
- 環境を記録：OS、クライアントのバージョン、コアのバージョン、ネットワークの種類。
- 接続方法を記録：システムプロキシまたはVPNモード、ローカルポート、アプリ別設定。
- 比較結果を記録：同じリクエストが別のノードや別のネットワークで成功するか。
- ログを記録：失敗の前後に関係する行を保存し、共有する前にサブスクリプションURL、認証情報、個人のネットワーク情報を削除します。
基本設定はクイックスタートガイドを、DNSやルーティングをさらに確認する場合は使い方ガイドのDNS設定を参照してください。まず失敗している段階を特定してから設定を変更すると、サブスクリプションを何度もインポートしたり、複数のスイッチを同時に切り替えたりするより、再現性のある結果を得やすくなります。