V2Rayトラブルシューティング完全ガイド

「接続後にインターネットへ接続できない」からといって、ノード自体が無効とは限りません。クライアントに起動済みと表示されても、ローカルプロセスの初期化が完了したことを示すだけで、リモートとのハンドシェイク、DNSクエリ、アプリの通信が成功した証拠にはなりません。まず影響範囲を確認します。すべてのサイトが開けないのか、ドメイン名を使うサイトだけなのか、システムプロキシを無効にすると直接接続が戻るのか、同じノードが別のネットワークでは使えるのか、ブラウザだけの問題なのか、コマンドラインや他のアプリでも起きるのかを確認してください。この4つの確認で、問題をネットワーク、名前解決、プロキシ接続、ノード設定のいずれかに絞り込めます。

基準状態に戻してから、層ごとに有効化する

v2rayNでは、まずシステムプロキシとTUNモードを無効にし、クライアントプロセスは動かしたまま通常の直接接続が正常か確認します。直接接続も失敗する場合は、ルーター、ネットワーク認証、ネットワークアダプター、ローカルDNSを先に確認し、V2Rayの設定を変更し続けないでください。直接接続が戻ったら、動作確認済みのノードを1つ選び、システムプロキシだけを有効にして、短時間だけルーティングをグローバルプロキシでテストします。グローバルモードでは使えるのにルールモードで使えない場合、問題はルーティングルール、GeoSiteデータ、DNSの振り分けにあることが多く、グローバルモードでも使えない場合はノードとローカルプロキシポートを確認します。

1. 他のプロキシ、アクセラレーター、通信を中継するツールを終了し、複数のプログラムがシステムプロキシやルーティングテーブルを同時に変更しないようにします。
2. システム時刻とタイムゾーンを確認します。時刻のずれはTLS証明書の判定ミスを招き、時刻情報を含む認証を失敗させることもあります。
3. クライアントでノードを選び直してコアを起動し、ログにローカルのインバウンド待ち受けが現れることを確認します。起動直後に終了していないかも確認してください。
4. 接続方式は1つだけ有効にします。通常のブラウザでテストする場合はシステムプロキシを優先し、システムプロキシとTUNを同時に有効にしないでください。
5. 純粋なIPアドレスの宛先と、一般的なドメイン名をそれぞれ開き、問題がDNSに集中しているかを判断します。

Windowsでは、次のコマンドでローカルポートが待ち受け状態か確認できます。ポート番号はv2rayNの現在の設定に合わせてください。一般的な設定ではSOCKSとHTTPの入口が同時に存在します。コマンドが何も出力しない場合、コアがそのポートを待ち受けていません。ポートの競合、設定生成の失敗、コアプロセスの終了が考えられます。

netstat -ano | findstr LISTENING
curl.exe -x http://127.0.0.1:10809 https://example.com/

2つ目のコマンドはシステムプロキシ設定を迂回し、ローカルHTTPプロキシへ直接リクエストします。ページのレスポンスが返れば、「アプリからローカルプロキシ、さらにノードへ」という基本経路は成立しています。問題はシステムプロキシの切り替えやブラウザ自身の設定にある可能性が高くなります。ローカルポートに接続できない場合はインバウンドポートを確認し、ローカルポートには接続できるもののリモート側で失敗する場合は、コアログのハンドシェイク、証明書、アドレス、ルーティング情報を確認してください。

設定ミスとネットワーク遮断を切り分ける

ノード設定では、サーバーアドレス、ポート、ユーザー識別子、転送方式、TLSの有効化、サーバー名、パスを1項目ずつ照合します。VMess、VLESS、Trojanではフィールドの意味が異なるため、アドレスとポートだけを置き換えて以前の転送パラメーターを使い続けることはできません。サブスクリプションからクライアントがノードを自動生成している場合は、まずサブスクリプションを再更新してノードを選び直します。手動入力の場合は、提供元の完全なパラメーターと各フィールドを照合してください。特にWebSocketのpath先頭にあるスラッシュ、gRPCのサービス名、TLSのサーバー名に注意が必要です。

同じ設定がモバイルネットワークでは使えて家庭のネットワークでは使えない場合、家庭側でDNSハイジャック、ルーターのフィルタリング、二重プロキシ、IPv6ルーティングの異常がないか確認します。反対に家庭のネットワークでは使えてモバイルネットワークで失敗する場合は、モバイル端末のバックグラウンド制限、プライベートDNS、現在のアクセスポイントを確認します。1回のリクエストだけでネットワーク側の障害と判断せず、少なくとも2つの異なるネットワークと2つの異なるノードで相互にテストしてください。結果を比較すれば、「特定ノードの異常」「特定ネットワークの異常」「クライアント全体の設定異常」を切り分けられます。

接続が復旧したら、ルーティングをグローバルモードから実際に使うルールモードへ戻し、中国本土向けの直接接続、プロキシ対象、ローカルネットワークのアドレスがそれぞれ想定した出口へ向かうか確認します。モードの違いについてはシステムプロキシ、グローバルモード、 中国本土を迂回するモードの違いを参照してください。切り替え後に再び接続できなくなった場合、基本接続ではなくルーティングルールとDNSを重点的に確認し、クライアントを再インストールしないでください。

タイムアウトとは、ある層が規定時間内に有効な応答を受け取れなかった状態です。ただしログの「timeout」は、TCP接続、TLSハンドシェイク、プロトコル認証、DNSクエリ、対象サイトの応答などを指す場合があります。対処前に、どの段階で、どれくらいの時間を要してタイムアウトしたかを記録します。複数のノードが同時にタイムアウトする場合は、ローカルネットワーク、システム時刻、DNS、クライアントコアを優先して確認します。1つのノードだけがタイムアウトする場合は、そのノードのアドレス、ポート、転送パラメーター、リモート側の状態を確認します。

相互テストで責任範囲を切り分ける

2×2のテストを行います。同じノードを現在のネットワークと別のネットワークでテストし、現在のネットワークでは別のノードもテストします。ノードを変えてもネットワークを変えても失敗し、他のノードは正常なら、そのノードに問題が集中しています。現在のネットワークですべてのノードが失敗し、ネットワークを変えると復旧するなら、ローカルネットワーク経路が原因です。すべての組み合わせで失敗する場合は、クライアント共通設定やサブスクリプションパラメーターを確認します。比較できなくなるため、テスト中はクライアントのバージョン、ルーティングモード、DNS設定を変えないでください。

「接続拒否」と「接続タイムアウト」は意味が異なります。接続拒否は通常、パケットが対象ホストに到達したものの指定ポートでサービスが待ち受けていない、または中間機器が明示的に拒否したことを示します。タイムアウトは、パケットが届いていない、戻り経路が途切れている、サービスが応答していない可能性があります。前者はポートとリモートサービスを先に確認し、後者はアドレス解決、ネットワーク経路、ファイアウォールを確認します。ログに短い間隔で再試行が続く場合は、最初の本当のエラーが埋もれないよう、クライアントを長時間再接続させずノードを一時停止してください。

TLSと転送パラメーターの確認順序

TLSを有効にした設定では、少なくともリモートアドレス、サーバー名、証明書の一致を確認します。サーバーアドレスはIPでもドメインでも構いませんが、サーバー名は通常TLSハンドシェイクに使われ、両者が同じとは限りません。手動編集でサーバー名を空欄にしたり、ノードのメモや誤ったドメインを入力したりすると、ハンドシェイクに失敗します。WebSocketを使う場合はHostとpath、gRPCを使う場合はserviceNameを確認し、REALITYを使う場合は公開鍵、短い識別子、サーバー名、フロー制御フィールドを照合します。証明書検証を無効にしてフィールドの誤りを隠さないでください。症状が消えても、設定が正しいことの証明にはなりません。

IPv6も不安定なタイムアウトの原因になります。ドメインがIPv4とIPv6の両方を返しても、現在のネットワークではIPv6接続が不完全な場合があります。初回接続だけ長く待たされてIPv4へフォールバックしたり、同じノードが使えたり使えなかったりするのが典型的な症状です。検証のため、クライアントDNSやシステムネットワークで一時的にIPv4を優先できますが、IPv6設定をすべて削除してはいけません。原因を確認したうえで、実際のネットワーク環境に合った優先順位を選びます。

ノード接続は確立しているのに特定サイトだけタイムアウトする場合は、対象ドメインが誤って直接接続へ振り分けられていないか、ブロックルールに一致していないか、DNSの返すアドレスがルーティングルールと一致しているかを確認します。対象ドメインを明示的なプロキシルールへ一時的に追加し、広いルールより前に置いてください。ルール変更後はコアを再起動するか設定を再読み込みし、ログで一致した出力タグを確認します。domain、ip、geositeの順序については、V2Rayルーティングルール設定の実践も参照してください。

修正後は少なくとも3種類のリクエストを確認します。ノードサーバーのドメイン解決、通常のHTTPSサイトへのアクセス、数分間の接続安定性です。ハンドシェイクが1回成功しただけでは、問題が解消したとはいえません。一定間隔で切断される場合は、ネットワーク切り替え、ルーターの接続追跡、モバイル端末の省電力設定、サーバー側のアイドルタイムアウトを引き続き確認し、クライアントの接続タイムアウトだけを延ばさないでください。

サブスクリプションの更新には、クライアントがURLへリクエストする、サーバーが内容を返す、クライアントが解析してノード一覧へ書き込むという3つの独立した段階があります。失敗メッセージは最後の結果しか示さないことが多いため、リクエストが実際に送信されたか、HTTPステータスが正常か、返された内容がクライアント対応形式かを確認します。ノード一覧が空でも、必ずしもネットワークの問題とは限りません。期限切れの内容、不完全なURL、ログインページの返却、すべてのノードを隠すフィルター、解析時の形式エラーなども原因になります。

まずURL自体を確認する

サブスクリプションURLをコピーし直すときは、提供元のページから完全コピーを行い、手入力で切り取らないでください。URL冒頭のプロトコル、パス、クエリパラメーター、末尾の文字を重点的に確認します。チャットアプリや文書エディターによって、区切り文字が別の記号へ置き換えられたり、末尾に句点、改行、空白が追加されたりすることがあります。URLに一時的な認証情報が含まれる場合は、公開ログやスクリーンショットに載せないでください。システム時刻も正確にします。一部のサブスクリプションサービスはリクエスト時刻を判定し、時刻のずれはHTTPS証明書の検証にも影響します。

v2rayNでは、まず指定したサブスクリプションだけを更新し、すべてのグループを同時に更新しないでください。失敗が特定URLの問題か、ネットワーク全体の問題かを確認できます。指定したサブスクリプションだけが失敗する場合は、エラーメッセージを保存し、ログのHTTPステータスを確認します。すべて失敗する場合は、システムプロキシ、直接接続、DNS、サブスクリプションリクエストがまだ使えないノードへ誤って送られていないかを確認します。提供元への到達性に応じて、直接接続で取得するか、既存のプロキシ経由で取得するかを選んでください。

curl.exe -L --connect-timeout 15 "https://example.com/subscription?token=xxxx" -o subscription.txt

コマンド内のURLはリクエスト構造を示す例にすぎません。実際の確認では、完全な認証情報を公共の端末に記録・共有しないでください。返されたファイルがHTMLのログインページ、エラー説明、空ファイルなら、クライアントはノードを生成できません。長いエンコード文字列やノードURLが返る場合は、クライアントが対応する形式かを確認します。HTTP 301、302はリダイレクトを示し、コマンドの -L はリダイレクトに従います。401、403は通常、認証情報、権限、リクエスト条件に関係します。404はパスが存在しないことを示し、429はリクエスト過多なので連続更新を止めて時間を置きます。5xxはサブスクリプションサービス側の一時的な異常である可能性が高いです。

内容は取得できたが解析に失敗する

ログにダウンロード成功と表示されてもノードが空の場合は、サブスクリプショングループのフィルター条件を確認します。正規表現の条件が厳しすぎると、すべてのノードが除外されます。重複排除ルールによって、名前が似たノードが統合されることもあります。まずフィルターを無効にして再更新し、元のノードが表示されるか確認します。表示されたら、フィルター条件を1つずつ戻してください。ノード名に括弧、プラス記号など正規表現の特殊文字が含まれる場合、そのままコピーしても文字どおりには一致しないことがあります。

サブスクリプションの返却形式とクライアントのコアは別の概念です。v2rayNはデスクトップ設定を管理し、v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。同じサブスクリプションに含まれる転送方式やプロトコルの一部が、特定のクライアントでしか認識されない場合があります。更新は成功したのに特定ノードのインポートに失敗する場合は、解析ログとノード種別を確認し、サブスクリプションを何度も削除しないでください。Androidではv2rayNGとv2flyNGを互換性比較に使えますが、2つのローカルVPNを同時に起動しないでください。

サブスクリプションURLが無効になった場合は、元の提供元から再取得し、tokenを自分で変更したりパスを推測したりしないでください。古いURLを削除してすぐ作り直しても、サーバー側の権限問題は解決しません。ブラウザでは取得できるのにクライアントで失敗する場合は、クライアントのユーザーエージェント制限、システムプロキシ経路、TLSログを確認します。クライアントでは成功するのにブラウザで失敗する場合は、ブラウザ拡張、キャッシュ、独立したプロキシ設定の違いが考えられます。ダウンロードページのよくある質問でクライアントの選択を確認し、本章に戻ってリクエスト、レスポンス、解析の3段階で切り分けてください。

修正後は「更新成功」という表示だけで判断せず、ノード数が妥当か、更新時刻が変わったか、古いノードが想定どおり置き換わったかを確認します。さらに2つのノードを無作為に開き、サーバーアドレスとプロトコルフィールドを照合してください。その後、1つのノードを選んで接続テストを行います。サブスクリプションの成功は設定データがクライアントに取り込まれたことを示すだけで、すべてのノードが接続できることを意味しません。接続に失敗したら、前章に戻ってタイムアウトとハンドシェイクを確認します。

速度の問題では、帯域不足、高い遅延、パケットロス、単一接続の制限、クライアントのリソース不足をまず区別します。ページの表示が遅いことは、ダウンロード帯域が低いことを意味しません。速度テストの結果が高くても、インタラクティブな遅延が安定しているとは限りません。確認時刻、対象ファイル、ネットワーク、ノードを固定し、少なくとも3回繰り返して、対象サイトの混雑や一時的な無線干渉をクライアントの問題と誤認しないようにします。複数の速度テストツールを同時に実行しないでください。帯域を奪い合い、結果が変わります。

直接接続とプロキシの2つの基準を作る

まずプロキシを無効にし、同じネットワークで直接接続の遅延、ダウンロード速度、パケットロスを測定してから、1つのノードを有効にして再測定します。直接接続自体が大きく変動するなら、Wi-Fiの電波、ルーターの負荷、LANケーブルのリンク速度、通信事業者側のネットワークを先に確認します。直接接続が安定しているのにすべてのノードが遅い場合は、ローカルCPU、ウイルス対策ソフトの通信スキャン、TUNドライバー、MTUを確認します。1つのノードだけが遅い場合は、ノードの回線、リモート側の負荷、ノードから対象サイトまでの経路が原因である可能性が高いです。

速度テストは小さなリクエストと継続的な転送の両方を行います。小さなリクエストではDNS、ハンドシェイク、最初のバイトまでの時間を確認し、継続転送では帯域の安定性を確認します。ページの初回表示だけ遅く後続リソースが正常なら、DNSまたはTLS接続に時間がかかっていることが多いです。ダウンロード開始時は速いのに徐々に低下する場合は、リモート側の速度制限、無線の混雑、パケットロスによる再送、CPU上限が考えられます。速度が周期的にゼロになって戻る場合は、ネットワーク切り替え、モバイル端末の省電力、接続の再確立を確認します。

転送方式、MTU、ルーティングを確認する

TUNモードでは仮想ネットワークアダプターとルーティング処理が増えます。システムプロキシでは速度が正常なのにTUNだけ明らかに遅い場合は、仮想ネットワークアダプターのドライバー、厳格なルーティング、IPv6、MTUを確認します。MTUが大きすぎると、断片化や一部経路でのパケットロスが起き、小さなリクエストは正常でも大きなレスポンスが止まることがあります。TUNインターフェースのMTUを段階的に下げて比較できますが、1回に1段階だけ変更し、変更後は再接続してください。MTUを下げすぎると余分な断片化で効率が落ちます。

ルールによる振り分けも「一部サイトが遅い」原因になります。対象ドメインは直接接続でも、ページ内の画像、スクリプト、APIはプロキシを通り、2つの出口でDNSと接続状態が異なるため、ページの待機として現れることがあります。コアのアクセスログを開き、同じページに関連するドメインがどの出力タグに一致したか確認します。一時的にグローバルプロキシへ切り替えて速度が戻るなら、ノード自体は使えるためドメインルールを修正します。グローバルモードでも遅い場合は、回線と転送パラメーターを引き続き確認します。GeoIPとGeoSiteデータが古いとルール分類がずれるため、更新方法はGeoIPとGeoSiteデータベースの更新方法を参照してください。

クライアントの暗号化、TLS、通信転送はCPUを使用します。低消費電力の端末やルーターでは、1つのコアが上限に達すると処理能力が帯域を制限します。デスクトップでは転送中のCPUとメモリを確認し、コアプロセスが継続的にリソースを使っているのか、ブラウザ、同期ソフト、セキュリティスキャンが使っているのかを切り分けます。CPUに余裕があるのに速度が低い場合、並列数や接続数を増やして無理に解決しないでください。高い並列度がパケットロスを悪化させることがあります。

無線ネットワークをテストするときは、できるだけアクセスポイントの近くで行い、大容量の同期処理を停止します。2.4GHzと5GHzで結果が大きく異なる場合は、まずローカルの無線環境を改善します。ネットワークを比較するときは種類と時間帯を記録し、条件の違う結果を直接プロトコルのせいにしないでください。調整後は元のルーティングモードに戻し、Web閲覧、動画、大容量ファイル、長時間接続をそれぞれテストします。特定の用途だけが異常なら、その対象と接続モデルを中心に分析します。

DNSの問題は、ドメインが開けない、同じサイトが時々使えない、プロキシ接続は成功するのに対象が誤って振り分けられる、ブラウザとコマンドラインで結果が異なる、といった形で現れます。確認すべきなのはDNSアドレスを単純に変えることではなく、「誰がクエリを発行し、どこへ送り、どのアドレスが返り、そのアドレスがルーティングにどう反映されたか」です。システムDNS、クライアント内蔵DNS、ブラウザのセキュアDNS、TUNによる横取りが同時に存在する場合があり、複数の解決経路によって結果が一致しなくなります。

まず名前解決の障害か判断する

クライアントを停止してシステムコマンドで対象ドメインを検索し、クライアントを起動して同じ検索を繰り返します。返されたIPv4、IPv6、解決時間を記録してください。システム検索は失敗するのに指定したパブリックDNSでは成功する場合、ローカルDNSまたはルーターに問題がある可能性があります。コマンドラインは成功するのにブラウザだけ失敗する場合は、ブラウザキャッシュ、独自DNS設定、拡張機能を確認します。名前解決は成功してもアクセスできない場合は、ログで実際に接続したアドレスが検索結果と一致するか比較します。

nslookup example.com
nslookup example.com 1.1.1.1
ipconfig /flushdns

nslookupは、システムまたは指定したサーバーの検索結果を確認するために使います。システムキャッシュの更新で消去されるのはOSが管理する記録だけで、ブラウザやクライアント内部のキャッシュは消えません。更新後はテストするアプリを完全に終了してから再起動します。クライアントでFakeDNSが有効な場合、予約アドレスが返ることがあります。これはマッピング機構の一部であり、通常のパブリックアドレスとして判断しないでください。その場合は、FakeDNSのマッピングがコアに引き継がれているか、対象の通信が対応するプロキシ入口へ入っているかを確認します。

DNSとルーティングの順序を理解する

ルーティングルールはドメイン名でも、解決後のIPアドレスでも一致させられます。コアに入る前にシステムがドメインを解決すると、コアにはIPしか見えず、ドメインルールが期待どおり機能しないことがあります。コアが解決を担当すれば、ドメイン情報を保持し、ルールに応じて異なるDNSや出力を選べます。設定時は解決方式を明確にし、互いに競合するシステムDNS、ブラウザDNS、クライアントDNSへ同時に依存しないでください。

以下は、サーバー一覧と検索ポリシーの構造を説明するための、簡略化したXray形式のDNS断片です。具体的なアドレスとポリシーは利用しているネットワークに合わせて調整してください。変更前に元の設定を保存し、GUIクライアントが設定保存時にファイルを再生成するか確認します。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ]
      }
    ],
    "queryStrategy": "UseIPv4"
  }
}

queryStrategyは返すアドレスの種類を制御します。IPv4のみに設定するとIPv6経路の異常を検証できますが、テストなしで長期固定しないでください。ネットワークが安定したIPv6に対応しているなら、デュアルスタックを維持するほうが適切な経路を選べます。IPv6アドレスはあるものの安定した出口がない場合、ドメインからAAAAレコードが返った後に長時間待たされることがあります。判断はネットワークアダプターにIPv6アドレスが表示されるかではなく、システムのルーティングと接続テストに基づいて行います。

DNSの振り分けでは、名前解決の出口とアクセスの出口を論理的に一致させます。ルールで直接接続するドメインには、直接接続のネットワークから安定して利用できるDNSを使い、プロキシ対象のドメインはコアからプロキシ出口経由で検索する構成が一般的です。先にローカルDNSで地域向けのアドレスを取得し、その後リモートプロキシへアクセスすると、対象から適切でないコンテンツノードが返されることがあります。反対に、すべてのドメインをリモートで解決すると、ローカルサービスまで不要なリモートアドレスへ解決される場合があります。ルールは実際のアクセス経路に合わせて設定してください。

少数のドメインだけが異常なら、まず明示的なドメインルールと指定DNSで最小限の検証を行い、すぐにDNS全体を書き換えないでください。ルールが有効だと確認してから、geosite分類へ範囲を広げます。データベースを更新した後は、ルール名がまだ存在するか、クライアントが正しいファイルを読み込んでいるかも確認します。データファイルの場所、読み込みの仕組み、更新後の検証方法については、GeoIPとGeoSiteデータベースの更新方法を参照してください。

最終確認には、システム検索、クライアントログ、実際のアクセスの3つを含めます。検索結果が安定しているか、ログに想定したDNSサーバーと出口が表示されるか、ブラウザが対応するアドレスへ接続しているかを確認します。3つが一致して初めて、名前解決経路が明確だといえます。ログに対象ドメインのDNSリクエストがまったくない場合は、コアの外側で検索されている可能性があるため、システム、ブラウザ、TUNの接管設定に戻って確認します。

システムプロキシは、OSへプロキシのアドレスとポートを書き込む仕組みです。これらの設定を読み取るアプリだけが利用します。クライアントに「システムプロキシ有効」と表示されても、すべてのプロセスの通信が接管されるわけではありません。ブラウザは通常システムプロキシに対応しますが、一部のコマンドラインツール、ゲーム、ストアアプリ、独自のネットワークスタックを持つソフトは無視することがあります。特定のアプリで機能しない場合は、まず他のアプリが正常か確認し、システム設定の書き込み失敗なのか、対象アプリがシステムプロキシを使っていないのかを判断します。

ローカル入口とシステム設定を照合する

v2rayNでHTTPとSOCKSのインバウンドポートを記録し、システムプロキシが 127.0.0.1 と正しいポートを指しているか確認します。ポートが他のプログラムに占有されていないこと、リモートノードのポートを誤って入力していないことも確認してください。前章の netstat コマンドで待ち受けプロセスを確認し、明示的なプロキシパラメーターでテストします。明示的なプロキシでは成功するのにブラウザで失敗する場合、コアとノードは正常で、問題はシステムプロキシの書き込み、ブラウザのポリシー、拡張機能にあります。

curl.exe -x http://127.0.0.1:10809 https://example.com/
curl.exe --socks5-hostname 127.0.0.1:10808 https://example.com/

1つ目はHTTPプロキシでテストし、2つ目はSOCKS5を使い、プロキシ側でドメインを解決させます。2つのポートはクライアントの実際の設定に置き換えてください。HTTPは成功してSOCKSが失敗する場合はSOCKSインバウンドを確認し、SOCKSは成功してHTTPが失敗する場合はHTTPインバウンドまたは混合ポートを確認します。両方とも成功するのに対象アプリで機能しない場合、アプリがシステムプロキシを読み取っていないか、アプリ内設定がシステム設定を上書きしている可能性があります。

ブラウザのプロキシ拡張機能がシステムプロキシを上書きすることがあります。確認時は一時的に拡張機能を無効にし、すべてのブラウザプロセスを終了してから再起動します。一部のブラウザのセキュアDNSは独自に名前解決するため、HTTP通信がシステムプロキシを通っていてもDNSが別経路になり、結果が異なることがあります。企業ポリシー、家庭向けセキュリティソフト、ネットワークフィルタリングツールがプロキシ設定を書き換える場合もあるため、有効化直後に設定が戻っていないか確認します。

システムプロキシとTUNを区別する

システムプロキシはHTTPまたはSOCKSプロキシに対応するアプリに適し、対象範囲が明確で問題が起きても戻しやすい方式です。TUNモードは仮想ネットワークアダプターとルーティングによって、システムプロキシを読み取らないプログラムを含む広い通信を接管しますが、DNSの横取り、ルーティング優先順位、MTU、ドライバー互換性の問題が加わります。1つのアプリがシステムプロキシを無視するからといって、すぐにTUNを常用しないでください。まずアプリに独自のプロキシ設定があるか確認し、本当に全体を接管する必要がある場合だけ最小構成でTUNを有効にします。

TUNを有効にして完全に接続できなくなった場合は、まずシステムプロキシを無効にし、2つの接続経路が重ならないようにします。その後、仮想ネットワークアダプターが正常に作成されたか、デフォルトルートが書き込まれたか、ローカルネットワークのセグメントが誤ってプロキシへ送られていないかを確認します。リモートデスクトップ、LAN共有、ルーター管理アドレスは直接接続のルールに残してください。TUNを有効にした後、ローカル接続を失うことがあります。他の仮想ネットワークアダプターがある場合は、ルーティング優先順位を確認します。特にコンテナ、仮想マシン、企業ネットワークソフトが作成したインターフェースに注意してください。

クライアント終了後もブラウジングできない場合は、システムのネットワーク設定で手動プロキシを無効にし、自動構成スクリプトが古いアドレスを指していないか確認してからブラウザを再起動します。プロキシ設定が繰り返し戻る場合は、スタートアップ項目や他のネットワークツールを確認してください。v2rayNではウィンドウを閉じるだけでなく「システムプロキシをクリア」を使います。ウィンドウを閉じてもトレイに最小化され、コアが動き続けている場合があるためです。

修正後は、システムプロキシに従うブラウザ、明示的なプロキシパラメーターを付けたコマンドラインリクエスト、以前問題があったアプリをそれぞれ確認します。3つの結果から、問題がシステム設定にあるのかアプリ自身にあるのかを判断できます。3種類のプロキシ方式の通信範囲と選び方については、システムプロキシ、グローバルモード、中国本土を迂回するモードの違いも参照してください。

クライアントウィンドウの終了、コアプロセスの終了、画面の無応答は、互いに異なる3種類の問題です。ウィンドウのクラッシュはグラフィックランタイム、設定データベース、画面コンポーネントに関係することがあります。コアの終了は、生成された設定の無効、ポート競合、コアファイルの実行不可、システム権限が原因になることが多く、画面が応答しない場合は大量のノード、ログ更新、サブスクリプション解析、セキュリティソフトのスキャンが影響している可能性があります。確認前に、終了したのがGUIクライアントなのかコアプロセスなのかを特定してください。

ログと再現条件を保存する

最初のクラッシュ直後に設定を消去したり、何度も再インストールしたりしないでください。コアの起動、サブスクリプション更新、設定画面の表示、TUNの切り替え、設定のインポートなど、どの操作で発生したかを記録します。クライアントログ、コアログ、システムイベントの時刻を保存し、そのときのルーティングモードとノード種別も記録してください。再現できる問題は偶発的なクラッシュより特定しやすく、毎回同じ操作で起きるなら、その操作が読み込む設定やシステムコンポーネントを優先して確認します。

v2rayNの起動後にコアがすぐ終了する場合は、まずシステムプロキシを無効にし、ローカルポートの停止による接続断を防ぎます。コア出力の最初のエラーを確認してください。よくある種類は、JSON構文エラー、フィールド型の誤り、存在しないルーティングタグ、インバウンドポートの競合、ファイルアクセスの失敗です。その後に続く大量の再試行は、結果として発生しているだけの場合があります。GUIで設定を生成している場合は、デフォルトルーティングとデフォルトDNSに戻し、通常のサブスクリプションノードを1つ選んで、カスタム設定が原因か判断します。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks"
    }
  ]
}

上の断片は、フィールドの型とJSONの句読点を確認するための、正しいSOCKSインバウンド構造の例です。完全なアウトバウンド設定ではありません。JSONでは末尾のカンマは使えず、文字列は二重引用符で囲み、ポートは数値にします。手動設定の検証に失敗した場合は、まずクライアントが自動生成した設定へ戻し、複数箇所を重複して編集しないでください。GUIクライアントは起動時に一時ファイルを上書きすることがあり、生成ファイルを直接編集しても恒久的な設定にはなりません。

ポート、権限、実行環境

ポート競合があると、コアは待ち受けを開始できません。netstat -anoで占有プロセスを調べたら、その用途を確認し、ネットワークプロセスをすべて終了しないでください。クライアントでローカルのインバウンドポートを変更して検証できます。新しいポートで起動できるなら、元のポートが使用中です。そのまま新しいポートを使うか、競合するプログラムを終了するか決めます。ポートを変更した後は、システムプロキシとアプリ内プロキシのアドレスも同期して変更しないと、古いポートへの接続が続きます。

デスクトップクライアントは対応する実行環境に依存します。ウィンドウがまったく開かず、システムイベントにランタイムエラーが記録される場合は、Windowsインストールパッケージのページでデスクトップ版と従来のWPF版の適用条件を確認し直してください。異なるディレクトリのプログラムファイルと設定ファイルを混在させたり、一部のファイルだけを上書きしたりしないでください。更新時はクライアントとコアを正常終了し、設定のバックアップを保存してから、新しいインストールパッケージを独立したディレクトリに置いてテストします。

セキュリティソフトがコアのプロセス作成、ローカルポートの待ち受け、仮想ネットワークアダプターの作成を阻止することがあります。ブロック履歴とファイルの入手元を確認し、必要なプログラムだけを最小限の範囲で許可してください。長期的な対策としてシステム保護をすべて無効にしないでください。通常モードでは正常なのにTUNモードでクラッシュする場合は、仮想ネットワークアダプターのドライバー、管理者権限、他のネットワークフィルタードライバーを重点的に確認します。サブスクリプション更新時だけ応答しない場合は、ノード数、フィルター式、返却内容を確認します。

設定ファイルが壊れた場合は、元のディレクトリをバックアップしてから新しい設定を作成し、クライアントにデフォルトファイルを生成させ、ノードを1つだけ手動で追加してテストします。新しい設定が正常なら、サブスクリプション、ルーティング、各設定を1つずつ移行し、古いディレクトリ全体を直接コピーしないでください。ある項目を移行した後に再びクラッシュすれば、原因を特定できます。新しい設定でもクラッシュする場合は、実行環境、権限、グラフィックドライバー、システムログを確認します。

トラブル解決後は、コールドスタート、サブスクリプション更新、ノード切り替え、システムプロキシの有効化、正常終了の5つを検証します。正常終了後にシステムプロキシが消去されたことを確認し、再起動後に設定を読み込めることを確認してください。1回接続に成功しただけでは、設定データベースと終了処理が正常とは限りません。Windowsのインストールと実行環境については、v2rayN Windowsインストール・設定完全ガイドも参照してください。

Androidのv2rayNGとv2flyNGは、システムVPNインターフェースを通じて通信を接管します。そのため、ノード設定だけでなく、バックグラウンド制限、プライベートDNS、バッテリー設定、ネットワーク切り替え、他のVPNアプリも原因になります。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。2つは異なるコアの互換性を比較するために使えますが、同時に有効にできるVPN接続は1つだけです。確認時はもう一方のクライアントを完全に停止し、画面をバックグラウンドへ移すだけにしないでください。

接続ボタンは成功するがアプリからアクセスできない

まずステータスバーにVPNアイコンが表示されているか確認し、クライアントログでローカルVPNインターフェースが作成されたか確認します。アイコンが表示されない場合は、システム権限の許可が未完了、既存VPNが使用中、クライアントがシステムにブロックされている可能性があります。アイコンがあるのにすべてのアプリが接続できない場合は、ノード、DNS、ルーティングを確認します。一部のアプリだけが異常なら、アプリ単位のプロキシ、除外リスト、アプリ独自のネットワーク設定を確認してください。

アプリ単位のプロキシ設定は、モードの理解を誤ると逆の結果になります。「選択したアプリのみプロキシ」と「選択したアプリを迂回」は意味が反対です。アプリの更新や再インストール後に、アプリ識別子が変わることもあります。確認時はまずアプリ単位の機能を無効にし、すべてのアプリを同じ経路で通信させます。基本接続が正常になってから、対象を1つずつリストへ追加してください。有効化後もアプリが直接接続する場合は、独立したプロセス、システムコンポーネント、内蔵サービスを使っていないか確認します。

AndroidのプライベートDNSがクライアントのDNS接管と競合することがあります。ノードは接続済みと表示されるのに、ドメインリクエストが長時間待機し、IPアドレスへの直接アクセスだけが正常になるのが典型です。検証のため、プライベートDNSを一時的に自動へ戻してクライアントを再接続します。問題が解消するなら、システムのプライベートDNSとクライアントのどちらに名前解決を任せるか決め、両者を不明確に連結しないでください。ブラウザ自身がセキュアDNSを有効にしている場合もあるため、個別に確認します。

バックグラウンド切断とネットワーク切り替え

画面ロック後の切断は、バッテリー最適化、バックグラウンド活動の制限、システムによるアプリの終了が原因であることが多いです。使用中のクライアントにバックグラウンド実行を許可し、省電力モードがVPNを制限していないか確認します。設定名は端末によって異なりますが、目的は画面ロック後もクライアントとコアプロセスが通信を維持できるようにすることです。同種のクライアントを複数、自動起動や常駐に設定しないでください。VPN権限を奪い合い、状態が不安定になることがあります。

Wi-Fiからモバイルネットワークへ切り替えると、既存接続のローカルアドレスとルーティングが変わります。自動再接続できるノードもあれば、古いネットワーク上に接続が残ることもあります。切り替え後に通信できない場合は、クライアントで接続を停止し、システムのネットワークが安定してから再起動します。頻繁に起きる場合は、ログにネットワーク利用不可、インターフェース切断、DNSタイムアウトがないか確認します。「ネットワーク切り替え後の失敗」と「固定ネットワークで継続する失敗」は分けて記録してください。対処の方向が異なります。

サブスクリプションの更新に失敗した場合は、まず現在のネットワークでブラウザからサブスクリプションリクエストを開けるか確認し、その後クライアントの更新ログを確認します。モバイルネットワークでは、バックグラウンド通信、ローミングデータ、省データモードが制限されていることがあります。サブスクリプションは成功したのにノードへ接続できない場合は、本マニュアルのタイムアウト章でアドレス、ポート、TLS、転送フィールドを確認します。2015年以降の主流端末では、通常arm64パッケージを優先します。アーキテクチャが分からない場合はユニバーサル版を使用できます。詳しい入口はAndroidクライアントのダウンロードを参照してください。

v2rayNGとv2flyNGでは、コアの対応範囲が異なります。あるノードがv2rayNGでは使えるのにv2flyNGで失敗しても、すぐにネットワークが原因だと判断せず、対応するコアがプロトコルと転送フィールドをサポートしているか比較します。比較テストでは、同じネットワーク、同じノード、同じDNS条件を使い、もう一方のクライアントを完全に停止してください。両方で失敗するならノードとシステムネットワークを確認し、片方だけが失敗するなら、そのクライアントの最初のコアエラーを保存して互換性を判断します。

モバイル端末の最終確認には、前面表示でのアクセス、画面ロックからの復帰、Wi-Fiとモバイルネットワークの切り替え、サブスクリプション更新、アプリ単位のルールを含めます。すべてのシステム設定を一度に変えず、各項目を個別にテストしてください。基本接続が安定してから、プライベートDNS、省電力設定、アプリのリストを戻します。ある項目を戻した後に問題が再現すれば、競合元を特定できます。初回のサブスクリプション読み込みがまだ完了していない場合は、クイックスタートガイドへ戻って基本手順で設定し、初期化の未完了を動作障害と取り違えないようにしてください。