症状から探すトラブルシューティング

V2Rayのトラブルシューティング
接続・サブスクリプション・クライアント設定

対象クライアント：デスクトップではv2rayN、Androidではv2rayNGを推奨。V2Flyコアを使う場合はv2flyNGも選択肢です。

このページは、クライアントのインストール後に問題の原因を調べたい場合に利用してください。初回接続がまだの場合は、まず入門ガイドに沿って、設定のインポート、選択、接続確認まで進めてください。その後、該当する症状を確認します。チュートリアルでは使える設定を作成し、このガイドでは問題が起きる範囲を切り分けます。最初から同じ操作を繰り返す必要はありません。

インターネットに接続できない：まず通信経路を切り分ける

「クライアントは接続中なのにWebページが開かない」という状態は、画面上で動作していることを示すだけで、接続先とのハンドシェイク成功を意味しません。通信経路には、アプリ、システムプロキシまたは仮想ネットワークインターフェース、ローカルの受信設定、出力設定、リモートサーバー、接続先サイトが含まれます。設定を次々に変えるより、リクエストがどの段階で止まるかを確認しましょう。再現性のある接続先を1つ決め、現在のネットワークから通常直接アクセスできるサイトも比較対象として用意します。

直接接続に戻して、基本ネットワークを確認する

デスクトップではシステムプロキシを無効にしてからクライアントの接続を停止します。Androidではクライアントが確立したVPNを切断してください。Wi-Fiに接続できていること、ゲートウェイが利用可能であることを確認し、必要に応じて公衆Wi-Fiのログイン画面で認証します。プロキシを停止しても比較対象のサイトを開けない場合は、ネットワークへのログイン、端末の時刻、ルーター、通信事業者側を確認してください。基本的な接続の問題をプロトコルの問題と混同しないようにします。公衆Wi-Fiの認証は、通常、直接接続の状態で行います。

直接接続が正常なら、クライアントを起動し、通信を取り込む方式を一つだけ有効にしてテストします。他のプロキシやVPN、ネットワーク設定を書き換える通信最適化ツールを同時に使わないでください。デスクトップではまずローカルプロキシで確認し、出力が使えることを確かめてから、追加の権限が必要な接続モードを有効にします。これにより「リモート接続の失敗」と「通信がクライアントに届いていない状態」を切り分けられ、原因が隠れるのを防げます。

選択中の設定とローカル待ち受けを確認する

v2rayNでは、一覧で別の行が強調表示されているだけではなく、テストしたいサーバーが実際に有効になっているか確認します。サブスクリプションの更新後は、使用中の設定が変わっている場合があります。起動前にアドレス、ポート、トランスポート設定を確認してください。続いて、ログにローカルの受信側が正常に起動した記録があるか確認します。ポート使用中と表示された場合は、使用しているプロセスを特定するか、クライアントのポートを変更してアプリ側の設定も合わせます。再起動を繰り返すだけでは解決しません。

ローカルのSOCKSポートはクライアントに表示されている値を使用してください。以下の例は、実際のポートが10808の場合に限り使えます。Windowsではターミナルからcurl.exeを実行し、macOSとLinuxでは通常curlを使います。コマンドでプロキシを明示すれば、ブラウザーがシステムプロキシを参照しているかどうかという要因を除外できます。接続先サイトから返されたHTTPエラーと、接続そのものの失敗は分けて判断してください。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/

HTTPレスポンスヘッダーが返れば、そのリクエストではローカルプロキシからリモートアクセスまでの経路が少なくとも通っています。ただし、すべてのサイトが使えるとは限りません。ローカルアドレスに接続できない場合は、クライアントが起動しているか、待ち受けプロトコルが一致しているかを確認します。ローカル接続の成功後にリモート側のエラーが出る場合は、出力ログを確認してください。SOCKSポートをHTTPプロキシ専用の欄に入力しないでください。ポート番号が同じでも、両者は置き換えられません。

ルーティングを切り替えてリクエストの経路を確認する

ローカルプロキシのテストは成功するのにブラウザーで失敗する場合は、ブラウザーのプロキシ拡張機能、独自のDNS設定、キャッシュを優先して確認します。一部のサイトだけで失敗する場合は、テスト時だけプロキシ優先のルーティングに切り替えて比較し、終わったら元に戻します。ここでいう「プロキシ優先」は出力先の選択を変更するもので、すべてのアプリの通信が自動的に取り込まれるわけではありません。通信がクライアントに届くかどうかは、システムプロキシ、アプリの設定、仮想ネットワークインターフェースによって異なります。

ルーティングを変えて改善した場合は、元のルールが対象を誤って直接接続に振り分けていないか、ブロックする出力に一致していないか、ルールセットが正しく読み込まれているかを確認します。ルールは通常、上から順に照合されるため、先にある広い条件が後の詳細なルールを上書きすることがあります。すべてのルールを消すのではなく、先にバックアップを取り、対象ドメインを1つに絞って検証してください。社内ネットワーク、LAN機器、一般のWebサイトでは必要な接続方法が異なります。グローバルモードだけで恒久的に解決しようとしないでください。

結果を確認して、今回の切り分けを終える

最後に、直接接続、プロキシを明示した接続、普段使うアプリでの接続をそれぞれ再テストします。明示したプロキシでは使えるのにアプリでは失敗する場合は、システムプロキシの項目へ進みます。すべての出力がタイムアウトする場合は、ノードのタイムアウトの項目を確認します。ドメイン名を使うリクエストだけで問題が起きる場合は、DNSの項目を確認してください。動作する設定を複製して保存し、テストのために追加した一時ルールを削除してから、必要な機能を一つずつ元に戻します。

ノードのタイムアウト：接続・ハンドシェイク・応答を切り分ける

タイムアウトは結果を待っている状態であり、原因そのものではありません。同じ「接続失敗」でも、リモートポートに到達できない、TLSハンドシェイクが完了しない、トランスポートの設定が誤っている、接続先サイトの応答が遅いなど、原因はさまざまです。まずクライアントのログを開き、失敗する操作を1回だけ実行して、同じ時刻のログから最初に発生したエラーを探します。その後に続く接続終了の記録は二次的な結果であることが多く、先に原因と決めつけないでください。

ログが発生した段階から判断する

dial tcpとタイムアウトが記録された場合は、通常、アドレス、リモートポート、ネットワーク到達性を確認します。connection refusedの場合は、接続先ポートでサービスが動作していないか、接続を明示的に拒否されている可能性があります。TLSの段階まで進んでいる場合は、サーバー名、証明書の検証、端末の時刻を確認してください。ログから分かるのは原因の範囲であり、短いエラーメッセージだけでリモートサービスが停止していると断定はできません。ネットワークを変えた比較も必要です。

エラーの手がかり優先して確認する項目この情報だけでは断定できないこと
timeoutアドレス、ポート、通信経路、待ち時間が発生した段階認証情報が必ず間違っている
certificateシステム時刻、サーバー名、証明書チェーン証明書の検証を必ず無効にすべき
EOF相手側による切断、トランスポート設定、前段サービス特定のプロトコルが必ず使えない

クライアント内蔵の接続テストは失敗するのにWebページを開ける場合、テスト先自体に到達できるか、実際の接続と同じ出力経路をテストしているかを確認します。TCP接続、プロキシのハンドシェイク、Webリクエストのテストは、それぞれ対象が異なります。結果をそのまま同一視しないでください。逆に、単純な接続確認に成功しても、認証や暗号化、アプリケーション層のアクセスが正常とは限りません。

プロトコルとトランスポート設定を一つずつ確認する

信頼できる提供元の元の設定と照らし合わせ、プロトコル、アドレス、ポート、ユーザー識別情報、暗号化オプション、トランスポートの種類を確認します。WebSocketではパスとサーバー側が要求するHostを一致させ、gRPCではサービス名を合わせます。TLSのサーバー名と接続先アドレスは異なる場合があるため、安易に同じ値にしないでください。あるWebサイトにアクセスできても、そのサイト上のプロキシサービスが同じ接続先を使うとは限りません。

VLESSとREALITYなどを組み合わせる場合、サーバーが要求する公開鍵、短いID、サーバー名、フロー制御の設定を、クライアントの機能と設定に合わせる必要があります。名前が似ているからといって、別のトランスポートに設定をコピーしないでください。パラメーター不足を解決するために、安易にコアを切り替えるのも避けます。サブスクリプションのインポート後に項目が欠けている場合は、まずクライアントがその形式に対応しているかを確認し、設定の提供元に完全な情報を問い合わせてください。

端末の時刻がずれていると、証明書の検証に失敗したり、一部の認証に影響したりすることがあります。まずシステムの自動時刻を有効にし、タイムゾーンを確認してから再試行してください。エラーを回避するために証明書の検証を長期間無効にしないでください。接続の安全性が損なわれるうえ、サーバー名の入力ミスを見逃す原因にもなります。関連オプションを調べるのは、管理されたテスト環境に限ってください。利用を再開する前に、通常の検証設定へ戻します。

ネットワークと設定を組み合わせて比較する

同じ設定のまま、現在のネットワークと別の信頼できるネットワークでテストします。次に、現在のネットワークはそのままにして、利用実績のある別の設定で試します。前者ではローカルネットワークの違いを、後者ではリモート側または個別設定の違いを確認できます。テスト時には、DNSを変更したか、別のVPNが動作しているか、IPv6経由の場合だけ失敗するかも記録します。複数の変更を1つの結論にまとめないようにしてください。

ドメイン名からIPv4とIPv6の両方が返される場合、片方のアドレスファミリーで経路に問題があると接続を待たされることがあります。まずログから実際に接続したアドレスを確認し、一時的にアドレスファミリーを切り替えて比較します。システム全体でIPv6を恒久的に無効にしないでください。サーバーアドレスにドメイン名を使っている場合は、名前解決の結果が提供元の想定と一致するかも確認します。誤ったアドレスに解決されているなら、タイムアウトを一律に延ばすのではなくDNSの問題として扱います。

リモート側の停止と再試行の範囲を確認する

複数の異なるネットワークで同じ設定だけが失敗し、パラメーターと有効期限も確認済みなら、問題をリモートサービスまたは設定の利用権限に絞ります。最初に発生したエラーを個人情報が分からない形にし、発生時刻とネットワークの比較結果を添えて問い合わせてください。サブスクリプション全体は送らないでください。何度も再試行しても、サーバーの待ち受け設定やアカウント制限は直りません。制限が追加されるおそれもあります。確認を待つ間は動作確認済みの予備設定を使い、後で比較できるよう元の項目も残します。

サブスクリプションの更新失敗：取得・解析・設定利用を切り分ける

サブスクリプションの更新には、URLから内容を取得する、クライアント用設定に変換する、その中から1つを選んで接続する、という3つの段階があります。更新成功は最初の2段階が完了したことを示すだけで、すべての設定が接続できるとは限りません。接続失敗も、サブスクリプションを追加し直すべきという意味ではありません。画面に表示されたのがネットワークエラー、形式エラー、インポート後に一覧が空になる問題のどれかを確認し、該当する手順に進みます。まだ使える古い項目を削除しないようにしてください。

リンクの種類とアクセス認証情報を確認する

HTTPまたはHTTPSのサブスクリプションURLは、通常、更新可能な設定一式を返します。vmess://やvless://などの共有リンクは、通常、単一のノードを表します。単一ノードのリンクをサブスクリプションURL欄に入力すると、取得に失敗することがあります。サブスクリプションのテキストを通常のWebアドレスとしてコピーすると、クエリパラメーターが失われる場合もあります。提供元の説明を確認し、「サブスクリプショングループ」や「クリップボードからインポート」など適切な方法を選んでください。

コピーした内容に前後の空白や改行、チャットアプリが追加した句読点、途中で切れたクエリ文字列が含まれていないか確認します。サブスクリプションURLに含まれるアクセストークンはパスワードと同様に扱ってください。公開の検査サイトに貼り付けたり、共有端末で直接開いたりしないでください。URLが漏えいした場合は、サービス提供元を通じてアクセス認証情報をリセットします。クライアントから記録を削除しても、すでにURLを入手した人のアクセスは無効になりません。

共有リンクとサブスクリプションの違いについては、共有リンクとサブスクリプションの違いをご覧ください。ノードを手動でインポートする方法は一時的な確認には使えますが、サブスクリプションの自動更新には対応しません。継続して使う場合は分かりやすいグループ名を付け、手動で追加した項目とサブスクリプションの項目を区別しておくと、次回の更新後に設定が意図せず変更されたと誤解しにくくなります。

取得エラーが発生した段階を確認する

更新ログでHTTPステータスとネットワークエラーを確認します。認証や権限に関する応答の場合は、アカウント、URL、有効期限を確認します。リクエスト過多の応答がある場合は、連続更新を止めて時間を置いてください。サーバーが成功ステータスを返しても内容を解析できない場合、設定本文ではなくログイン画面、メンテナンス画面、ネットワーク認証画面を取得している可能性があります。ステータスコードとコンテンツの種類を合わせて判断し、すべての失敗をクライアントのバージョンのせいにしないでください。

直接接続ではサブスクリプションを取得できず、現在のプロキシは使える場合、クライアントに該当オプションがあれば、現在のプロキシ経由で更新を試せます。反対に、プロキシ自体が使えない状態で更新をプロキシ経由にすると、古い設定が新しい設定の取得に必要になり、その古い設定も更新を必要とする依存関係が生じます。まず更新に使われている経路を確認し、必要に応じて利用可能な直接接続のネットワークに戻すか、動作確認済みの一時接続を使ってください。

形式と互換性の問題に対処する

取得は完了したのにインポートに失敗する場合は、サブスクリプションがクライアントで認識可能な共有リンクの一覧であり、別のクライアント専用形式ではないことを確認します。任意のYAML、Webページのソース、別の形式に変換されたテキストを汎用サブスクリプションとして使わないでください。共有形式で扱えるパラメーターはクライアントやコアの機能によって異なります。項目名が表示されても、すべてのトランスポート設定が正しく保持されているとは限りません。

まず専用のテストグループを作り、同じ提供元の共有リンクを1つだけインポートして、アドレス、プロトコル、トランスポート設定が揃っているか確認します。単一項目は使えるのにグループ全体のインポートに失敗する場合は、サブスクリプションの内容と変換方法を調べます。1つの項目でも不足が起きる場合は、まず形式への対応状況を確認してください。個人用サブスクリプションを、提供元不明のオンライン変換サービスに渡さないでください。変換処理でURLや認証情報が読み取られるおそれがあります。

更新後の有効な設定を選び直す

サブスクリプションの更新後、選択中だった項目の名前が変わったり、置き換えられたり、削除されたりすることがあります。有効なサーバーとグループを選び直し、接続してログを確認してください。更新前は使えていたのに更新後に失敗する場合は、表示名だけでなくプロトコルとトランスポート設定を比較します。サーバー側の変更に新しい設定項目が必要になっても、古いクライアントでは正しく読み込めない場合があります。クライアントの更新が必要な場合は、プラットフォームに合ったパッケージをダウンロードセンターから選び、先に移行方法を確認してください。

復旧したら必要な更新頻度だけを設定し、手動で追加した項目が誤って上書きされないことを確認します。今回使用した取得経路も記録してください。同じサブスクリプション内で一部の項目だけが異常な場合は、グループ全体を何度も作り直すのではなく、ノードのタイムアウトの項目へ進みます。問題を報告する際は、個人情報を除いたステータスコード、解析エラー、クライアント名を記載します。完全なURL、ユーザー識別情報、加工していないサブスクリプション本文は含めないでください。

速度が遅い：名前解決・接続・データ転送を分けて確認する

Webページの表示が遅い、動画が途中で止まる、大きなファイルのダウンロードに時間がかかる、といった症状は同じ問題とは限りません。最初の症状はDNSやハンドシェイクに時間がかかっている可能性があり、後の症状は継続的な転送速度、パケットロス、サーバー負荷が関係することがあります。接続先を固定し、近い時間帯に同じアプリで再テストして、開始まで時間がかかるのか、接続後も遅いのかを記録します。異なるサイト、ファイル、ネットワークの結果をそのまま比較しないでください。

再現できるテスト条件を整える

バックグラウンドで大量の通信を行うタスクを止め、Wi-Fiの電波とローカルネットワークが安定していることを確認してから、動作確認済みの設定でテストします。ノートPCでは可能なら有線ネットワークとも比較し、スマートフォンではWi-Fiとモバイルデータ通信を比較できます。一度に変更するのは1項目だけにし、元の症状を再現できるまでテストを続けてください。クライアントの接続テスト結果は帯域幅を保証するものではなく、長時間の通信が安定するかどうかも単独では判断できません。

特定のWebサイトだけが遅く、他の接続先は正常な場合は、接続先の負荷、コンテンツ配信経路、アカウントの制限を検討します。プロキシの出口が変わると、Webサイトが異なる配信サーバーを選択し、同じ設定でもサイトによって速度に大きな差が出ることがあります。1つのページが遅いだけでローカル設定全体を変更しないでください。別のブラウザーや同じサイトの別コンテンツで問題の範囲を確認してから、出力先を変更するか判断します。

初回応答の遅さと継続的な転送の遅さを見分ける

最初の表示は遅いのに2回目は明らかに速い場合は、DNSキャッシュ、TLSセッションの確立、ブラウザーの接続再利用を確認します。毎回名前解決の段階で待たされるなら、ルーティングやトランスポートの並列数を変えても効果がないことがあります。名前解決は速いのにハンドシェイクが繰り返し失敗する場合は、タイムアウトの項目に戻り、トランスポート設定を確認します。転送速度が徐々に低下する場合は、DNSのタイムアウトをむやみに短くするのではなく、パケットロス、リモート負荷、端末のリソースを確認してください。

ターミナルでリクエスト各段階の累積時間を確認できます。以下の例は、ローカルのSOCKSポートが実際に10808の場合に限り使ってください。各リクエスト段階を確認するためのもので、速度測定ツールではありません。プロキシ経由のアクセスでは、名前解決やハンドシェイクにかかった時間にプロキシトンネルの確立が含まれる場合があります。特定の値だけをリモートDNSの所要時間とみなしたり、1回の結果で設定の優劣を決めたりしないでください。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -o /dev/null -sS -w "connect=%{time_connect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" https://example.com/

このコマンドは、通常これらのターミナルツールを利用できるmacOSとLinuxで使用できます。Windowsではcurl.exeを使い、出力先ファイルをNULに変更してください。比較時は同じ接続先と同じプロキシ経路を使います。最初の1バイトが返るまでの時間が長くなっていても、リクエスト処理のどの段階に問題があるかをさらに調べる必要があることを示すだけです。端末、プロキシサービス、接続先サイトのどれかに必ず原因があると断定はできません。

端末の負荷と追加処理を確認する

システムのタスク管理ツールを開き、クライアント、コアのプロセス、他のプログラムのCPU、メモリ、ディスク使用量を確認します。高負荷が続く場合は、詳細ログ、大量のルール処理、他のアプリとのリソース競合が原因かもしれません。切り分け時はデバッグログを通常のレベルに戻し、不要なタスクを一時停止してから再テストします。システムのセキュリティ機能を一度にすべて無効にしないでください。実際にブロックされた証拠がある場合は、該当するプログラムと通知を個別に確認します。

多重化、同時接続、トランスポート設定は、値を大きくすれば速くなるとは限りません。接続の再利用方法を変えるだけでなく、サーバー側の実装上の制限を受ける場合もあります。提供元から指定がない場合は、まず設定の既定値を使用してください。特定のオプションを検証するときは元の値を記録し、1項目ずつ比較します。変更後に停止や切断が起きた場合は、その変更を取り消します。最適化オプションを重ねて追加すると、以降の切り分けで比較の基準が失われます。

ルーティング、アドレスファミリー、ネットワーク切り替え

ルーティングの誤りによって、本来は直接接続するリソースがプロキシ経由になったり、プロキシ経由にすべき接続が失敗を繰り返したりすることがあります。対象が実際にどの出力先を選んだかを確認してから、ルールを修正します。IPv4とIPv6の経路の違いや、仮想ネットワークインターフェースのMTU不一致が、小さなリクエストは通るのに大きな応答が止まる原因になることもあります。関連する証拠がある場合に限ってテストし、「速度が遅い」という理由だけでシステムのMTUを変更しないでください。

ネットワークを変えて問題が解消した場合は、設定を変えずにしばらく確認し、元のネットワークのWi-Fi品質、ゲートウェイの負荷、アクセス制限を調べます。複数のネットワークで特定の出力だけが遅い場合は、接続先、発生時刻、個人情報を除いたログをサービス提供元に伝えてください。修復できたかどうかは、同じ作業が安定して完了するかで判断します。テスト用に無効にした機能を戻し、追加した特殊なルートを削除してください。

DNSの問題：名前解決の経路とルーティングを確認する

DNSはドメイン名をアドレスに変換しますが、クライアント内には複数の名前解決経路が存在することがあります。システムのリゾルバー、ブラウザーの暗号化DNS、プロキシプロトコルで渡されるドメイン名、ルール照合のためにコアが行う名前解決などです。あるWebページが開けても、すべてのDNSリクエストが想定どおり処理されているとは限りません。調査を始める前に、名前解決の失敗を直したいのか、誤ったアドレスを減らしたいのか、特定のリクエストの出口を制限したいのかを明確にします。

問題が本当に名前解決の段階で発生しているか確認する

ログに名前解決のタイムアウト、空の結果、DNSサーバーを使用できないという記録があるか確認します。システムのコマンドでドメイン名を解決できても、システム側の経路が使えるというだけで、プロキシコアが同じリゾルバーを使用しているとは限りません。HTTPSサイトのIPアドレスを直接開いてDNSの結果を判断しないでください。証明書やサーバー名の確認には通常、元のドメイン名が必要です。IPアドレスで開けなくても、アドレスに到達できないとは断定できません。

SOCKSを明示したテストでは、socks5hは通常、ドメイン名をプロキシ側で処理します。一方、通常のSOCKS接続ではローカルで先に名前解決する場合があります。結果の違いは名前解決経路を見分ける手がかりになりますが、クライアントの出力ログと合わせて判断してください。ブラウザーで独自の暗号化DNSが有効になっていると、システムの名前解決テストとWebページの表示結果が一致しないこともあります。比較する前に、その設定状態を記録しておきます。

domainStrategyが影響する範囲を理解する

ルーティングのdomainStrategyは、ドメインとIPのルールを照合する際に名前解決を行うかどうかを制御します。DNSの出口を切り替える設定ではなく、DNSリクエストがプロキシ経由になることを単独で保証するものでもありません。以下はルーティングオブジェクトの有効な一部で、フィールドの意味を理解するための例です。受信、出力、DNSサーバーは定義されていないため、そのまま実行できる完全な設定ではありません。GUIクライアントが生成した設定全体を置き換える用途にも使わないでください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIsは通常、既存のドメイン情報を使って照合し、IPルールのための名前解決は積極的に行いません。IPIfNonMatchは、ドメインルールに一致しない場合に名前解決を試み、照合を続けます。IPOnDemandは、関連するIPルールに遭遇したときに名前解決を開始する場合があります。実際に使える値は、使用中のコアに準じます。上記の例は、利用可能な地理データと、directという名前の出力にも依存します。フィールド名は実際の設定と一致させてください。

そのため、DNSに問題が起きても、より積極的に見える設定へ変更するだけでは解決しません。まずドメインルールが対象に一致しているか、リゾルバーに到達できるか、DNSサーバーへの接続にどの出力先が使われているかを確認します。名前解決の回数を増やすと待ち時間が長くなったり、ルールの照合結果が変わったりする場合があります。変更後は、Webページがたまたま開けたかだけでなく、対象のアドレスと実際の出力先の両方を確認してください。

DNSサーバーとの依存関係が循環する場合の対処

HTTPSベースのDNSサービスを使う場合、そのサービスのドメイン名も事前に解決する必要があることがあります。その名前解決にプロキシが必要で、プロキシサーバーのアドレスも同じDNSに依存していると、起動時に依存関係が循環します。対処するには、起動段階での名前解決経路とアクセスルールを明確にし、コアが対応する方法でブートストラップ用の名前解決を設定します。すべてのリゾルバーを理由なく同じアドレスに変更しないでください。選択したサービスにネットワークからアクセスできることも確認します。

中国本土内と中国本土外のドメインを別のDNSで解決する場合は、DNSの選択、ルーティングルール、接続先への出力経路を一致させる必要があります。適切でないリゾルバーにドメインを渡すと、利用できないアドレスや望ましくない経路が返ることがあります。DNSリクエストが誤って直接接続されると、想定した経路から外れる場合もあります。詳しい設定項目はDNSの分流・振り分け設定をご覧ください。依存関係を理解してから、現在のクライアントに適用してください。

キャッシュ、漏えい検査、最終確認

名前解決の設定を変更しても、ブラウザー、OS、コアには古いキャッシュが残っている場合があります。まずクライアントの接続を作り直して古いWebページを閉じ、OSの方法に従ってキャッシュを更新します。キャッシュを消すために設定ディレクトリを削除しないでください。社内や家庭内のドメインは、そのネットワークが提供するリゾルバーに依存している場合があります。すべてを公共DNSに任せると、一般のWebサイトは使えるようになっても、内部ネットワークのリソースが使えなくなることがあります。

検査ページに表示されるDNSの出口は、現在のテスト結果にすぎません。すべてのアプリが同じ経路を使う証拠にはならず、サーバーの所在地だけで漏えいを判断することもできません。ブラウザーのDNS設定、クライアントログ、複数アプリの比較と合わせて確認します。システム全体を調べる必要がある場合は、DNS漏えいの検査と設定を参照してください。修正後は一般のドメイン、内部ネットワークのドメイン、IPv6の各ケースを確認し、説明できる名前解決経路を保ってください。

システムプロキシが効かない：アプリの通信が接続されているか確認する

システムプロキシは、アプリが参照する設定であり、OS上のすべての通信を強制的に転送する仕組みではありません。v2rayNで自動設定を有効にすると、通常はローカルプロキシのアドレスがシステムの該当設定に書き込まれます。それでも、コアが正常に待ち受けているか、アプリが設定に従うか、ルーティングがどの出力先を選ぶかは別々の段階です。「設定が有効」と「対象の通信がプロキシを通る」の間には、実際のリクエストによる確認が必要です。

まずローカルプロキシを確認し、次にシステム設定を確認する

インターネットに接続できないの項目にある、プロキシを明示するコマンドでテストします。明示した場合に成功すれば、ローカルの受信側とその出力経路はおおむね使えています。この場合はノードを次々に変更せず、システムプロキシのアドレス、ポート、アプリの動作を確認してください。ホストがローカルのループバックアドレスか、ポートがクライアントの現在の設定と一致しているか、アプリの入力欄がHTTPプロキシとSOCKSプロキシのどちらを求めているかを確認します。異なるプロトコルを混在させないでください。

クライアントのポートを変更した場合は、システム設定やアプリ独自の設定も更新します。起動時にプロキシ設定を読み込むアプリでは、変更後にアプリを完全終了して再起動する必要があります。ウィンドウを閉じただけではバックグラウンドプロセスが終了しないこともあります。テストでは、独自のプロキシ拡張機能を使っていないブラウザー設定をまず利用し、拡張機能による上書きを除外してください。成功を確認したら、拡張機能や個別設定を一つずつ戻して競合の原因を特定します。

デスクトップのOSごとに設定元を確認する

OS主な確認箇所よくある注意点
Windowsシステムプロキシ、ブラウザー拡張機能、アプリ独自の設定バックグラウンドサービスや一部のツールは、ユーザーのプロキシ設定を参照しない場合がある
macOS現在使用しているネットワークサービスのプロキシ設定Wi-Fiと有線接続を切り替えた後は、該当するネットワークサービスの設定を確認する
Linuxデスクトップ環境のプロキシ、アプリ設定、環境変数プログラムによって参照するプロキシ設定が異なることがある

Windowsでは、ユーザーインターフェースのプロキシ設定をすべてのバックグラウンドコンポーネントが共有しているとは限りません。ブラウザーは使えるのに特定のサービスで失敗する場合は、そのプログラムの説明を確認してください。他のプロキシ関連サブシステムをまとめて書き換えないでください。macOSでは、現在使用中のネットワークサービスの設定を変更したか確認します。接続方法を切り替えると、以前の設定が適用されなくなる場合があります。Linuxではデスクトップ環境の設定とターミナルの設定を区別してください。多くの場合、両者は独立しています。

ターミナルのHTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYは、ツールの実装に応じてアプリの動作を上書きしたり補足したりすることがあります。特に、除外リストにテスト対象のドメインが含まれていないか確認してください。調査では、単発のコマンドにプロキシを明示するほうが、環境変数を全体に設定するより簡単に元へ戻せます。動作確認前に、すべてのターミナル起動ファイルを変更しないでください。

システムプロキシと仮想ネットワークインターフェースによる接続を区別する

システムプロキシに従わないアプリや、そのプロキシモードの対象外となる接続方式を使うアプリもあります。その場合は、クライアントが提供する仮想ネットワークインターフェースによる接続を検討します。ルーティングをグローバルに変更しただけで解決したと判断しないでください。このモードには管理者権限、インターフェース用コンポーネント、正しいルーティングが必要な場合があります。他のVPN、仮想マシンのネットワーク、組織のネットワークポリシーと競合する可能性もあるため、先に基本のプロキシ接続が使えることを確認してください。

接続モードでは、プロキシの出力通信が自分自身に戻るループを避ける必要があります。クライアントは通常、除外設定やインターフェース用ルールを生成しますが、ゲートウェイやルートを手動で変更すると、この関係が崩れることがあります。有効にした直後にすべての通信が止まる場合は、いったん無効にして元の接続に戻し、インターフェースの起動ログとルーティングログを確認してください。静的ルートを手当たり次第に追加しないでください。クライアントを終了した後も、別のネットワーク問題が残るおそれがあります。

LAN内での共有は別の利用シーンです。ローカルのループバックアドレスはその端末自身を指すため、他の端末が自分のループバックアドレスを使ってこのPCに接続することはできません。共有が必要な場合は、待ち受けアドレス、端末が実際に使うアドレス、ファイアウォールの範囲を明確にします。接続のためにプロキシポートを、アクセス可能なすべてのネットワークに公開しないでください。この端末だけのトラブルシューティングであれば、不要な要因を減らすため待ち受け範囲は最小限に保ちます。

残った設定を整理し、状態を明確にする

クライアントが異常終了しても、システム設定には停止済みのローカルポートが残り、アプリを閉じた後もネットワークに接続できなくなることがあります。まずシステム設定で使えなくなったプロキシを無効にしてから、クライアントを起動して設定を適用し直します。設定がすぐに書き戻される場合は、別のプロキシ、ブラウザー拡張機能、管理ポリシーが継続的に変更していないか確認してください。組織管理の端末では管理ルールに従い、無理に上書きしないでください。

最後に、システムプロキシに従うアプリ、プロキシを明示するコマンド、個別設定が必要なプログラムをそれぞれ使って確認します。結果はトレイアイコンだけで判断せず、それぞれの設定で説明できる必要があります。復旧手順はv2rayNの初回インストールと設定チェックを参照してください。現在有効なポートを記録しておくと、後で設定を変更した際にアプリの接続問題をノードの障害と誤認しにくくなります。

クライアントがクラッシュする：画面・コア・設定を切り分ける

起動直後に終了する、ウィンドウが固まる、接続後にコアが停止する、といった症状は、関係するプロセスやログが異なります。まず画面が残っているか、トレイのプロセスが動いているか、エラーがアプリ起動時、設定読み込み時、接続開始時のどこで発生するかを確認してください。最初からデータディレクトリを削除したり、上書きインストールを繰り返したりしないでください。使える設定を失ったり、原因を説明できる状況が消えたりするおそれがあります。まずバックアップを取り、最小限の条件で再現します。

インストールパッケージと実行環境を確認する

デスクトップではv2rayNを優先し、プラットフォームとプロセッサーのアーキテクチャに合ったものをダウンロードセンターで確認します。Windowsデスクトップ版と従来のWPF版は画面が異なるため、一方で問題が起きたからといってデータファイルを混在させないでください。macOSではApple SiliconとIntelを区別します。Linuxではアーキテクチャとディストリビューションのパッケージ形式の両方を合わせます。パッケージを展開できても、中のプログラムをOSで実行できるとは限りません。

OSから実行コンポーネントが不足していると表示された場合は、現在のインストール手順に従って必要な環境を追加してください。無関係なポップアップから修復ツールをダウンロードしないでください。macOSで提供元や権限に関する警告が出た場合は、ファイルの入手元を確認し、OSのセキュリティ設定を使って対処します。保護機能を全体的に無効にする方法を通常の手順にしないでください。Linuxではパッケージ管理ツールが示す依存関係を確認し、起動時の問題をすべてファイル権限のせいにしないようにします。

展開して実行する場合は、現在のユーザーが書き込み可能な固定ディレクトリに完全に展開してください。圧縮ファイルのプレビューから直接起動しないでください。同期ツール、保護対象フォルダー、他のプログラムによる使用などでパスに問題があると、設定の保存に失敗することがあります。まず権限が明確なローカルディレクトリで試し、その後にセキュリティソフトの具体的な記録を確認します。隔離の通知がある場合は対象を確かめてください。原因が分からないエラーを回避するために、すべての保護機能を無効にしないでください。

画面の問題とコアの終了を区別する

画面を操作できるのに接続後すぐ停止する場合は、まずコアのログで最初に発生した起動エラーを確認します。ポートの競合、現在のコアが対応しない項目、参照先ファイルの欠落、地理データの読み込み失敗などが考えられます。設定の解析エラーがログにある場合は、受信側が起動していない可能性があるため、システムプロキシを切り替えても解決しません。直近で変更した項目を元に戻し、以前使えていた設定で確認してください。

画面自体が開かない場合は、システムのイベント記録やクライアントの起動ログを確認し、特定のデータファイルの読み込み、ウィンドウ状態、保存先との関係を調べます。元のディレクトリを残し、データを上書きせずに、独立したテスト用ディレクトリから最小構成で起動してください。新しい空の環境で動作しても、問題が古いデータや設定に近いことを示すだけです。過去の設定がすべて壊れていると断定はできません。

設定の問題を安全に絞り込む

まずクライアントを終了し、バックグラウンドプロセスも停止したことを確認してから、設定、サブスクリプションの記録、必要なログを安全な場所にコピーします。テスト環境には動作確認済みの設定を1つだけインポートし、複雑なカスタムルーティングや外部ルールは保留します。最小構成が安定したら、サブスクリプション、ルーティング、その他の設定を少しずつ戻し、問題が再発する箇所を特定してください。この方法なら、すべての設定を作り直して原因が分からないままになるのを避けられます。

コアの切り替えは、設定が対応している場合に限ります。XrayとV2Flyは異なるコア実装であり、すべての項目が共通とは限りません。トランスポートやセキュリティの設定が、別のコアでは異なる扱いになる場合があります。切り替え直後に未対応項目のエラーが出た場合は、元のコアに戻すか、そのコアの機能に合わせて設定を作り直してください。GUI上で項目名が同じでも、完全に互換性がある証拠にはなりません。

リソース不足と移行時の問題を特定する

しばらく動作した後にクラッシュする場合は、起動時の設定だけでなく、メモリ、ディスク空き容量、ログの増加を確認します。ディスク容量が不足すると設定を保存できない場合があります。デバッグログを出し続けることも、ディスクへの負荷を増やします。大量の設定をインポートした場合や特定のルールが関係する場合は、対象を絞って再テストし、再現に必要な最小限のデータを残します。ログにはアドレスやユーザー識別情報が含まれることがあるため、共有前にすべてを個人情報が分からない形にしてください。

更新後に初めて問題が起きた場合は、古いデータのバックアップと移行エラーの記録を保存します。異なるプログラムの状態やデータ形式をそのまま上書きしないでください。元に戻す場合は、元の環境に対応するバックアップを使い、移行済みデータを古いプログラムに読み込ませないようにします。修復後は、起動、インポート、接続、終了、再起動まで一通りテストしてください。一時的に開けるだけでなく、設定を安定して保存し、再び利用できることを確認します。

モバイル端末の問題：VPN権限、アプリ別設定、バックグラウンド動作

Androidではv2rayNGを優先して使います。V2Flyコアが必要な場合は、v2flyNGも検討してください。画面が似ているだけで、2つのクライアントの設定やコアの機能を同じものとみなすことはできません。モバイル端末ではリモート接続に加えて、システムのVPN許可、アプリ別ルール、バックグラウンド制限、ネットワーク切り替えも関係します。まず画面を点灯したまま前面で接続を確認し、その後で画面ロック後の切断を調べると、同時に変化する要因を減らせます。

アプリのアーキテクチャとVPNの許可

インストールできない場合は、アーキテクチャ、システム要件、ストレージの空き容量、既存アプリとの競合を確認します。比較的新しい一般的なスマートフォンでは通常arm64を選びます。アーキテクチャを確認できない場合にのみ汎用パッケージを検討してください。パッケージの違いはアカウント権限の違いを意味しません。署名の競合がシステムに表示されても、すぐに古いアプリをアンインストールしないでください。必要な設定をエクスポートし、バックアップを利用できることを確認します。アンインストールすると、通常はアプリ専用データが削除されます。ダウンロード先はAndroid版ダウンロードです。

初回接続時には通常、システムのVPN許可が必要です。許可の確認を拒否した場合は、クライアントから接続をやり直し、許可の手順を確認してください。仕事用プロファイルや組織のポリシーで管理された端末では、追加の制限がある場合があります。通常、同じユーザー環境で同時に有効にできるVPNサービスは1つです。他のVPN、一部のローカルフィルタリングツールや通信最適化ツールがその枠を使用していることがあるため、接続前にどのサービスが通信を受け持つか確認します。

システムのステータスバーにVPNのアイコンが表示されても、サービスが起動したことを示すだけで、リモートプロキシとのハンドシェイク成功を意味しません。クライアントのログを確認し、Webページへのリクエストも実行してください。常時接続VPNやVPN未接続時の通信をブロックする設定を有効にしていると、クライアント停止後に直接接続できない場合があります。これはシステムのポリシーによる動作です。基本ネットワークを調べる際は設定を確認し、想定された遮断をネットワーク全体の障害と誤認しないでください。

アプリ別ルールと一部アプリだけの問題

特定のアプリだけ接続できない場合は、アプリ別ルールの対象になっているか確認します。画面によって「選択したアプリだけをプロキシ経由にする」場合と「選択したアプリを除外する」場合があり、チェック操作の意味が逆になることがあります。現在のモードと説明を確認し、変更後に接続を作り直して、対象アプリも完全終了してから再起動します。アプリ名が一覧にあるだけでプロキシ経由だと判断せず、実際の接続結果とログを確認してください。

アプリによっては独自のDNS、長時間接続、特殊なトランスポートを使うため、ブラウザーとは異なる動作をすることがあります。まず同じネットワークで他のアプリが使えるか比較し、該当する出力がUDPなどの通信に対応しているか確認します。ブラウザーが使えるからといって、対象アプリのデータをすべて消去しないでください。ログイン状態やローカルファイルを失う可能性があります。まず接続を作り直し、アプリのネットワーク権限を確認してから、明確な目的がある場合にキャッシュの処理を検討します。

画面ロック後の切断とバックグラウンド制限

前面では正常なのに画面ロック後に使えなくなる場合は、システムのバッテリー最適化、バックグラウンド動作の権限、メーカー独自の省電力設定を優先して確認します。必要な範囲でクライアントのバックグラウンド動作を許可し、画面をロックして再テストしてください。すべてのアプリの制限を一度に解除せず、該当するクライアントだけを変更して、消費電力と安定性を確認します。自動起動やバックグラウンドタスクを管理する機能がある端末では、名称は異なっても、意図せずVPNサービスが停止されないようにする点が重要です。

サービス自体が停止したのか、接続は維持されているのに通信リクエストが失敗したのかを区別します。前者ではVPNアイコンが消えたり、プロセスが再起動したりすることがあります。後者では再接続、DNS、リモート側のタイムアウトに関するログを確認します。特に多数のアプリを同時に使っていると、システムのメモリ不足でプロセスが終了する場合もあります。発生した時間帯とシステムの状態を記録し、バックグラウンドのアプリを減らして再テストすると、ノードを何度も変更するより端末リソースの問題を判断しやすくなります。

ネットワーク切り替え後の復旧と報告に必要な情報

Wi-Fiとモバイルデータを切り替えた後は、以前の接続や名前解決キャッシュが一時的に使えなくなることがあります。クライアントが接続を再確立するのを待ってから、新しいリクエストを送ります。失敗が続く場合は、一度切断して再接続し、新しいネットワーク経路を取得したか確認してください。特定のWi-Fiだけで失敗する場合は、Web認証画面とネットワークのアクセス制限を調べます。モバイルデータだけで失敗する場合は、アドレスファミリー、DNS、サーバーへの到達性を比較します。デスクトップの設定をすべてそのまま適用しないでください。

小さなページは開けるのに大きな応答が止まる場合は、通信経路やMTUをさらに調べることができます。ただし、まず既定値を保ち、再現条件を記録してください。パラメーターを適当に小さくすると、一時的に問題が見えなくなる一方で、余分な負荷が増える場合があります。端末間で設定を移す際は手動でインポートし、プロトコルへの対応、ルーティング、ポート、プラットフォームの違いを一つずつ確認します。デスクトップのファイルパス、システムプロキシの方式、権限設定をそのままスマートフォンに移さないでください。

問題を報告する際は、クライアント名、端末のOS、使用ネットワーク、前面表示中か画面ロック中か、アプリ別モード、個人情報を除いた最初のエラーを記載します。接続の問題はノードのタイムアウト、名前解決の問題はDNSの問題を確認してください。操作の基準を作り直す場合は入門ガイドに戻ります。修復後は、前面でのアクセス、画面ロック後の復旧、ネットワーク切り替えの3項目を確認してから、通常の設定に戻します。