このチェックリストは、v2rayN、v2rayNG、v2flyNGが起動済みで、速度テストの結果も表示されるのに、ブラウザーやアプリだけがインターネットに接続できない場合に役立ちます。通信がローカルプロキシに入っているか、リスニングポートが使えるか、ルーティングでドメインを誤って遮断していないか、DNSが有効なアドレスを返しているか、TUNや他のプロキシがネットワーク入口を奪い合っていないかを確認します。
まず「接続済み」が何を意味するか確認する
クライアントのトレイアイコンが変わったり、実行ログに起動完了と表示されたりしても、コアプロセスが設定を読み込んだことしか分かりません。ブラウザーの通信がプロキシを経由したことや、リモートノードが正常に転送したことを示すものではありません。完全な通信経路には、アプリ、システムプロキシまたはVPNインターフェース、ローカルリスニングポート、ルーティングルール、DNS、出力ノードという少なくとも6つの要素があり、どれか1つが途切れるだけで「画面上は正常なのにWebページが開けない」状態になります。
まずは条件を絞って確認します。追加のプロキシツールをすべて終了し、V2Rayクライアントを1つだけ残します。動作確認済みのノードを選び、同じブラウザーで通常のWebページとプロキシが必要なWebページをそれぞれ開きます。通常のページも開けない場合は、ローカルポート、システムプロキシ、TUNを優先して確認します。通常のページは開けるのに特定サイトだけ失敗する場合は、ルーティング、DNS、ノードのプロトコル設定、リモート接続性を重点的に調べます。
ステップ1：システムプロキシとローカルリスニングポートを確認する
デスクトップ版で最も多いのは、コアは動作しているのにシステムプロキシが無効になっているケースです。v2rayNのローカルポートはブラウザーやアプリからのリクエストを受け取り、システムプロキシは対応アプリにそのポートへリクエストを送るよう指示します。両方が実際にリスニングしている同じ値を指している必要があり、デフォルトポートを推測してはいけません。
ブラウザーに個別のプロキシ設定を入れたことがある場合は、古いポートを参照し続けていないか確認します。たとえばクライアントが 127.0.0.1:10818 に変更されているのに、ブラウザー拡張機能が 127.0.0.1:10808 のままだと、リクエストは存在しないリスナーに送られます。企業向けネットワークツール、デバッグプロキシ、旧バージョンのクライアントが同じポートを使用している場合もあります。
動作状態を確認する
v2rayNのメイン画面で現在のサーバーが選択されていること、コアの起動が完了していること、連続再起動や即時終了が発生していないことを確認します。
リスニングポートを確認する
「設定」→「パラメーター設定」→「基本設定」を開き、ローカルSOCKSまたは混合プロキシのポートを記録します。10808がよく使われますが、現在の画面に表示されている値を優先してください。
システムプロキシを有効にする
メイン画面の「システムプロキシ」メニューで「システムプロキシを自動設定」を選び、システム設定のプロキシサーバーが
127.0.0.1と現在のポートを指していることを確認します。ポートの競合を解消する
他のプロキシやネットワークデバッグプログラムを終了して、v2rayNを再起動します。それでもログにバインド失敗が表示される場合は、ローカルポートを10818に変更して再度起動します。
アプリを再起動してテストする
ブラウザーを完全に終了してから再起動し、古い接続プールによる直接接続の再利用を防ぎます。まず通常のWebページをテストし、その後プロキシが必要なアドレスを確認します。
エラー：failed to listen TCP on 127.0.0.1:10808
原因と対処：ローカルポートでリスニングを開始できていません。通常は、ポートが別のプロセスに使用されています。重複して起動しているクライアントを終了するか、「設定」→「パラメーター設定」で未使用のポートに変更し、コアを再起動します。
エラー：bind: Only one usage of each socket address is normally permitted
原因と対処：同じアドレスとポートですでにリスナーが動作しています。タスクバーにv2rayNのインスタンスが2つ起動していないか確認し、デバッグプロキシ、旧クライアント、10808を使用しているローカルサービスを終了します。
エラー：proxy server is refusing connections
原因と対処：ブラウザーはプロキシへの接続を試みていますが、指定ポートで利用できるサービスがありません。システムプロキシのポートとクライアントのリスニングポートが完全に一致しているか、もう一度確認します。
ステップ2：ルーティングモードを検証しやすい状態に戻す
ルーティングルールは、リクエストをプロキシ、直接接続、ブロックのどれに振り分けるかを決めます。ルールセットの期限切れ、カスタムドメインの誤記、優先順位の逆転などにより、対象サイトが誤った出力先へ送られることがあります。トラブルシューティング中は複数のルールを同時に変更せず、まず境界が明確なモードに切り替え、ログで対象ドメインが最終的にどのルールへ一致したかを確認します。
v2rayNで「設定」→「ルーティング設定」を開き、一時的にクライアントが提供する基本ルールを選び、追加したカスタムルールを無効にします。「グローバルプロキシ」ではアクセスできるのに、「ローカルネットワークと一般的な直接接続ドメインをバイパス」ではアクセスできない場合、ノードとポートはおそらく正常で、問題はルールによる振り分け、ドメイン分類、DNSの応答結果にあります。
- グローバルプロキシは使えるがルールモードで失敗：対象ドメインが誤って直接接続に振り分けられていないか確認します。特にカスタムサフィックスルールと正規表現を確認してください。
- グローバルプロキシも失敗：ローカルポート、ノードのプロトコル設定、TLSの時刻、リモートネットワークを引き続き確認し、ルーティングを何度も変更しないでください。
- ローカルネットワークのアドレスだけ失敗：プライベートアドレスがプロキシへ送られていないか確認します。プリンター、ルーターの管理画面、共有デバイスは通常、直接接続にします。
- 一部のサブドメインだけ失敗：Webページが複数のAPIドメインを同時に呼び出している可能性があります。メインドメインだけを追加するのではなく、コアのログから失敗している具体的なホスト名を確認します。
結論：グローバルモードは切り分けに使う
グローバルプロキシでアクセスが戻った場合、ローカルリスニングとノードからの出力は基本的に利用できます。次はルールを修正し、グローバルモードに常用で依存しないようにします。カスタムルールを1つずつ戻せば、誤った振り分けの原因を直接特定できます。
ステップ3：DNS名前解決とシステム時刻を確認する
DNSの障害には、ドメインをまったく解決できない、到達できないアドレスに解決される、DNSリクエストが誤って振り分けられるという3つの典型的な症状があります。サーバーアドレスを直接入力すると接続できるのに、ドメイン名では失敗する場合、原因はほぼDNSに絞れます。ノードサーバー自体がドメイン名を使っている場合、DNSの失敗によりコアが出力接続を開始する前に停止することもあります。
まずシステムの日付、タイムゾーン、自動時刻合わせを確認します。時刻のずれはTLS証明書の検証だけでなく、サブスクリプション内の有効な設定をハンドシェイク失敗のように見せることもあります。次にシステムのDNSキャッシュを消去し、ブラウザーで個別に設定した暗号化DNSを一時的に無効にして、テストリクエストが同じ名前解決経路を使うようにします。
システム時刻を同期する
システムの「設定」→「時刻と言語」→「日付と時刻」を開き、自動的な時刻とタイムゾーンの設定を有効にして、すぐに一度同期します。
名前解決のログを確認する
ノードに再接続してコアのログを開き、
lookup、DNS、no such host、timeoutを検索し、失敗したドメインを記録します。キャッシュを消去する
通常のトラブルシューティング手順でシステムのDNSキャッシュを更新し、ブラウザーを終了して再起動します。キャッシュに残った古いアドレスが使われ続けるのを防ぎます。
名前解決の入口を統一する
切り分け中はDNS設定を1つに絞り、クライアントのDNS、ブラウザー独自のDNS、他のネットワークツールによるDNS制御を同時に有効にしないでください。
ipconfig /flushdns
nslookup example.com
netstat -ano | findstr 108081つ目のコマンドでWindowsのDNSキャッシュを消去し、2つ目で現在のシステムリゾルバーがアドレスを返せるか確認し、3つ目で10808がリスニング状態か確認します。クライアントの実際のポートが10808でない場合は、「パラメーター設定」に表示された値へ置き換えてください。コマンドに出力があっても経路が正常とは限りませんが、「リスニングしていない」状態と「名前解決に失敗している」状態をすばやく区別できます。
エラー：failed to find an available destination
原因と対処：コアが利用可能な宛先アドレスを取得できていません。よくある原因は、ドメインの名前解決失敗、またはルーティングによる絞り込み後に有効なアドレスが残っていないことです。ノードサーバーのドメイン表記を確認し、DNS設定を統一してからコアを再起動します。
エラー：lookup server.example: no such host
原因と対処：現在のDNSが、そのドメインは存在しないと返しています。サブスクリプションでサーバーアドレスが途中で切れていないか確認し、利用可能なリゾルバーに変更してからサブスクリプションを再更新します。
エラー：context deadline exceeded
原因と対処：接続または名前解決が制限時間内に完了していません。まずログがDNS段階で発生したのか、出力接続のハンドシェイク段階で発生したのかを切り分け、その後ローカルネットワークのパケットロス、ノードポート、通信パラメーターを確認します。
ステップ4：TUN、VPNインターフェース、ファイアウォールの競合を除外する
TUNモードは仮想ネットワークインターフェースを作成し、システムプロキシを読み取らないプログラムも転送対象にします。対象範囲が広い一方で、他のVPNインターフェース、仮想マシンのネットワークアダプター、企業向けセキュリティソフト、ファイアウォールルールと競合しやすくなります。典型的には、システムプロキシなら閲覧できるのにTUNを有効にするとすべて切断される、またはクライアント終了後も異常なルートが残るといった症状が出ます。
切り分けでは、まずTUNを無効にして通常のシステムプロキシだけを残します。アクセスが戻れば、ノード設定は主な原因ではありません。続いて、仮想インターフェースが正常に作成されたか、デフォルトルートが重複して制御されていないか、DNSが停止済みの仮想インターフェースを参照していないかを確認します。デフォルトルートを変更できるネットワークツールを2つ同時に有効にしないでください。
- 仮想ネットワークアダプターを作成したり、デフォルトルートを変更したりする他のプログラムを終了し、現在のクライアントだけを残します。
- v2rayNでTUNモードを無効にし、「システムプロキシを自動設定」を再び有効にして、ブラウザーの基本的なアクセスを確認します。
- ファイアウォールでv2rayNのメインプログラムと現在のコアに、プライベートネットワークおよびパブリックネットワークへのアクセスが許可されているか確認します。
- クライアントをアップグレードした直後なら、システムを再起動して、古い仮想インターフェース、ルーティングテーブル、使用中のプロセスを完全に解放します。
- TUNを再び有効にした後でログを確認し、受信タイプが変化したこと、失敗がDNS転送段階で発生していないことを確認します。
エラー：failed to create TUN interface
原因と対処：仮想インターフェースを作成できません。権限不足、ドライバーの異常、インターフェース名の競合などが考えられます。他の仮想ネットワークツールを終了し、システムを再起動してから、適切な権限でTUNを有効にします。
エラー：access is denied
原因と対処：クライアントにネットワークアダプターやルートを操作するための権限がありません。まずTUNを無効にして通常のプロキシを確認し、その後システム権限とセキュリティソフトのブロック記録を調べます。
結論：通常のプロキシを先に通し、その後TUNを確認する
TUNを無効にすると接続が戻る場合は、仮想インターフェース、ルーティングテーブル、DNSの制御へ重点を移します。この段階でVMessやVLESSのノードを何度も変更しても、ローカルのネットワーク入口の競合は解消しません。
ステップ5：AndroidのVPN権限とアプリごとの振り分けを確認する
v2rayNGはXrayコア、v2flyNGはv2flyコアを使用し、Androidでは通常、システムのVPNインターフェースを通じて通信を制御します。ステータスバーにVPNアイコンが表示されても、すべてのアプリが正しく対象になっているとは限りません。ブラウザーは使えるのに特定のアプリだけ使えない場合は、まずアプリごとの振り分けを確認します。すべてのアプリが使えない場合は、VPN権限、ノード設定、DNS、バックグラウンド動作のバッテリー制限を確認します。
VMess、VLESSなどの設定では、サーバーアドレス、ポート、ユーザー識別子、通信方式、TLS、パスのパラメーターを一致させる必要があります。サブスクリプションの更新後にサーバー側の設定が変わると、古い設定がリストに残って選択可能に見えても、接続はハンドシェイク段階でタイムアウトすることがあります。その場合はサブスクリプションを更新し、新しく更新された項目を選び直してください。古いノードをコピーして修正し続けるのは避けます。
VPNインターフェースを再作成する
現在の接続を停止し、ステータスバーからVPNアイコンが消えるまで待ってから、接続を再開します。システムの許可ダイアログで承認済みであることも確認します。
アプリごとの振り分けを無効にする
クライアントの「設定」→「アプリごとのプロキシ」を開き、切り分け中はホワイトリストまたはブラックリストのルールを一時的に無効にします。ブラウザーとテスト対象アプリが同じ経路を使うようにします。
サブスクリプションを更新する
サブスクリプショングループから更新を実行し、新しいノード数と名前が更新されたことを確認してから、更新後のノードを選んで接続テストを行います。
ノード設定を確認する
サーバーポート、通信方式、TLS、SNI、Host、パスを確認し、別のノードの設定が現在の構成に混ざっていないことを確認します。
バックグラウンド動作を許可する
システムのアプリ設定でクライアントのバックグラウンド動作を許可し、画面消灯後にバッテリー制御でVPNプロセスが停止されないようにします。
ノードの速度テストには数値が出るのに、なぜWebページを開けないのですか？
速度テストのリクエストとブラウザーの完全なアクセス経路は、必ずしも同じではありません。いったん接続を停止して再接続し、アプリごとのプロキシを無効にして、ブラウザーの通信がコアのログに表示されるか確認します。
通常のWebサイトは開けるのに、一部のドメインだけ読み込み中のままになる場合は？
グローバルプロキシに切り替えて比較します。グローバルモードで復旧する場合は、そのドメインに適用されたルーティングルールとDNSの応答アドレスを確認します。グローバルモードでも失敗する場合は、ノードの通信方式とTLS設定を確認します。
サブスクリプションを更新したら、逆にすべてタイムアウトする場合は？
端末の時刻が正しいことを確認し、サブスクリプションをもう一度更新して、新しく生成されたノードを選びます。古いノードがリストに残っている場合は、グループと更新時刻を確認し、期限切れの項目をテストし続けないでください。
特定のアプリだけインターネットに接続できない場合は？
「設定」→「アプリごとのプロキシ」を開き、そのアプリが除外されていないか確認します。切り分け中は振り分けを無効にし、復旧してからアプリのルールを1つずつ追加します。
画面ロック後しばらくすると接続が切れる場合は？
v2rayNGまたはv2flyNGのバッテリー設定をバックグラウンド動作の許可に変更し、VPNの継続動作も許可します。再接続後に5分間画面をロックしてテストし、ステータスバーのVPNアイコンが残っていることを確認します。
10分で確認する順番：一度に変更するのは1つだけ
最も早い解決方法は、ノードを何度も交換することではありません。ノードを固定し、通信経路を近い部分から順に確認します。各手順が終わるたびに再テストして結果を記録し、復旧したら直前に変更した唯一の要素を確認すれば、障害箇所を特定できます。ノード、ポート、DNS、ルーティングを同時に変更すると、復旧しても本当の原因が分からず、次回も同じ作業を繰り返すことになります。
- 1分目：他のプロキシツールを終了し、クライアントのインスタンスが1つだけ動作していることを確認します。
- 2分目：システムプロキシのアドレス、クライアントのローカルリスニングポート、ブラウザーのプロキシポートを確認します。
- 3〜4分目：グローバルプロキシに切り替えて比較し、結果からルーティングによる振り分けの問題か判断します。
- 5〜6分目：システム時刻を同期し、ログにあるDNS、lookup、timeoutの情報を確認します。
- 7〜8分目：TUNまたはアプリごとのプロキシを無効にし、最も単純なシステムプロキシまたはVPN経路でテストします。
- 9分目：サブスクリプションを更新し、VMessまたはVLESSのポート、通信方式、TLS、SNI、パスを確認します。
- 10分目：クライアントとテスト対象アプリを再起動し、重要なログを保存してから、ノードを変更するか判断します。
最終判断：通信がどの層で止まっているかを確認する
ローカルからの受信記録がない場合は、システムプロキシ、VPN権限、ポートを確認します。受信はあるのに送信がない場合は、ルーティングとDNSを確認します。送信記録があるのにハンドシェイクが続けて失敗する場合は、ノード設定、システム時刻、リモート接続性を確認します。