システムリファレンス

V2Rayトラブルシューティング：症状から接続問題の原因を特定

ネットワークの基準状態を確認し、ノード、サブスクリプション、ルーティング、DNS、システムプロキシ、クライアントの動作状態を順に調べます。Windows、macOS、Android、Linuxのv2rayN、およびAndroidのv2rayNG、v2flyNGに対応しています。

まず基本設定を完了してください：使い方ガイドではサブスクリプションの追加、ノード選択、初回接続を扱います。このページでは接続に失敗した後、症状から原因を追跡します。クライアントを再インストールする場合は、クライアントダウンロードからプラットフォームに合ったインストールファイルを選択してください。

章の目次

01 ローカルネットワークを確認

まず、ネットワーク切断、スリープ復帰後の不具合、時刻のずれ、他のプロキシソフトによるポート占有を除外します。

02 クライアントのログを確認

タイムアウト、接続拒否、証明書エラー、名前解決失敗、設定エラーを区別します。

03 問題の範囲を絞り込む

単一ノード、グローバルルーティング、デフォルトDNS、1台の端末に固定して、項目ごとに再テストします。

症状 01

クライアントは接続済みだが、ウェブページを開けない

まず「ローカルのネットワーク断」と「プロキシ経路の切断」を切り分ける

クライアントのトレイアイコンが動作中でも、グラフィカルインターフェースとコアプロセスが起動したことしか示さず、通信がリモート側へ届いている証明にはなりません。調査時は、まずシステムプロキシまたはAndroidのVPN接続を一時的に無効にし、ローカルネットワークで通常利用できるサイトへアクセスします。クライアントを終了してもアクセスできない場合、問題は現在のWi-Fi、LANケーブル、モバイル通信、ゲートウェイ、またはシステムのネットワークスタックにあります。ノード設定を変更し続けるのは適切ではありません。ネットワークへの再接続、ネットワークアダプターの無効化と再有効化、別のネットワークでの再テストのほうが、サブスクリプションを何度も追加するより早く解決できることが多いです。

直接接続が正常で、プロキシを有効にするとすべてのサイトで失敗する場合は、次にクライアントのログを確認します。v2rayNではログ領域からXrayの起動状況と接続記録を確認できます。v2rayNG、v2flyNGではログ画面を開いてから、対象アドレスへもう一度アクセスします。重要なのはログの行数ではなく、最初に現れたエラーです。connection refusedは対象ポートが明確に接続を拒否していることを示す場合が多く、timeoutは制限時間内にハンドシェイクが完了しなかったことを示します。no such hostはドメイン名の名前解決、certificateまたはhandshakeはシステム時刻、SNI、トランスポートのセキュリティ設定を確認する手がかりです。

最小構成でルーティングルールの影響を切り分ける

複雑なルーティングでは、ブラウザーの通信が利用できないアウトバウンドへ振り分けられたり、本来プロキシで処理すべきドメインが誤って直接接続へ送られたりします。まず確実に使えるノードを1つだけ残し、ルーティングモードを一時的にグローバルプロキシへ切り替え、追加のカスタムルール、チェーンプロキシ、Mux、実験的なDNS機能を無効にして、通常のHTTPSページをテストします。グローバルモードでは使えるのにルールモードで使えない場合、問題はノードではなくルールのマッチングにあります。ルールを戻すときは一度に1組だけ有効にし、変更のたびに新しい接続を確立してください。ブラウザーが古いTCPまたはHTTP/3セッションを再利用するのを防ぐためです。

グラフィカルインターフェースのルーティングルールは、最終的にXrayの設定へ変換されます。ルールはクライアントが生成した順序で照合され、ドメイン、IP、ポート、ネットワーク種別が同時にアウトバウンドを決める場合があります。以下の最小構造では、プロキシと直接接続の2つのアウトバウンドだけを残し、問題の範囲を理解できるようにしています。実際のクライアントでは、受信待ち受けやノードの認証情報などが追加されます。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {}
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

ポートの使用状況、時刻、残留プロセスを確認

デスクトップクライアントは、ローカルでSOCKS、HTTP、または混合プロキシのポートを待ち受けます。同じポートを別のプロキシソフト、古いコアプロセス、デバッグツールが使用していると、新しいコアの起動に失敗しても、画面には前回の状態が残ることがあります。Windowsではターミナルでnetstat -anoを実行し、待ち受けポートとプロセス番号を確認できます。macOSとLinuxではlsof -iTCP -sTCP:LISTENを使用できます。競合が見つかったら、関連するプログラムを終了してからクライアントでコアを完全に再起動してください。ノードを切り替えるだけでは解決しません。

netstat -ano | findstr LISTENING
lsof -iTCP -sTCP:LISTEN
date

システム時刻も正確でなければなりません。TLS、REALITY、サブスクリプションサーバーへのHTTPS接続はいずれも、時刻を使って通信の有効性を判断します。時刻が大きくずれていると、すべてのノードが同時に失敗する、サブスクリプションを更新できない、証明書がまだ有効でない・期限切れといったメッセージがログに繰り返し出るなどの症状が現れます。自動時刻合わせを有効にしたら、クライアントを完全に終了して再起動し、補正後の時刻で新しい接続を作成します。ここまで問題がなければ、ダウンロードページでプラットフォームに合ったクライアントを使用していることを確認し、最小構成を作り直します。大量の古い設定をそのまま上書きするのは避けてください。

症状 02

ノードの遅延テストがタイムアウトする、または接続を拒否される

遅延テストの結果は、実際のウェブ閲覧速度とは異なる

v2rayNの遅延テストでは、TCP接続、実際の遅延、その他の可用性チェックなど、複数の方式が使われる場合があります。方式によって確認できる内容は異なります。TCP接続が成功しても、リモートアドレスとポートで基本的なハンドシェイクが完了したことを示すだけで、プロトコル認証、TLS、REALITY、対象サイトへのアクセスまで成功するとは限りません。実際の遅延テストはより多くの処理を経ますが、テスト先、DNS、現在のルーティングの影響も受けます。そのため、1つのタイムアウト表示だけでノードを削除すべきではありません。まずテスト方式を確認し、実際にウェブページへアクセスしたうえで、ログからタイムアウトが名前解決、リモート接続、TLSハンドシェイク、アウトバウンドアクセスのどの段階で発生したかを判断します。

同じサブスクリプション内で1つのノードだけがタイムアウトし、他のノードは正常な場合、通常はそのノードのアドレス、ポート、トランスポート設定、またはサービス状態に問題があります。すべてのノードが同時にタイムアウトする場合は、ローカルネットワーク、システム時刻、DNS、コアの起動、ネットワーク環境の変化が原因である可能性が高くなります。特定のネットワークだけで全て失敗し、別のネットワークでは復旧するなら、現在のルーター、ファイアウォール、企業ネットワークのポリシー、UDPの利用可否を優先して確認します。すべてのノードを同時に変更するのは避けてください。

アドレス、ポート、トランスポート設定を順に照合

ノードを手動設定する場合、サーバーアドレスにプロトコルの接頭辞、パス、余分な空白を含めないでください。ポートは整数で指定し、UUID、ユーザー識別子、パスワードなどの認証項目は完全にコピーします。VLESSとVMessは互換プロトコルではありません。TCP、WebSocket、gRPCなどのトランスポートも、ポート番号だけから推測することはできません。TLSを使用する場合はサーバー名とホスト項目を照合し、REALITYでは公開鍵、短い識別子、フィンガープリント、サーバー名も一致させる必要があります。どれか1つでも一致しないと、ハンドシェイクのタイムアウトや、接続直後の切断として現れることがあります。

WebSocketノードでは、パスとHostも確認します。パスは通常スラッシュで始まり、大文字・小文字や追加のクエリ部分もサーバー側の照合に影響する場合があります。gRPCではサービス名を確認し、WebSocketのパス欄に入力しないでください。ノードがサブスクリプション由来なら、手動で「修正」するより、まずサブスクリプションを再更新するのが基本です。提供元がパラメーターを変更している可能性があるためです。再追加前に現在のサブスクリプショングループをコピーして記録しておくことはできますが、同名ノードを2つ同時に自動選択へ参加させないでください。テスト対象が分からなくなります。

ログに現れる症状 主な原因 優先する対応
i/o timeout リモートアドレスに到達できない、ポートが遮断されている、ハンドシェイクに応答しない ネットワークを切り替えて再テストし、アドレスとポートを確認してからトランスポート設定を調べる
connection refused リモートポートが待ち受けていない、またはローカルから誤ったポートへ接続している サブスクリプションを更新してポートを照合し、タイムアウト時間を延ばして隠さない
bad certificate システム時刻、SNI、証明書名、証明書チェーン まず自動時刻合わせを行い、その後サーバー名を照合する
EOF 相手側が先に接続を閉じた、トランスポート設定が一致していない プロトコル、セキュリティ方式、パス、サービス名を照合する

タイムアウト時間を延ばすだけで原因究明の代わりにしない

接続タイムアウトを数秒から長時間へ延ばしても、利用できないノードの失敗通知が遅くなるだけで、プロトコルやポートの誤りが直ることは通常ありません。適切な再テストでは、ノードを1つに固定し、自動切り替えを無効にして新しい接続を確立し、接続ボタンを押してから最初のエラーログが出るまでに何が起きたかを確認します。TCP接続はできるのにTLSハンドシェイクで失敗するならSNIと時刻を、TLS完了後に認証で失敗するならユーザー識別子とプロトコルを重点的に調べます。プロキシ接続後に特定サイトだけタイムアウトするなら、ルーティング、DNS、MTU、対象側の接続問題を確認します。

UDPを使う場面は別途判断が必要です。ネットワークによってはUDPが不安定で、ブラウザーがHTTP/3を優先したり、DNSがUDPで問い合わせたりするため、「一部のページだけ読み込みが続くが、通常のTCPテストは正常」という症状が出ます。一時的にブラウザーのHTTP/3を無効にし、DNSをTCPまたはHTTPS方式へ変更して、問題が消えるか確認できます。UDPだけが失敗する場合、ノード全体を完全に利用不可と判断せず、実際の用途に合わせてトランスポート方式とルーティングを調整します。

自動選択や負荷分散は、調査時の変数を増やします。テスト中は1つのアウトバウンドに固定し、クライアントが複数ノードを切り替えないようにします。単一ノードが安定してから自動選択へ戻してください。あるノードがデスクトップとAndroidの両方で失敗し、しかも2台が異なるネットワークを使っているなら、ノード設定またはリモート側の状態である可能性が高くなります。同じノードが1台の端末だけで失敗する場合は、両端のコア種類、ルーティングルール、DNS設定、システム時刻を比較します。同じサブスクリプションを何度も追加したり、すぐに再契約したりする必要はありません。

症状 03

サブスクリプション更新に失敗する、一覧が空になる、または読み込み内容が欠ける

サブスクリプションURLと単一ノードの共有リンクを区別する

サブスクリプションURLは通常、複数のノードデータを返し、クライアントに保存したURLから再更新できます。一方、vmess://やvless://などで始まる共有リンクは、通常1つのノードだけを記述します。単一ノードのリンクをサブスクリプション管理へ登録すると、形式エラーになったり、更新後に一覧が表示されなかったりします。逆に、サブスクリプションURLを単一ノードのQRコードとして読み込んでも解析できない場合があります。違いは共有リンクとサブスクリプションURLの解説で確認できます。調査時は、コピーしたURLが完全で、チャットアプリによる改行や途中での切り詰め、末尾パラメーターの欠落がないことを確認してください。

サブスクリプション更新には2つの接続があります。まずクライアントがサブスクリプションサーバーへアクセスして内容を取得し、その後、内容を解析してノードを生成します。ダウンロード段階で失敗すると、DNS、TLS、HTTPステータス、接続タイムアウトなどがログに現れます。ダウンロードは成功したのに解析で失敗する場合は、未対応形式、データが空、個別項目の異常などが示されます。まずどちらの段階のエラーかを記録すると、ネットワーク問題をノード形式の問題と誤認せずに済みます。

システムプロキシとサブスクリプション更新経路を確認

サブスクリプション更新は直接接続で行われる場合も、現在のプロキシを経由する場合もあります。サブスクリプションURLがプロキシ接続時のみアクセス可能なのに、現在のノードが無効だと、「ノードを更新するには先にノードが必要」という循環が起こります。その場合は、まだ使える古いノードへ切り替えてから更新します。クライアントのサブスクリプション更新用プロキシ設定も確認し、システムプロキシ、現在のプロキシ、直接接続のどれを使うかを明確にしてください。意味を理解しないまま多重プロキシを有効にすると、リクエストが本機のプロキシポートへ戻ってループすることがあります。

逆に、サブスクリプションサーバーへ直接アクセスできるのにプロキシ経由で失敗するなら、一時的に直接接続で更新します。更新後すぐに古いグループを削除せず、新しい一覧に想定したノードが含まれていることを確認してから重複を整理します。複数のサブスクリプションは、「すべて更新」より1つずつ更新したほうが、失敗したURLを特定しやすくなります。サブスクリプション名はローカル上のラベルにすぎず、接続には関与しません。確認すべきなのはURL、更新方式、要求されるUser-Agent、返却内容です。

HTTPステータスと返却内容で原因を特定

ステータスコードから責任範囲をすばやく切り分けられます。401または403は、URL内のトークン、パス、アクセス条件が無効になったことを示す場合が多く、404はリンクの置き換えやコピー誤りでよく発生します。429は短時間にリクエストが多すぎる状態なので、連続更新を止めてしばらく待ちます。5xxはサブスクリプションサーバー側の一時的な障害であり、クライアントを何度も再インストールしても通常は解決しません。200なのに一覧が空の場合は、返されたものがノードテキスト、ウェブページの案内、ログイン画面のどれかを確認します。グラフィカルクライアントでは「解析失敗」としか表示されなくても、詳細ログにはレスポンスの種類やデコードエラーが記録されていることがあります。

デスクトップではシステム標準のツールを使ってレスポンスヘッダーだけを確認し、サブスクリプションの内容全体を共有画面や公開ログへ出力しないでください。以下のコマンドのURLはローカルでの例にすぎず、実際のサブスクリプション情報は含まれていません。

curl -I "https://example.invalid/subscription"
nslookup example.invalid

ドメインを解決できない場合は、このページのDNS章を確認します。TLSエラーが出る場合は時刻を補正し、証明書名を確認してください。レスポンスは正常なのにクライアントの解析だけ失敗する場合は、新しい空のサブスクリプショングループを作成し、そのURLだけを追加して、古いキャッシュや同名ノードの影響を切り分けます。v2rayN、v2rayNG、v2flyNGでは、一般的な共有形式の処理が異なる場合があります。同じサブスクリプションでクライアントごとに差が出るときは、端末のネットワーク障害と決めつけず、対象クライアントが認識できない拡張フィールドを含んでいないか確認してください。

更新後もノード一覧が変わらない場合の対処

更新は成功したのに一覧が変わらないように見える場合、サブスクリプションが実際に同じ内容を返しているか、クライアントがカスタムノードの保持、備考による統合、キャッシュ表示を有効にしている可能性があります。まずノード数、備考、サーバーアドレスを比較し、一覧画面を完全に終了してから開き直します。サブスクリプションキャッシュの削除や古いノードを保持しない設定があれば、バックアップを確認したうえで使用します。ノード名だけで更新を判断しないでください。提供元が名前を維持したままアドレスを変更することも、名前を変更して同じ接続パラメーターを維持することもあります。

システム時刻の誤りによって、HTTPSサブスクリプションとノード接続が同時に失敗することもあります。見落とされやすい共通原因です。すべてのサブスクリプションが突然証明書エラーになり、すべてのTLSノードが利用できなくなった場合は、まず時刻を同期してからクライアントを再起動します。1つのサブスクリプションだけが失敗する場合は、そのURLを重点的に確認します。更新後は新しいノードを手動で1つ選び、実際にアクセスしてください。自動選択が削除済みノードのキャッシュ参照を使い続けないようにします。

症状 04

接続はできるが速度が遅い、動画がバッファリングする、ダウンロード速度が変動する

速度の問題を遅延、スループット、安定性に分ける

「速度が遅い」には少なくとも3種類の現象があります。ウェブページの初回表示に時間がかかる場合は、DNS、接続確立、遅延が関係することが多く、大容量ファイルの継続的なダウンロード速度が低い場合は、回線のスループット、混雑、端末性能に近い問題です。速度が大きく上下したり、動画が周期的にバッファリングしたりする場合は、パケットロス、無線干渉、ノード負荷、プロトコルの再送、バックグラウンド通信を確認します。1回の遅延値だけでは全体を説明できません。同じ端末、同じローカルネットワーク、近い時間帯で2つのノードを比較し、ルーティング、DNS、テスト対象を揃えてください。

テスト前に、クラウド同期、システム更新、ゲームプラットフォームのダウンロード、他の端末による大容量通信を一時停止します。無線ネットワークではルーターの近くで一度テストし、その後LANケーブルまたは別のネットワークで再確認します。直接接続のダウンロード自体が遅いなら、プロキシでローカル回線のボトルネックを解消することはできません。直接接続は安定しているのにすべてのノードで変動するなら、本機のプロキシ経路、MTU、コア負荷、ネットワークのUDP処理を確認します。1つのノードだけが遅いなら、ノードの回線またはリモート側の負荷である可能性が高いです。

ルーティングによる迂回を確認

ルールモードでは、ドメイン、IP、ポート、プロトコルに基づいてアウトバウンドを選択します。ドメインがローカルでIPへ解決された後、domainStrategyとルールセットの組み合わせが適切でないと、同じサイトのトップページ、画像、動画が別々のアウトバウンドを通り、ページは開くのにメディアだけ遅いという症状が出ます。調査時は一時的にグローバルプロキシを使い、同じリソースを比較します。グローバルモードで明らかに改善するなら、ルールの優先順位、ドメインルールとIPルールの競合、DNSの返却結果が想定どおりかを確認します。

ルーティングルールは多ければよいわけではありません。重複するルールが多いほど保守が難しくなり、古いルールセットが新しいドメインを不適切なアウトバウンドへ送ることもあります。まずクライアント内蔵の簡潔なルールセットで基本接続が安定することを確認し、その後必要なカスタム項目を追加します。一度に1組だけ追加し、ログで対象ドメインが最終的にどのアウトバウンドタグを使ったか確認してください。アプリがIPへ直接接続する場合、ドメインルールはマッチしないことがあります。その場合はアプリの特性、対象IP、ポートに基づいてルールを設計しますが、広すぎるネットワーク範囲で無関係な通信までプロキシへ送らないよう注意します。

Mux、同時接続数、トランスポート方式の選び方

Muxは複数の論理接続で下位の接続を共有する機能です。特定の高遅延環境では、繰り返し行われるハンドシェイクを減らせますが、スループットの向上を保証するものではありません。長時間の大容量通信では、共有接続のパケットロスが複数のリクエストへ影響することがあります。また、サーバー側の設定によっては、クライアントだけで有効にするのが適切でない場合もあります。速度を調べるときはまずMuxを無効にして基準値を取り、その後Muxだけを有効にして比較します。無効時のほうが安定するなら無効のままにし、短時間の接続が多い環境で明らかに改善するなら有効化を検討します。Mux、同時接続数、分割転送、DNS、ルーティングを同時に変更しないでください。どの変更が効果を生んだのか分からなくなります。

WebSocket、gRPC、TCPなどのトランスポート方式はサーバー側の設定で決まり、クライアントで適当に切り替えても「高速化」にはなりません。パラメーターが一致しなければ通常は速度が上がるのではなく、接続そのものに失敗します。REALITYとTLSが解決するのはハンドシェイクと安全な通信の条件であり、速度を上げる機能ではありません。スループットに実際に影響するのは、ローカル回線の品質、端末のCPU、リモート側の容量、回線混雑、パケットロス、往復時間、アプリ自身の同時接続戦略などです。

端末リソースとMTUの症状を確認

性能の低い端末では、高スループットの暗号化、複雑なルール、大量の同時接続によってCPU使用率が上がることがあります。デスクトップではタスクマネージャーやシステムモニターを同時に確認し、Androidでは端末の発熱とバックグラウンド制限に注目します。速度上昇時にCPUがほぼフル稼働するなら、複雑なルーティングを減らし、不要なログや同時接続機能を無効にして、異なるコアクライアントの動作を比較します。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用するため、Android上での比較対象にできます。ただし、ノードのプロトコルが各コアでサポートされている必要があります。

MTUの問題では、小さなウェブページは開けるのに、大きな画像、アップロード、特定のHTTPSページだけが停止することがあります。VPN、トンネル、一部のブロードバンド接続が重なると、実効パケットサイズが小さくなる場合があります。まずネットワークを切り替えて確認します。同じ端末が別のネットワークでは正常なら、元のネットワークのMTUまたはルーターを調べる価値があります。Linuxではフラグメントを許可しないpingでパケットサイズを段階的に小さくできますが、システムごとにオプションが異なり、対象が応答するかどうかにも左右されるため、あくまで手がかりです。通常の速度変動だけを理由に、グラフィカルクライアントの基盤MTUを変更する必要はありません。まず症状がネットワークに関連することを確認し、その後システムまたはルーター側で慎重に調整します。

最終比較では、同じファイル、同じ時間帯、少なくとも数分間の継続通信を使い、平均速度と中断状況を記録します。1回だけのピーク値には代表性がありません。ノードが安定したら、ルールモード、自動選択、普段のDNS設定を戻し、項目を1つ復元するたびに再テストします。こうすれば性能低下がノード由来かローカル設定由来かを判断できます。

症状 05

DNSの名前解決に失敗する、汚染されたキャッシュが残る、一部のドメインを開けない

DNS障害が起きる典型的な境界を見分ける

DNSはドメイン名をIPアドレスへ変換します。名前解決に失敗すると、既知のIPへ直接アクセスすれば応答があるのに、ドメイン名ではサーバーが見つからないと表示されることがあります。不適切なアドレスへ解決されると、接続タイムアウト、証明書名の不一致、ネットワークごとに同じサイトの挙動が異なるといった症状が出ます。すべてのサイトで失敗する場合、すぐにDNSと決めつけないでください。ローカルのプロキシポート、ノード、システムプロキシでも全面的な接続不能は起こります。ドメインを個別に問い合わせ、クライアントのDNSログを確認し、プロキシの有効・無効で結果を比較するほうが確実です。

デスクトップシステムではnslookupまたはdigで基本的な名前解決を確認できます。出力に含まれるDNSサーバー、返されたアドレス、エラー種別は、単に「ウェブページを開けるか」より有用です。システムの問い合わせは成功するのにプロキシ経由のアクセスが失敗する場合、Xray内蔵DNS、ルーティングルール、ブラウザーのセキュアDNSが別の名前解決経路を使っている可能性があります。ブラウザー、システム、クライアントでそれぞれセキュアDNSを有効にすると調査が難しくなるため、まずは明確な経路を1つだけ残してください。

nslookup example.com
dig example.com A
dig example.com AAAA

ローカル解決、リモート解決、ルーティングの関係を理解する

ドメイン名はプロキシへ入る前にシステムで解決することも、プロキシコアのDNSモジュールへ任せることもできます。前者はシステムキャッシュを利用しやすい一方、解決結果がローカルDNSの影響を受けます。後者はドメインとルーティングルールの一貫性を保ちやすい一方、DNSのアウトバウンドと問い合わせ経路を正しく設定する必要があります。XrayのdomainStrategyは、ルーティングの照合時にドメインを解決するかどうかも決めます。AsIsはできるだけ元のドメイン名で処理し、IPIfNonMatchはドメインルールに一致しない場合にIPを解決して再度照合します。ポリシーはルール構造に合わせて選ぶもので、複雑な値ほどよいわけではありません。

以下は、通常のアドレスで項目の関係を示した簡略版のDNS構成です。実際に使用する際はネットワーク環境とクライアント画面に合わせて設定し、クライアントが自動生成した完全なファイルをそのまま上書きしないでください。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

設定例にある公開DNSアドレスが、すべてのネットワークに適しているとは限りません。重要なのは、問い合わせがどこから送信され、どのアウトバウンドを通り、AレコードとAAAAレコードのどちらを返し、その結果がルーティングにどう利用されるかを確認することです。問い合わせが直接接続で送信され、現在のネットワークからDNSサービスへ安定して到達できないと、断続的なタイムアウトが起こります。プロキシ経由で送信するのにプロキシがまだ確立していない場合は、起動時の依存関係が生まれます。複数のチュートリアルをつなぎ合わせた複雑な設定より、クライアントのデフォルト設定のほうが通常は保守しやすいです。

キャッシュを消去し、IPv6の違いに対処

DNSを変更した後も、システム、ブラウザー、クライアントが古い結果を保持している場合があります。Windowsではipconfig /flushdnsを実行してシステムキャッシュを消去できます。Linuxのコマンドは稼働中の名前解決サービスによって異なります。macOSではネットワークへ再接続するか、対応する名前解決サービスを再起動して更新します。ブラウザーが独自の接続プールを保持していることもあるため、関連ページを完全に閉じて開き直してください。キャッシュの消去で直るのは古いレコードの問題だけで、誤ったDNSルーティングや到達不能なDNSサーバーは修復できません。

ipconfig /flushdns
resolvectl flush-caches

IPv6もよくある分岐の1つです。ドメインがAレコードとAAAAレコードを同時に返すと、システムやアプリがIPv6を優先して試すことがあります。ネットワークからIPv6アドレスが割り当てられていても、実際の出口が不安定なら、初回接続の待ち時間、特定ドメインの失敗、フォールバック後にようやく開くといった症状が出ます。一時的にDNSでIPv4の結果だけを返す設定にして比較できます。問題が消えた場合は、ローカルのIPv6接続性とクライアントの問い合わせ方針を確認します。逆に、IPv6ネットワークが正常なのに一律で無効化すると、より適した経路を失う可能性があります。

FakeDNSの適用範囲と無効化する条件

FakeDNSはドメインに予約アドレスを割り当て、接続時にコアが元のドメイン名へ戻す仕組みです。透過プロキシやドメイン単位の分流に便利ですが、通常のDNSの単純な代替ではありません。アプリによっては返されたIPを検査したり、アドレスをキャッシュしてプロキシを回避したり、独自の名前解決を使ったりします。その場合、ログイン失敗、LAN機器への接続不能、プッシュ通知の異常、UDPアプリの不安定化などが起こることがあります。このような境界の問題では、まずFakeDNSを無効にして通常のDNSで基準状態を作ります。仕組みの詳細はFakeDNSの仕組みと適用シーンを参照してください。

LAN内のホスト名、プリンター、ルーターの管理アドレスだけが失敗する場合は、プライベートアドレスとローカルドメインを直接接続の名前解決へ回し、リモートDNSやFakeDNSへ送らないようにします。ブラウザーだけが失敗して他のアプリが正常なら、ブラウザー独自のセキュアDNSを確認します。すべてのアプリが失敗するなら、システムDNSとクライアントDNSの受信設定を調べます。「システムの問い合わせ—クライアントの問い合わせ—ブラウザーの問い合わせ」の3層を順に検証するほうが、公開DNSを頻繁に変更するより本当の競合を見つけやすくなります。

症状 06

システムプロキシは有効だが、ブラウザーやアプリがクライアントを経由しない

システムプロキシとローカルの受信ポートが一致しているか確認

システムプロキシは、プロキシ設定に対応するアプリを本機のHTTPまたはSOCKS待ち受けポートへ向ける仕組みです。クライアント画面に「システムプロキシ有効」と表示されても、システム設定のアドレスとポートが現在のコアの実際の待ち受け値と一致しているか確認する必要があります。一般的なアドレスはループバックアドレスで、ポートはクライアント設定によって決まります。ローカルポートを変更したのにシステムへ古い値が残っていると、アプリは存在しない待ち受けポートへ接続します。古いクライアントプロセスがそのポートを使っている場合は、誤ったインスタンスへ通信が入ることもあります。

まずクライアントのログで受信待ち受けが起動していることを確認し、次にポート確認コマンドで待ち受けプロセスを検証します。リモートノードのポートとローカルプロキシのポートを混同しないでください。リモートポートはコアがサーバーへ接続するためのもので、ローカルポートはブラウザーがクライアントへ接続するためのものです。システムプロキシにはローカルの待ち受けアドレスだけを指定し、ノードのアドレスは入力しません。変更後はブラウザーを完全に終了して開き直します。既存の接続が古い経路を使い続けることがあるためです。

アプリごとのシステムプロキシ対応の違いを理解する

ブラウザーや多くのデスクトップ向けネットワークプログラムはシステムプロキシを読み取りますが、すべてのアプリが従うわけではありません。独自のプロキシ設定を使うプログラム、環境変数だけを読むコマンドラインツール、直接ネットワーク接続を確立するアプリもあります。そのため、「ブラウザーは使えるのに特定のアプリは直接接続する」からといって、システムプロキシ全体が無効とは限りません。まずシステムプロキシに対応していることが明確なブラウザーで基準状態を作り、その後、対象アプリにHTTP、HTTPS、SOCKSの設定があるか確認します。

コマンドラインツールでは、通常、環境変数を明示的に設定する必要があります。以下の例ではHTTPとHTTPSのリクエストをローカルのHTTPプロキシポートへ向けています。ポートはクライアントに現在表示されている実際の値へ置き換えてください。環境変数が有効なのは現在のターミナルセッションと子プロセスだけで、ターミナルを閉じると通常は保持されません。

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809

SOCKSプロキシでは、ドメイン名をどこで解決するかも関係します。一部のツールではsocks5と書くとローカルで名前解決し、socks5hではプロキシ側へ名前解決を委ねます。コマンドラインでドメイン名だけが失敗し、IPには接続できる場合は、この違いを確認する価値があります。アプリ内、システム、透過プロキシのすべてで同じ通信にプロキシを設定すると、接続がクライアントへ何度も入る可能性があるため避けてください。

PAC、バイパスリスト、ルールモードを確認

システムプロキシのモードには、グローバル、PAC、変更しない設定などがあります。PACはスクリプトでプロキシを使うアドレスを決めるため、スクリプトが更新されていない、古い内容がキャッシュされている、対象ドメインがルールに含まれていないと、ブラウザーは直接接続します。グローバルシステムプロキシは対応するリクエストをクライアントへ送りますが、クライアント内部ではXrayのルーティングルールの影響を受けます。つまり「システム側のグローバル」は「すべての通信がプロキシのアウトバウンドを通る」という意味ではありません。調査では、OSの層とコアのルーティング層を分けて確認します。

システムのバイパスリストには通常、LANアドレスとローカルホスト名が含まれます。リストが広すぎると一般のドメインまでプロキシを回避し、狭すぎるとルーターの管理画面やLANサービスがプロキシへ送られることがあります。ループバックアドレスと明確なプライベートネットワーク範囲を残し、大量のドメインを曖昧なワイルドカードで覆わないことを推奨します。企業環境でポリシーによりプロキシが一括配布されている場合、クライアントがシステム設定を継続的に上書きできないことがあります。その場合は、変更前後でシステムプロキシの値が自動的に戻っていないか比較します。

終了後に残るプロキシとスリープ復帰に対処

クライアントの異常終了、システムによる強制終了、端末のスリープ復帰後には、システムプロキシだけがローカルポートを指し続け、対応するコアが停止していることがあります。この場合、システムプロキシに従うアプリはすべて失敗しますが、システムプロキシを無効にするとすぐ復旧します。まずシステムのネットワーク設定でプロキシを無効にし、その後クライアントを再起動して、クライアントから再度有効にします。通常の終了では復元処理が実行されますが、異常終了したプロセスによる後始末は期待できません。

Windowsでは、現在のユーザーのプロキシ設定と、一部の古いプログラムが読み取る別のインターフェースを区別する必要があります。macOSでは、現在使用中のネットワークサービスを変更しているか確認します。Linuxのデスクトップ環境では、システムプロキシ、デスクトッププロキシ、アプリの環境変数という3つの設定元が存在することがあります。すべての場所へ同時に入力せず、まず明確な方法を1つ選んで検証してください。v2rayNをLinuxデスクトップへインストールして自動起動する場合は、Linuxデスクトップインストールガイドを参照し、ユーザーサービスとデスクトップセッションが同じ環境にあるか確認します。

最終確認では、クライアントのアクセスログに対象ドメインが現れているか確認します。ログに何も記録されないなら、通信がクライアントへ入っていないため、アプリとシステムプロキシを調べます。対象ドメインが記録されているのにdirectへ送られているなら、原因はルーティングルールです。プロキシ経由になった後でタイムアウトするなら、ノードとDNSの章へ戻ります。ログで問題を層別化すれば、システムプロキシが機能していないのにノードを何度も変更する事態を避けられます。

症状 07

クライアントが起動しない、コアが終了する、設定の読み込みに失敗する

グラフィカルインターフェースのクラッシュとコアの起動失敗を区別する

v2rayNは、グラフィカルインターフェース、設定データ、プロキシコアで構成されています。ウィンドウが開かない、開いた直後に消える、画面は正常なのに接続ボタンが反応しない、といった症状はそれぞれ異なる層に属する可能性があります。画面を操作できるのにログでコアの終了が示されるなら、生成された設定とポートを重点的に確認します。プログラム自体にウィンドウが表示されない場合は、システムイベント、起動時のターミナル出力、ファイル権限、実行依存関係を確認します。ノードの破損は通常、接続失敗を引き起こすだけで、インターフェース全体を表示できなくするとは限りません。すべての起動問題をノードのせいにしないでください。

調査前に関連プロセスを完全に終了し、もう一度起動します。何度もダブルクリックすると複数のインスタンスが起動し、設定ファイルのロックやローカルポートの競合が起こることがあります。デスクトップではタスクマネージャーまたはシステムモニターで、グラフィカルプロセスとXrayプロセスが残っていないか確認します。システムの再起動で復旧しても、次回のスリープ後に再発しないよう、前回のログでポート占有と異常終了の原因を確認してください。

最初の設定エラーからさかのぼって追跡

コアが設定を読み込む際、JSON構造、フィールド型、プロトコルパラメーター、参照タグを検証します。後から大量に出る終了メッセージは、最初の設定エラーが引き起こしていることが多く、重要なのは最初に現れるfailed to load config、未知のフィールド、存在しないアウトバウンドタグ、JSONの解析位置です。JSONを手動編集すると、カンマ、引用符、括弧で間違えやすくなります。グラフィカルクライアントで設定の生成に失敗する場合は、カスタムルーティング、DNS項目、ノードの追加パラメーターが不正である可能性があります。

JSONではコメントを使用できず、最後のメンバーの後にカンマを残すこともできません。文字列内のバックスラッシュと二重引用符はエスケープが必要です。以下の構造は構文が完全で、基本的な階層を照合するためのものですが、接続可能なノードは含みません。

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

カスタム設定を有効にした後だけエラーが出る場合は、まずカスタム項目を無効にし、クライアントにデフォルト設定を再生成させます。デフォルト設定で起動できることを確認してから、DNS、ルーティング、アウトバウンドを段階的に追加します。設定ファイルの構造と各ブロックの役割はV2Ray JSON設定の構造解説を参照してください。他のクライアントの完全な設定を現在のクライアントへ上書きしないでください。インターフェースが独自に生成した受信タグ、ポート、管理インターフェースに依存している場合があります。

ディレクトリ権限、パス、セキュリティソフトによる遮断を確認

クライアントは設定を読み込み、ログを書き込み、コアの子プロセスを起動する必要があります。インストール先が書き込み不可、ユーザーディレクトリの権限に問題がある、パスのあるディスクが読み取り専用といった状態では起動に失敗します。Linuxでは特に、管理者権限で一度起動した後、同じ設定ディレクトリを一般ユーザーで実行するのは避けてください。前回生成されたファイルの所有者が管理者になっている可能性があります。ファイルの所有者と権限を修正し、通常のデスクトップユーザーで再起動します。macOSとWindowsでは、システムの保護機能がプログラムディレクトリへの書き込みを阻止していないか、セキュリティソフトがコアファイルを隔離したり子プロセスの実行を阻止したりしていないか確認します。

パスに特殊文字が含まれていても、現在のクライアントなら通常は処理できます。ただし外部スクリプト、古い設定、カスタムコマンドがパスを誤って分割することがあります。比較のため、設定ディレクトリを一時的に短いユーザーディレクトリへ移動します。リアルタイム同期フォルダーに設定を置いてテストしないでください。クライアントが書き込む際に、同期ソフトが競合コピーを作成したり、ファイルを一時的にロックしたりする可能性があります。パスが原因だと確認できたら、元の場所へ項目ごとに戻します。

診断資料を残して安全に設定を再構築

リセットが必要な場合は、まずクライアントを終了し、設定ディレクトリをローカルのバックアップとしてコピーします。その後、現在の設定ディレクトリの名前だけを変更し、クライアントに新しい設定を生成させます。新しい設定で起動できるなら、プログラムファイルとシステム環境は基本的に正常で、問題は古い設定にあります。サブスクリプションと必要最小限のルールを追加し直し、古いディレクトリ全体をすぐに戻さないでください。サブスクリプション、ルーティング、DNS、インターフェース設定の順に種類ごとに復元し、そのたびに起動を確認します。

新しい設定でも起動できない場合は、再インストールを検討します。クライアントダウンロードから、プラットフォームとプロセッサーに合ったv2rayNを選択してください。Androidではv2rayNGを使用し、v2flyコアが必要な場合はv2flyNGを選びます。再インストール前に、ログのエラー、OS、プロセッサーアーキテクチャ、再現手順を記録してください。「起動できない」というスクリーンショット1枚より、原因の特定に役立ちます。バージョン互換性を推測せず、ダウンロードページに現在掲載されているパッケージ形式とシステム要件を基準にしてください。

特定のノードを追加した後にクラッシュするなら、新しい設定ではまず別のノードを追加し、疑わしいリンクだけを後から追加します。特定のDNSやルーティング機能を有効にした後に発生するなら、デフォルト設定を残して項目ごとに再現します。「どの項目を追加した後から失敗したか」を特定できれば、システム、クライアント、サブスクリプションをすべて同時に変更せず、具体的な設定へ問題を絞り込めます。

症状 08

Androidで接続が切れる、バックグラウンドで停止する、アプリ分流が不安定

VPN権限と、システム上で同時に存在する接続を確認

v2rayNGとv2flyNGは、Androidでは通常、システムのVPNインターフェースを通じて通信を引き受けます。初回接続ではシステムの許可を確認してください。許可ダイアログをキャンセルすると、クライアントはノードを保存できてもVPNを確立できません。ステータスバーにVPNアイコンが表示されても、インターフェースが作成されたことを示すだけです。コアとノードの接続成功はログで確認する必要があります。システム上で同時に維持できるVPNサービスは通常1つだけで、他のVPNアプリ、仕事用プロファイル管理ツール、システムのネットワーク機能がインターフェースを奪い、接続直後に切断させることがあります。

調査時はまず他のVPN機能を無効にし、v2rayNGまたはv2flyNGを完全に停止してから、対象クライアントを開き直して許可します。2つのクライアントを同時に自動接続状態にしないでください。クライアントを切り替えた後も古いVPNアイコンが消えない場合は、システムのネットワーク設定で現在のVPNを切断し、対象クライアントを起動します。デスクトップでは使えるノードがAndroidで即座に失敗する場合、まずAndroidへ取り込んだ後のプロトコル、トランスポート、セキュリティ方式、サーバー名、パスを比較し、QRコードやクリップボードの内容が途中で切れていないか確認します。

省電力設定とバックグラウンド制限に対処

画面消灯から数分後に接続が切れ、画面を点灯すると復旧する場合、通常はバックグラウンド制限が関係しています。Android端末メーカーの省電力機能がクライアントプロセスを停止したり、バックグラウンド通信を制限したり、長時間動作するVPNサービスを終了させたりすることがあります。システムのアプリ設定でクライアントのバックグラウンド実行を許可し、そのアプリのバッテリー最適化を解除し、必要に応じて自動起動やバックグラウンド動作を許可します。メニュー名は端末によって異なりますが、判断基準は同じです。画面ロック後もクライアントが動作し、システムから制限対象アプリとして扱われないことを確認します。

クライアントを最近使ったアプリ一覧に残すだけでは不十分な場合があります。一部システムの「タスクをロック」も、バックグラウンド通信の許可とは別物です。設定変更後は画面をロックしてしばらく待ち、メッセージ同期、ウェブリクエスト、クライアントログで接続が継続しているか確認します。モバイル通信からWi-Fiへ切り替えたときだけ切断するなら、ネットワーク変更後に古い接続が再構築されていない可能性があります。クライアントへ戻って手動で停止・再起動し、再接続の問題か判断します。頻繁にネットワークを切り替える環境では、システムの常時接続VPN、他の自動化ネットワークツール、クライアント自身の自動接続を同時に有効にしないでください。複数の仕組みが競合するためです。

アプリ分流とバイパス設定を調べる順序

Androidクライアントでは、アプリごとにVPNへ入れる通信を決められます。設定の方向が混同されやすく、画面によっては「選択したアプリのみをプロキシ」し、別の画面では「選択したアプリをバイパス」します。意味を逆に理解すると、ブラウザーは正常なのに対象アプリだけ直接接続する、または一部のアプリしか通信できないといった症状が出ます。調査時はまずアプリ分流を無効にし、すべてのアプリを同じVPN経路へ入れてノードとDNSが正常か確認します。その後、分流を有効にし、テスト対象のアプリを1つだけ選びます。

システムアプリ、仕事用プロファイル内のアプリ、通常のユーザーアプリは、異なる設定範囲に属することがあります。対象アプリがシステムコンポーネントを呼び出してウェブページを開く場合、メインアプリとシステムコンポーネントが別の経路を通り、ログインページと本文で接続結果が異なることがあります。その場合はクライアントログに対象ドメインが出ているか確認し、関連するシステムコンポーネントが分流ルールで除外されていないか調べます。最初から大量のアプリ名を追加しないでください。リストが長いほど実際の適用方向が分かりにくくなります。

LANアクセス、テザリング、DNSの違いに対処

VPNを有効にした後、ルーター、LANストレージ、プリンターへ接続できない場合は、「LANをバイパス」またはプライベートアドレスの直接接続ルールを確認します。LANアドレスは通常、リモートノードへ送るべきではありません。IPではアクセスできるのにローカルホスト名では失敗するなら、問題はノードよりローカルDNSまたはマルチキャスト名前解決に近いものです。FakeDNSを無効にし、LANドメインをローカルで解決し、プライベートネットワーク範囲を直接接続にすれば、より明確な基準状態を作れます。

端末のテザリングは別のネットワーク転送層です。端末のアクセスポイントへ接続した機器が、スマートフォン上のVPNを自動的に使うとは限りません。スマートフォンのブラウザーがクライアント経由で接続できても、テザリング先の機器は独立した出口を使うことがあります。スマートフォンのステータスバーだけで共有端末の経路を判断せず、接続先の機器で個別に確認してください。スマートフォンのアプリだけが対象なら、テザリングを無効にして変数を減らせます。共有通信を処理したい場合は、クライアントとシステムが対応機能を提供しているか確認し、通常のVPNモードの挙動をテザリングへそのまま当てはめないでください。

AndroidのプライベートDNSとクライアントDNSが同時に存在する場合があります。プライベートDNSへ到達できないと、一部アプリが待ち続けることがあります。また、クライアントでFakeDNSやリモートDNSを有効にすると、システムのポリシーと異なる解決結果になる可能性があります。調査時はプライベートDNSをシステムの自動設定へ戻し、クライアントの高度なDNS機能を無効にして、デフォルト設定だけを残します。基本接続が復旧してから、必要な項目を1つずつ有効にします。特定のアプリだけが失敗する場合は、アプリ内蔵DNS、QUIC、証明書ピンニングも考慮し、すべての差異をクライアントの問題と決めつけないでください。

ログを収集し、2つのAndroidクライアントを比較

問題を再現する前に、現在のログを消去するか位置を確認します。その後、切断して再接続する、失敗するドメインを開く、画面をロックして待つなど、明確な操作を1回だけ行います。最初のエラー、ネットワーク種別、アプリ分流の有無、DNSモード、ノードプロトコルを記録します。対象リクエストがログにまったく出ないならアプリ分流を確認し、リクエストはあるのに名前解決で失敗するならDNSを調べます。ノード接続がタイムアウトするならアドレス、ポート、ネットワークへ戻り、画面ロック後にコアのログが止まるならバックグラウンド制限を重点的に確認します。

v2rayNGはXrayコアを使用するAndroid向けの主要クライアントで、v2flyNGはv2flyコアを使用し、プロトコル互換性や動作を比較するために利用できます。比較テストでは、サポートされている同じノードを取り込み、DNS、ルーティング、アプリ分流をできるだけ簡単に保ちます。同じネットワークで両方のクライアントが失敗し、別のネットワークではデスクトップが正常なら、Android側のネットワークを切り替えて再テストします。一方だけが失敗するなら、コアのサポート範囲と生成された設定を比較します。クライアント、ノード、ネットワークを同時に変更すると、結果から原因を判断できなくなります。

調査が終わったら、必要なバックグラウンド権限、アプリ分流、DNS設定を戻し、項目ごとに確認します。長期的に安定する設定は、多数の実験的オプションを重ねた設定より保守しやすいものです。初回設定の手順は使い方ガイドへ戻って確認し、証明書ハンドシェイクに関するエラーはTLSと証明書エラーのチェックリストも参照してください。

トラブルシューティング後の次の手順

最小限の動作構成を残し、設定を1つずつ戻す

原因を特定した後、古い設定を一度にすべて戻さないでください。利用できるノード1つとデフォルトDNSを固定し、ルーティング、システムプロキシ、自動選択、高度な機能の順に再テストします。

使い方ガイドを見る クライアントを見る