よくある質問設定・接続のトラブルシューティング

V2RayはProject Vのプロキシエコシステムに属し、V2Flyは関連するコアの保守を引き継いでいます。Xrayは同じ技術エコシステムにおける別のコアです。v2rayNはサーバーを管理し、設定を生成して、選択したコアを起動するGUIクライアントです。問題を調べる際は、画面操作の失敗とコアの起動失敗を切り分けましょう。サブスクリプション一覧が空なら取得結果を確認し、サービスの起動エラーならログに記録されたコア、設定、ポートの情報を確認します。クライアント名だけで特定のプロトコル構成が動作すると判断せず、実際に使用するコアとサーバー側の要件も確認してください。

デスクトップではv2rayNがおすすめです。ダウンロード時はWindows、macOS、Linuxの別とプロセッサのアーキテクチャに合ったパッケージを選んでください。WindowsではクロスプラットフォームのデスクトップUIと従来のWPF UIを選べますが、メニューの位置や実行に必要な環境が異なる場合があります。AndroidではXrayコアをベースにしたv2rayNGが第一候補です。V2Flyコアの環境が必要な場合はv2flyNGを検討してください。クライアントを切り替える前にサブスクリプションURLとカスタムルールを保存し、新しいクライアントがノードのプロトコルとトランスポートの組み合わせに対応しているか確認しましょう。既存の設定フォルダーをそのまま上書きしないでください。

クライアントはローカルでの設定と接続に使うもので、インストールしただけでは接続先のリモートサーバーは用意されません。サブスクリプションURLからは複数のノード設定を取得でき、単一ノードのリンクには通常、1台のサーバーの接続情報が含まれています。いずれも信頼できる提供元から入手し、サービスごとの有効期限、利用上限、利用規約を確認してください。サブスクリプショングループの設定にはサブスクリプションURLを入力します。サービス提供元のアカウントページのURLを代わりに使わないでください。URLに含まれるアクセス情報は認証情報として扱い、スクリーンショットや問い合わせ、ログを共有する前に必ず隠してください。

システムプロキシは、OSの設定に従うアプリにローカルのプロキシ接続先を提供します。ルーティングは、コアに届いた接続をプロキシ経由、直接接続、ブロックのいずれにするか決めます。TUNは仮想ネットワークインターフェースを通じて、より多くのアプリの通信を取り込みます。それぞれ役割が異なるため、システムプロキシを設定しても、すべてのアプリの通信がコアに届くとは限りません。また、グローバルルーティングを選んでも、プロキシを使わないプログラムの通信を強制的に取り込むことはできません。初めて設定する場合は、まずシステムプロキシでブラウザーの接続を確認し、次にルーティングを調整して、必要に応じて最後にTUNを有効にしましょう。原因を特定しやすくするため、一度に変更する項目は1つにしてください。

まず圧縮ファイルをすべて展開し、現在のアカウントで書き込み可能な専用フォルダーに保存してください。展開先のv2rayN.exeを実行し、圧縮ソフトのプレビュー画面から直接起動しないでください。OSとプロセッサのアーキテクチャに合ったパッケージか確認します。実行環境の不足が明示されている場合は、使用中のバージョンの説明に従って必要な依存関係を導入し、関係のないコンポーネントをむやみに追加しないでください。続いて、セキュリティソフトの隔離履歴とフォルダーの書き込み権限を確認します。それでも起動しない場合は、エラー全文、OSのバージョン、使用中のUIのバージョンを記録し、原因調査のため元のフォルダーを残してください。何度も上書きインストールするのは避けましょう。

比較的新しい一般的なAndroid端末ではarm64が適していることが多いものの、最終的には端末のプロセッサとOSが対応するアプリのアーキテクチャを確認してください。購入年だけでは判断できません。OSがarm64に対応していると確認できた場合は、対応するパッケージを選びます。確認できない場合やアーキテクチャの不一致が表示される場合は、複数のアーキテクチャを含むuniversalパッケージを試してください。「アプリをインストールできません」と表示された場合は、空き容量、OSの要件、旧バージョンとの署名の互換性も確認しましょう。設定が残っているクライアントをすぐにアンインストールせず、復元できるよう設定をエクスポートしてから、再インストールするか判断してください。

まず、入手したものがサブスクリプションURL、単一ノードのリンク、ログイン専用のWebページのどれか確認します。サブスクリプションURLはサブスクリプショングループの設定に入力し、保存後にそのグループの更新を実行します。単一ノードのリンクは、クリップボードからのインポートなど、対応する方法で読み込みます。QRコードをスキャンしても結果が表示されない場合は、内容がWebページである、リンクが途中で切れている、現在のクライアントがその形式に対応していない、といった原因が考えられます。元のテキストをもう一度コピーし、前後の空白や改行を取り除いてから、インポート時のメッセージを確認してください。URLの漏えいを防ぐため、個人用サブスクリプションを見知らぬオンライン変換サイトに入力しないでください。

まずTUNを無効にし、通常のシステムプロキシで接続できることを確認してから、仮想インターフェースの問題を調べます。Windowsではクライアントの案内に従って必要な権限で起動してください。macOSとLinuxでは、現在のバージョンが求める権限昇格やサービスの設定を確認します。ログを確認し、権限不足、インターフェースの作成失敗、ルートの追加失敗、DNS設定の失敗を切り分けましょう。起動エラーをすべてノードの問題と決めつけないでください。ほかの仮想ネットワークアダプターやトンネルツールを一時的に終了してから再試行します。有効化後にネットワークに問題が起きた場合は、まずTUNを無効にして通信が戻ることを確認してから、具体的なエラーに応じて設定を調整してください。複数のルート設定を同時に変更するのは避けましょう。

まずサーバー一覧から使用するサーバーを選び、コアが起動していることを確認します。次にメイン画面またはタスクトレイのシステムプロキシメニューから、システムプロキシの自動設定を選択してください。OSに設定されたプロキシのアドレスとポートが、クライアントの現在の待ち受け設定と一致しているか確認し、テストするアプリを開き直します。ブラウザー拡張、アプリ独自のプロキシ設定、ほかのプロキシツールがシステム設定を上書きすることがあるため、一時的に無効にして再確認してください。特定のアプリだけで効かない場合は、そのアプリがシステムプロキシに従うか確認します。従わない場合はアプリ側のプロキシを設定するか、通常の接続を確認したうえでTUNを検討してください。

サブスクリプショングループの設定で提供元ごとにグループを作成し、提供元や用途が分かるメモを付けて、それぞれ対応するサブスクリプションURLを入力します。初回はグループごとに更新し、各グループから正常に情報を取得できたことを確認してから、すべてのサブスクリプションを更新しましょう。サーバーを探すときは、まずグループを切り替えてからメモのキーワードで絞り込みます。絞り込みは表示範囲を変更するだけで、サーバーの削除ではありません。手動で追加したノードは、サブスクリプション管理の項目とは分けて保存し、更新前に旧項目がどのように扱われるか確認してください。URLが無効になった場合は、同じ名前のグループを増やさず、既存のグループを編集しましょう。

通常はルーティング設定で、中国本土を迂回するルールを必要に応じて選択します。該当ルールに一致した通信は直接接続され、それ以外はルールに従って処理されます。ルーティングが原因か切り分けるには、一時的にグローバルプロキシルートへ切り替え、同じサーバーから同じ接続先にアクセスして比較してください。テスト後は元のルールに戻します。グローバルルーティングの対象はプロキシコアに届いた通信だけで、すべてのアプリを自動的に取り込むわけではありません。カスタムルールの優先順位、ドメインの判定方法、ルールデータも結果に影響します。変更前に現在のルールを保存し、一度に調整する条件は1つにしてください。

まずクライアントを終了し、関連プロセスが停止したことを確認してから、設定フォルダーをバックアップするか、現在のバージョンにエクスポート機能があれば利用します。サブスクリプショングループ、手動追加したノード、カスタムルート、DNS設定、ローカルの待ち受けポートを忘れずに保存してください。サブスクリプションURLも安全な場所に保管します。アップグレード前に使用中のバージョンの移行案内を確認してください。特にUIの異なるバージョン間や、大きく異なるバージョン間の更新では、古い設定をそのまま上書きできるとは限りません。更新後はサービスの起動、単一ノード、サブスクリプションの更新、普段使うアプリの順に確認し、安定してから古いフォルダーやバックアップを整理しましょう。

まずサブスクリプションの有効期限、URLがリセットされていないか、コピー時にクエリパラメーターが欠けていないか確認します。次に更新ログを確認し、接続失敗、証明書エラー、空の応答、形式の解析エラーを切り分けてください。現在のプロキシが使えない場合は、クライアントに更新方法の選択肢があれば、プロキシを経由せずに取得する方法を試します。必要であれば、正常に使える別のネットワークでも比較してください。ログインページ、認証ページ、エラーページは有効なサブスクリプションデータではないため、再インポートしても解決しません。既存のサーバー一覧を残したまま、応答内容とサービスの状態を確認してから、グループを作り直すか判断しましょう。

テストのタイムアウトは、今回のテストが制限時間内に完了しなかったことを示すだけで、すべての接続が使えないとは限りません。まず端末自体がインターネットに接続できることを確認し、使用中のサーバー、システム時刻、ノードの有効期限を調べます。TCPテストと、プロキシ経由で実際にWebページへアクセスするテストでは確認できる範囲が異なるため、実際のアクセス結果とコアのログをあわせて判断してください。同じネットワークで別の正常なノードをテストするか、別のネットワークで同じノードを試すと、問題の範囲を絞れます。ログに認証エラーやハンドシェイクエラーがある場合は、ノードの設定値とコアの対応状況を確認し、タイムアウト時間を何度も延ばすだけで済ませないでください。

「実行中」は通常、ローカルのサービスが起動していることを示すだけで、リモートサーバーへの接続成功を意味しません。まずプロキシを無効にして基本のネットワーク接続を確認し、再度有効にして使用中のサーバー、システムプロキシのアドレス、待ち受けポートを確認します。すべてのWebサイトに接続できない場合は、コアのログに接続エラーや認証エラーがないか調べてください。一部のドメインだけ開けない場合は、ルーティングルールの適用状況、DNS名前解決、ブラウザーのセキュアDNS設定を確認します。ブラウザーのプロキシ拡張を一時的に無効にし、別のブラウザーでも比較してください。設定を一度にすべてリセットするのは避けましょう。TUNとシステムプロキシを同時に有効にしている場合は、まずTUNを無効にすると切り分けが簡単になります。

まずログで競合している待ち受けポートを確認します。必ず10808とは限りません。Windowsではターミナルでnetstat -anoを実行し、待ち受け中のポートとプロセスIDを確認してから、タスクマネージャーでプロセス名を調べられます。古いクライアントが重複して起動している場合は、まず通常の方法で終了してください。正体の分からないシステムプロセスを強制終了しないでください。設定のパラメーター設定にある該当のローカル待ち受け項目を、未使用のポートに変更してサービスを再起動する方法もあります。変更後はシステムプロキシを再設定し、ブラウザー拡張や手動でプロキシを設定したアプリもあわせて調整します。ポート番号が同じでも、HTTPとSOCKSのプロトコルを互換的に使えるとは限りません。