v2rayNの問題診断とトラブルシューティング

1. クライアントは起動しているのにインターネットに接続できない

まず、「すべてのサイトにアクセスできない」のか「一部のサイトだけ開けない」のかを切り分けます。前者ではプロキシの入口とサーバー接続、後者ではルーティングルールとDNSを優先して確認します。ブラウザーに接続エラーが表示されても、サーバーの故障とは限りません。リクエストがクライアントに届いていない場合も、届いた後に適切でない出口へルーティングされている場合もあります。以下の順に確認し、各手順の結果を記録してください。

選択中のサーバーと動作状態を確認する

v2rayNのサーバー一覧で、現在選択されているサーバーがあることを確認します。サブスクリプションを追加しただけでサーバーを選択していない場合や、更新後に元の項目が置き換わった場合は、その後の確認対象がなくなっている可能性があります。クライアントのログを開き、起動時に設定の読み込みエラー、コアの起動失敗、ポートの競合、接続失敗がないか確認してください。起動時点でエラーが出ている場合は、まずログに記録された最初の具体的なエラーに対処し、いきなりDNSを変更しないでください。

一時的に、動作することが確認済みの別のサーバーを選んで再テストします。1台だけ失敗する場合は、そのサーバーのアドレス、ポート、トランスポート設定を優先して確認します。すべて失敗する場合は、ローカルのプロキシ入口とネットワーク環境を確認してください。サーバー情報はサブスクリプション提供元、または自分で管理するサーバーの設定を参照してください。ユーザーID、PublicKey、ShortIdを記憶に頼って入力しないでください。変更前に元の項目を複製しておくと、比較や元に戻す際に便利です。

システムプロキシと適用範囲を確認する

v2rayNのシステムプロキシメニューで現在の状態を確認します。ブラウザーがシステムプロキシを使用する場合、クライアントが起動していても、OSがブラウザーの通信をクライアントに渡しているとは限りません。システムプロキシを必要なモードに切り替え、ブラウザーのウィンドウを一度閉じてから開き直してテストしてください。また、ブラウザー独自のプロキシ設定や拡張機能がシステムプロキシを上書きしていないか確認します。他のアプリがシステムプロキシに従うかどうかは、アプリの実装によって異なります。

プロキシ経路だけを確認する場合は、一時的にグローバルプロキシへ切り替えて同じ接続先をテストできます。グローバルモードではアクセスでき、通常のルーティングモードではアクセスできない場合、入口とサーバーはおおむね動作していると考えられます。再インストールを繰り返すのではなく、ルーティングルールを確認してください。テスト後は元のモードに戻し、診断のための変更を日常の設定に残さないようにします。TUNはより多くの通信を処理できますが、未確認のシステムプロキシの問題を覆い隠す目的で使うべきではありません。

ログからリクエストが止まっている箇所を特定する

クライアントのログ画面を開き、テスト用のページを一つだけ開いて、該当する接続記録が表示されるか確認します。記録がまったくない場合は、システムプロキシ、アプリ独自のプロキシ、またはTUNの入口を確認してください。リクエスト記録があり、接続先の名前解決に失敗している場合は、このページのDNSの章へ進みます。リモートへの接続がタイムアウトしている場合は、ノードのタイムアウトの章を確認してください。ログにルールによって直接接続またはブロックの出口が選ばれたと明記されている場合は、ルーティング設定を確認します。

テストでは同じブラウザー、同じ接続先、同じサーバーを使い、複数のタブのリクエストが混ざらないようにします。ログの「クライアントが起動しました」を「接続先のサイトにプロキシ経由で接続できた」と解釈しないでください。確認できるのはプログラムが動作状態になったことだけです。必要に応じて、通常は直接接続するサイトと、現在のプロキシルールで処理されることが明確なサイトをそれぞれテストし、ルールの適用結果を比較します。

ローカルネットワークと残存プロキシ設定を確認する

クライアントのシステムプロキシ設定を一時的にオフにし、現在のネットワークで本来直接アクセスできるページが開くか確認します。直接接続もできない場合は、Wi-Fi、有線接続、ゲートウェイ、OSのネットワーク設定を先に確認してください。プロキシクライアントで、切断された基本ネットワークを修復することはできません。また、別のプロキシアプリが同じ待ち受けポートを使用していないか、OSに古いプロキシアドレスが残っていないか確認します。ログにポート競合が記録されている場合は、ノードを何度も切り替えるより先に対処する価値があります。

トラブルシューティングが終わったら、システムプロキシとルーティングモードを使用予定の状態に戻し、最初に失敗した操作をもう一度試します。特定のアプリだけで問題が起きる場合は、そのアプリのプロキシ設定とネットワーク権限を確認してください。一つのアプリの挙動を、端末全体の問題と決めつけないようにします。「接続済みなのにウェブページが開かない」などの短いQ&Aはヘルプセンターをご覧ください。基本設定を一から行う場合は、ガイドに戻ってください。

3. サブスクリプションの更新に失敗する、またはサーバー一覧が空になる

サブスクリプションの更新には、「内容の取得」と「内容の解析およびグループへの登録」という二つの段階があります。エラーが出たら、内容を取得できていないのか、取得後にクライアントが認識できないのかを切り分けます。一覧が空でも、現在のフィルター条件によってサーバーが非表示になっているだけの場合があります。元の設定を保存してから、一つずつ確認してください。既存のサブスクリプションのアドレス、グループ、フィルターをむやみに変更しないでください。

サブスクリプションURLと現在のネットワークを確認する

v2rayNのサブスクリプショングループ設定を開き、URLに余分な空白や改行が入っていないか、途中で切れていないかを確認します。そのグループが有効になっているかも確認してください。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、機密情報として扱います。URL全体を公開スクリーンショットや質問投稿に載せないでください。提供元に問い合わせる場合は、エラーの種類、発生時刻、クライアントだけを伝え、リンク全体は公開しないでください。

更新に失敗したら、まず端末から通常のウェブページにアクセスできることを確認します。次に、サブスクリプショングループの更新方式を見て、リクエストに既存のプロキシが必要か確認してください。初回の追加時に利用可能なノードがない状態で、現在のプロキシに依存する取得経路を指定すると、「更新するには先にノードが必要」という循環が起きることがあります。既存ノードは使えるのにサブスクリプションのリクエストだけが失敗する場合は、直接接続とプロキシ経由の更新をそれぞれ試し、URLに実際にアクセスできる方式を選んでください。

ネットワークエラーと内容のエラーを切り分ける

ログにドメインの名前解決失敗や接続タイムアウトが表示される場合は、URLのドメイン、ネットワーク接続、取得経路を優先して確認します。アクセス拒否や、サブスクリプション形式ではない内容が返されたと表示される場合は、認証と内容の形式について提供元に問い合わせてください。クライアントがウェブページをダウンロードできても、それがインポート可能なノード一覧とは限りません。URLをブラウザーで開いたときにログインページ、案内ページ、エラーページが表示される場合、更新を繰り返しても有効なサーバーは追加されません。

ログに解析失敗が表示された場合、取得した内容を手動でサーバー編集画面に貼り付けないでください。サブスクリプションには通常、複数の設定が含まれており、個別サーバーの項目だけではグループ、フィルター、更新ルールを完全に表現できません。確認済みのURLだけを入力した一時的なサブスクリプショングループを作成し、テストする方法があります。一時グループで正常に更新できる場合は、元のグループの更新方式やフィルター設定を重点的に確認します。原因がわかったら、一時グループを削除し、同じサーバーが重複して残らないようにしてください。

サーバーを追加したのに一覧に表示されない

選択中のサブスクリプショングループ、一覧の検索ボックス、キーワードフィルターを確認します。グループを切り替えると、そのグループの項目だけが表示される場合があります。フィルター語句によって、すべての項目が非表示になることもあります。まず検索条件をクリアし、すべてのサーバーを表示してから、ログや更新結果に項目が登録されたかを確認してください。特にキーワードルールを変更した直後は、一覧が空だからといってサブスクリプション自体が無効だと判断しないでください。

インポートに成功したものの件数が想定と異なる場合は、サブスクリプション提供元が内容を変更していないか確認し、重複排除、フィルター、グループへの割り当てを見直します。異なるサブスクリプションのサーバー名が似ていても、設定が同一とは限りません。複数の配信元を整理する方法はv2rayNの複数サブスクリプショングループ管理をご覧ください。トラブルシューティング中はフィルターをできるだけ少なくし、表示を確認してから一つずつ戻すことをおすすめします。

更新結果を再現できるようにする

更新ボタンを連続してすばやく押すのではなく、「手動で一度更新」した結果を正確に記録します。リクエストが終わる前に更新を再実行すると、ログが入り交じり、どちらが失敗したのか判断しにくくなります。更新の前後でグループ名、サーバー一覧、最後に記録された具体的なエラーを確認します。サブスクリプションが複数ある場合は一つずつ更新し、一つの配信元だけが失敗するのか、すべて失敗するのかを切り分けます。すべて失敗する場合は、端末のネットワークとリクエスト方式を先に調べるとよいでしょう。

古いノードがまだ使える場合は、ネットワーク確認のために残しておき、サブスクリプションの問題を解決する目的で既存サーバーをグループごと削除しないでください。古いノードも同時に使えなくなった場合は、ネットワークの切り替えやシステムプロキシの状態変化がなかったか確認し、「インターネットに接続できない」の章に戻って入口を調べます。サブスクリプションの更新とノードへの接続は別の経路です。更新に失敗しても、保存済みのノードがすぐ使えなくなるとは限りません。ノードに接続できても、サブスクリプションURLにアクセスできるとは限りません。

5. DNSの名前解決エラー、汚染、名前解決とルーティングの不一致

DNSはドメイン名を接続に使えるアドレスへ変換し、ルーティングはリクエストの出口を決めます。これは別々の設定です。ブラウザーにサーバーが見つからないと表示される、特定のドメインが時々しか開かない、ドメイン名では失敗するのに既知のアドレスなら接続できる場合は、名前解決の経路を確認してください。上流を変更したりFakeDNSを有効にしたりする前に、「どこで、いつ名前解決し、その結果がどの出口に渡されるのか」を特定します。

サーバーのドメイン名か、接続先サイトのドメイン名かを確認する

ノードへの接続前に、クライアントがサーバーアドレスを名前解決する場合があります。プロキシ接続の確立後に接続先のサイトへアクセスすると、別の名前解決が行われることもあります。ログで失敗したドメインがどの段階のものかは重要です。サーバーのドメイン名の名前解決に失敗すると、そのノードは接続開始時点で利用できません。接続先サイトのドメイン名の名前解決に失敗した場合は、一部のサイトだけ開けないことがあります。ログに明記されたドメインの種類を記録し、どちらも単に「DNSの調子が悪い」とまとめないでください。

OS標準の名前解決コマンドを使って、端末がドメインレコードを取得できるか確認できます。例ではこのサイトのドメインを使っていますが、操作方法を示すだけのものです。名前解決の結果はネットワークや時間によって変わるため、固定設定としてそのまま使わないでください。コマンドが成功しても、クライアントが同じ名前解決サーバーを使っているとは限りません。ブラウザー、OS、クライアント、TUN環境では、名前解決の経路が異なる場合があります。比較する際は、どの入口からコマンドを実行したかを記録してください。

nslookup v2raypeizhi.com

ドメイン名と出口に応じてDNS設定を確認する

v2rayNのDNS設定とルーティング設定を確認し、対象ドメインが直接接続とプロキシ接続のどちらを使うかを特定してから、その経路でどの名前解決方式が使われるかを確認します。直接接続の通信で別のネットワークでしか到達できないアドレスが返された場合や、プロキシ通信でローカルから適切でない名前解決が行われた場合、「ルールは正しく見えるのに接続できない」という状況が起きます。変更前に既存のDNS設定をバックアップしてください。一度に変更するのは、一つの上流または一種類のドメインルールだけにします。

カスタムDNSを設定している場合は、ルールの照合順とデフォルトの上流を確認します。ドメインの個別ルールに一致しないリクエストは、デフォルトの経路に進みます。DoH、従来のDNS、システムの名前解決は用途に応じて組み合わせられますが、追加する上流にも到達可能なネットワーク経路が必要です。上流のドメイン名をさらに解決する必要がある場合は、そのための初期名前解決も考慮してください。設定例と確認手順はV2Ray DNS分割設定の詳しい解説をご覧ください。

FakeDNSを確認するタイミング

FakeDNSはまずドメイン名に仮想アドレスを割り当て、その後、通信のスニッフィングと組み合わせて接続先のドメイン名を関連付けます。端末の通信を取り込みつつ、ルーティングの照合にドメイン名を使いたい場合によく利用されます。「DNSエラーが起きたら有効にする」ための万能な修復機能ではありません。スニッフィングが実際の通信を捕捉できない場合や、名前解決で得た実アドレスをアプリが直接必要とする場合は、有効化によって新たな互換性の問題が起きることがあります。

トラブルシューティングでは、まず元の設定で失敗する接続先を記録し、FakeDNS関連の設定だけを変更して同じアプリを再テストします。この項目の有効・無効によって結果が安定して変わる場合に限り、スニッフィング、仮想アドレスの対応付け、ルーティングルールを確認します。仕組みと制約についてはFakeDNSの仕組みをご覧ください。割り当てられた仮想アドレスをリモートサーバーの実アドレスと誤認したり、それを根拠にサーバー項目のaddressを変更したりしないでください。

キャッシュと一時的な名前解決の違いに対処する

DNSを変更した後も、ブラウザー、OS、アプリが以前の結果をキャッシュしていることがあります。テストするアプリをいったん終了して開き直し、同じネットワークで再テストしてください。必要に応じて、OSが提供するDNSキャッシュの消去機能を使います。キャッシュを消去できるのは古い応答だけで、誤った上流の選択やルーティング出口は修正できません。しばらくすると再発する場合は、キャッシュを何度も消去するのではなく、実際のリクエスト経路を引き続き確認してください。

特定のドメインだけに問題がある場合は、ドメイン名、発生時刻、使用ネットワーク、ルーティングの照合結果、名前解決段階のログを記録します。すべてのドメインで問題がある場合は、まずローカルネットワークとDNS上流への到達性を確認してください。比較中に新しいDoH、FakeDNS、TUNを同時に有効にしないでください。「何を変更したか、結果はどうだったか、元に戻したか」を各手順で記録すれば、どの段階が問題を解決したか確認できます。

7. クライアントが起動しない、クラッシュする、コアの起動に失敗する

画面が開かない場合と、画面は開くもののコアが起動しない場合は、別の問題です。まず、どの段階で失敗するか確認します。ダブルクリックしてもウィンドウが表示されない、ウィンドウが開いてすぐ終了する、設定をインポートした後に終了する、接続をクリックしたときにコアエラーが出る、といった状況を区別してください。ログと現在の設定を保存してから、インストール環境や設定エラーを調べます。最初にすべてのユーザーデータを削除して再インストールしないでください。

インストーラーと実行環境を確認する

OSとプロセッサーアーキテクチャに合ったクライアントがインストールされているか確認します。デスクトップでは主にv2rayNを使用します。WindowsユーザーはダウンロードセンターのWindows欄でデスクトップ版と従来のWPF版を確認してください。macOSとLinuxでは、それぞれのプラットフォームに合ったものを選びます。通常の読み書き権限がある場所にアプリを置き、アクセス制限のある場所や読み取り専用の場所から直接実行しないでください。ダウンロードが完了する前にファイルを開くことも避けてください。

更新後に起動できなくなった場合は、更新前後の操作、インストール形式、エラー内容を記録し、古いプロセスが残っていないか確認します。複数のインスタンスを起動すると、待ち受けポートが競合することがあります。OSのタスク管理ツールで応答しなくなった古いインスタンスを終了してから、単独で一度起動してください。再インストールする前に、サブスクリプショングループと自分で編集した設定を保存します。「プログラムの起動失敗」を「設定の消失」にしないためです。

画面は正常だがコアでエラーが発生する

v2rayNのログを開き、設定の解析、ポートの待ち受け、コアの起動に関する最初の具体的なエラーを確認します。ポート競合の場合は、別のクライアントインスタンスやローカルソフトが該当する入口を使用していないか調べます。設定の解析エラーの場合は、直近で変更したサーバー項目、ルーティング、DNS設定を見直してください。末尾の「起動に失敗しました」だけをコピーしないでください。通常は、その前に記録された具体的なエラーが原因です。

手動で変更していない別のサーバーを一時的に選び、最近追加したカスタムルールを無効にして再テストできます。この状態で起動できる場合は、設定を一つずつ戻して、エラーの原因を特定します。別のコアを使う場合は、選択したプロトコルとパラメーターが現在のコアでサポートされていることも確認してください。XrayとV2Flyですべての機能が対応しているわけではありません。詳しくはXrayとV2Flyのコアの違いをご覧ください。

権限、セキュリティソフト、設定ファイルの破損を確認する

ログにファイルの読み書きエラーが表示される場合は、プログラムと設定の保存先のアクセス権、ディスクの空き容量を確認します。セキュリティソフトのブロック通知がある場合は、対象のファイル、操作、時刻を確認し、今回の起動失敗に関係するか判断してください。トラブルシューティングのためにシステム保護を長期間無効にしないでください。インストール先を変更する場合は、サブスクリプション情報とカスタム設定をバックアップしてから、対象プラットフォーム用のインストーラーで再セットアップします。

既存の設定を読み込むときだけプログラムが終了する場合は、完全なバックアップを残したうえで、初期状態の設定で画面が開くかテストできます。初期設定で起動できるなら、元の設定または参照ファイルに問題がある可能性が高くなります。それでも起動できない場合は、インストール環境とシステムログを重点的に確認してください。サブスクリプションURLを含む設定ファイルを、そのまま公開アップロードしないでください。問い合わせる際は、機密項目を伏せたエラー情報だけを共有します。

再現可能な復旧手順を組み立てる

まず画面が安定して開くことを確認し、次にコアが起動することを確認します。その後、根拠のあるサーバー設定を一つインポートし、最後にサブスクリプション、ルーティング、DNSのカスタム設定を戻します。一つ追加するたびに起動してログを確認すれば、どの段階で問題が再発したかを特定できます。古い設定を一度にすべて戻して問題が起きた場合、原因の箇所がわかりません。設定を戻す順序自体が診断の手順になります。

解決後は、システムプロキシが現在起動中のクライアントを指しているか、プログラム終了後にシステムプロキシが正常に無効になるかも確認します。クラッシュとプロキシ設定の残存は続けて発生することがありますが、別々に対処してください。前者はプログラムと設定、後者はOSのプロキシ状態を確認します。よくあるインストールの疑問はヘルプセンターをご覧ください。最初から設定する場合は、ガイドに沿って進めてください。