v2rayN トラブルシューティング

v2rayNはデスクトップ向けのGUIクライアントで、サブスクリプションのグループ管理、サーバー選択、システムプロキシ、ルーティングを設定します。実際に接続を確立するのは、v2rayNが起動するプロキシコアです。v2rayNGとv2flyNGはAndroid向けで、それぞれXrayとV2Flyを主なコアとして採用しています。このエコシステムを理解するにはProject Vが出発点になります。クライアント名が似ていても、設定ファイルをそのまま相互に使えるとは限りません。問題を調べる際は、クライアントのバージョン、実際に動作しているコア、使用プロトコルを分けて記録してください。クライアントが起動しているだけでは、コアの起動やアプリの通信がプロキシを経由していることは確認できません。

Windowsではv2rayNのデスクトップ版と従来のWPF版を選べます。macOSとLinuxではクロスプラットフォームのデスクトップ版を使用します。デスクトップ版はAvalonia、WPF版はWindowsのUI技術を採用しており、タスクトレイの動作やメニュー位置、一部のシステム連携が異なる場合があります。まずOSとプロセッサーのアーキテクチャに合うパッケージを選び、既存の設定や使い方に応じてUIのバージョンを決めてください。切り替える前にクライアント設定をバックアップし、2つの版を同じフォルダーに展開して上書きしないでください。片方の版だけで問題が起きる場合は、サブスクリプションやサーバーの停止と決めつけず、使用したUIの版と操作手順を記録しましょう。

まず、端末のプロセッサーアーキテクチャまたはシステムの端末情報を確認してください。対応する実行環境を備えた64ビットARM端末では、通常arm64版を選びます。アーキテクチャがわからない場合は、複数のアーキテクチャ向けコンポーネントを含むuniversal版を試せますが、ファイルサイズは大きくなります。購入年だけでは判断できません。プロセッサーが64ビットに対応していても、OSが同じアプリ実行環境を提供しているとは限りません。互換性エラーが出た場合はOSの要件も確認してください。署名の競合が表示された場合は、設定をバックアップしてから、インストール済みアプリの入手元と署名を確認しましょう。すべてのインストール失敗をアーキテクチャの選択に結びつけないでください。

サブスクリプションURLは複数のサーバー設定を取得するためのもので、後から内容を更新できる場合があります。単一のサーバーリンクには通常、1つの接続設定が記述されています。設定ファイルには、インバウンド、アウトバウンド、ルーティング、DNSなどの設定が含まれることもあります。それぞれインポート先が異なるため、サブスクリプションURLを単一サーバーのリンクとして読み込むと、認識されなかったり一覧が空になったりすることがあります。また、サブスクリプションURLは通常のWebサイトのURLとは異なります。ブラウザーにページが表示されても、クライアントが読み込める形式とは限りません。URLにはアクセス認証情報が含まれることが多いため、スクリーンショットやログを共有する前に、URL全体と個人情報を隠してください。

入力したものがサブスクリプションURLか、単一サーバーのリンクかをまず確認してください。サブスクリプションはグループのURL欄に登録して、そのグループを更新します。単一リンクは専用のリンクインポート機能を使います。コピー時に空白や改行、チャットアプリが付けた文字列が混入していないか、必要なパラメーターが欠けていないかも確認しましょう。更新リクエストが成功しても一覧が空の場合は、クライアントログに形式を解析できない旨が記録されていないか確認し、提供元からログイン画面、期限切れ通知、エラーページが返されていないかも調べてください。試行錯誤のためにサーバーをすべて削除するのは避け、既存のグループを残したままテスト用グループを作り、取得元と応答内容を確認しましょう。

システムプロキシの自動設定で変更されるのは、アプリが参照するシステムのプロキシ設定です。すべてのプログラムがそれを使うとは限りません。まずプロキシコアが起動していて、ローカルの待ち受けポートが正常か確認し、システムプロキシのアドレスとポートがクライアントの設定と一致しているか調べてください。ブラウザー拡張機能、個別のプロキシ設定、組織のポリシー、別のプロキシソフトがシステム設定を上書きしていることもあります。設定を変更した後、ブラウザーを再起動して試してください。システムプロキシを使うことが明確なアプリと、問題が発生しているアプリを比べると、接続経路の問題かアプリごとの挙動の違いかを切り分けやすくなります。システムプロキシを参照しないプログラムの通信を取り込む必要がある場合は、先に全体ルーティングへ切り替えるのではなく、TUNを検討してください。

TUNは仮想ネットワークインターフェースを作成してルーティングを変更するため、通常は管理者の許可、またはプラットフォームに応じた権限昇格が必要です。まず重複して起動しているクライアントを終了し、利用中のプラットフォームに必要な権限で起動して、ログに記録された最初のエラーを確認してください。権限不足、インターフェースの作成失敗、ルートの追加失敗はそれぞれ異なる段階の問題です。スイッチを何度も押すだけでは解決しません。組織の管理下にある端末では、管理ルールに従い、制限を回避しようとしないでください。ほかの仮想ネットワークアダプターやVPNがルーティングを使用中でないかも確認しましょう。切り分け中はTUNをオフにし、システムプロキシで動作することを確認してから、仮想ネットワークアダプターによる通信の取り込みとDNS設定を一つずつ戻してください。

追加後、対象グループに認識可能なサーバーが表示されていることを確認し、そのうち1つを有効なサーバーとして選び、コアが正常に起動するか調べてください。次に必要なシステムプロキシのモードを選び、その経路を実際に使うアプリでテストページにアクセスして、対応するアクセス記録やルーティングログを確認します。サーバー一覧に項目が表示されるのは設定が保存されたことを示すだけで、テストに応答があってもすべてのアプリが正常に通信できるとは限りません。確認時は一度に1つの条件だけ変更しましょう。たとえばサーバーはそのままにして、システムプロキシの設定だけ切り替えます。こうすれば設定の解析、サーバー接続、通信の入口、ルーティングルールを個別に確認でき、複数の設定を同時に変えて判断できなくなるのを防げます。

システムプロキシは、アプリの通信をローカルのプロキシ経路に渡すかどうかを決めます。ルールは、コアに入った通信をどのアウトバウンドに送るかを決めます。システムプロキシを自動設定しても、すべての宛先が自動的にプロキシ経由になるわけではありません。また、全体ルーティングを設定しても、システムプロキシを使わないアプリの通信は取り込まれません。「中国本土を除外」などのプリセットを使う場合は、ドメイン、IPアドレス、ルールデータベースの照合条件も把握しておきましょう。特定のWebサイトへの経路が想定と異なる場合は、まず通信がコアに入っているかを確認し、次に一致したルールとアウトバウンドのタグを調べます。切り分けのためにプリセットを一時変更する場合は、元の設定を記録し、テスト後に戻してください。例外を常設する場合は、広範なルールを使い続けるより、対象範囲を明確にしたルールを追加するほうが管理しやすくなります。

サブスクリプショングループの設定で更新が有効になっていることを確認し、項目の説明に従って自動更新の間隔を入力してください。単位は分です。更新頻度はサブスクリプション提供元の案内に従いましょう。頻繁に更新しすぎるとリクエスト制限にかかったり、調査時のログが増えたりすることがあります。プロキシ経由の更新は、サブスクリプションの配信元に直接接続できない一方、利用可能なプロキシがある場合に適しています。そのためには、有効なサーバーが選択され、プロキシコアが正常に動作している必要があります。サーバーがすべて利用できず、更新にもサーバーが必要な場合は、更新ができない状態に陥ります。まず直接接続を復旧するか、利用可能な設定を使ってください。設定後に手動更新を1回実行してログを確認し、その後、自動更新が実行されるかを確認しましょう。

まずログを確認し、名前解決の失敗、接続の失敗、想定と異なるアウトバウンドへの送信のどれかを特定してください。アプリ独自のセキュアDNS、システムDNS、コアのDNSは異なる経路を使うことがあり、いずれか1つを変更しても他に影響しない場合があります。TUNを使っている場合は、DNSリクエストが取り込まれているか、名前解決のリクエストが自身の入口に再び入るループが発生していないかも確認してください。IPアドレスで照合するルールでは、名前解決の結果がルーティング先に影響します。DNSの設定は一度に1つだけ変更し、アプリの接続をやり直して再テストしてください。すべてのDNSサーバーとルーティングルールを同時に変更するのは避けましょう。IPアドレスを直接指定すると証明書のホスト名との照合に失敗することがあるため、この方法は最終的な解決策にはなりません。

まず、使用中のクライアントに備わっているバックアップまたはエクスポート機能を利用し、サブスクリプショングループ、手動追加したサーバー、カスタムルート、必要なパラメーター設定を保存してください。元のクライアントとコアの情報も記録しておきましょう。エクスポートファイルにはサブスクリプションの認証情報やサーバーの認証情報が含まれることがあります。安全な場所に保存し、共有リンクを公開クラウドストレージにアップロードしないでください。異なるプラットフォームやクライアントへ移行する際は、データフォルダー全体をそのまま上書きできると決めつけず、インポート形式と各項目の互換性を確認しましょう。復元後は、ローカルポート、システムプロキシ、TUN、カスタムパスを一つずつ確認します。特に、以前のシステムの絶対パスをそのまま使わないでください。新しい環境で動作を確認できるまで元のバックアップを残しておけば、問題が起きた場合に戻しやすくなります。

タイムアウトは、現在のテストが制限時間内に完了しなかったことを示すだけで、サーバーが恒久的に停止した証拠にはなりません。まずクライアントが使用するテスト方式とテスト先を確認し、ローカルネットワークの状態、システム時刻、サーバーのドメイン名解決、プロトコルのパラメーターを調べてください。ハンドシェイクの失敗、宛先への到達不能、テストサイトへの接続失敗は似た症状になることがあります。コアのログを見て切り分けましょう。ネットワークを変えずに、動作が確認できている設定と比較してください。反対に、設定を変えずにネットワークだけ切り替えて再テストする方法もあります。複数の設定で同時に失敗する場合は、サーバーを一つずつ削除したり、クライアントを何度も再インストールしたりする前に、PC側の通信経路、ネットワーク、コアの起動状態を確認してください。

クライアントの動作状態、テストリクエストの成功、アプリが実際に通信できるかは、それぞれ別の確認項目です。まず問題のアプリがシステムプロキシを使っているか、TUNで通信を取り込まれているかを確認し、次に有効なサーバーとルーティング先が正しいかを調べてください。ドメイン名でのみ接続に失敗する場合はDNSを、特定のサイトだけで問題が起きる場合はルールの適用状況、接続ログ、接続先サービスの状態を確認します。プロキシ拡張機能、古い手動プロキシ設定、セキュリティソフトの影響も除外してください。テストでは通常のブラウザーウィンドウと別のアプリを使って比較し、接続を確立し直して古い経路が使われないようにします。ステータスアイコンだけで通信経路全体が正常だと判断したり、全体ルーティングをすべての問題に効く対処法と考えたりしないでください。

まず更新ログを確認し、URLの無効化、名前解決の失敗、接続タイムアウト、証明書エラー、サーバー側のリクエスト拒否を区別してください。証明書エラーが出た場合は、端末の日付とタイムゾーン、システムの信頼済み証明書が正常かを確認してから、サブスクリプションのドメイン名を調べます。証明書の検証を無効にする方法を、通常の解決策として使わないでください。リクエスト制限が表示された場合は手動での連続再試行をやめ、提供元の案内に従って更新間隔を延ばしましょう。URLの期限切れや認証エラーが返される場合は、サブスクリプションの有効期限と認証情報を確認してください。通常、クライアントを再インストールしても解決しません。ログにはエラーの種類と発生した段階を記録し、サポートへ送る前にサブスクリプションURL全体と認証情報を含む可能性のあるパラメーターを隠してください。

まず、停止したローカルプロキシのポートがシステムに設定されたままになっていないか確認し、必要に応じてシステム設定から元のネットワークプロキシに戻してください。TUNを使っている場合は、クライアントの通常の手順で仮想ネットワークアダプターによる通信の取り込みを解除してから終了します。プロセスを強制終了すると、ネットワーク設定が復元されないことがあります。複数のプロキシやVPNが同時に動作すると、システムプロキシ、デフォルトルート、DNSをそれぞれ変更する場合があるため、切り分け中は通信を取り込むソフトを1つだけにしてください。ポートが使用中の場合は、使用しているプログラムを確認してから対処し、システムプロセスをむやみに終了しないでください。基本の通信を復旧した後、機能を一つずつ有効にして問題が再現する段階を確認しましょう。リモート操作中にルートを変更する場合は、元に戻す手段を用意してください。