V2Rayのよくある質問とトラブル対処

V2RayはProject Vのプロキシツール群の一つで、V2Flyは関連コアの開発を引き継いでいます。Xrayは独立して発展した別系統のコアです。v2rayNはサーバー、サブスクリプション、ルーティング、ローカルプロキシを管理するGUIクライアントで、実際の接続処理は選択したコアが行います。設定項目やプロトコルが認識されない場合は、ウィンドウに表示されたクライアント名だけで判断せず、現在呼び出されているコアとバージョンを確認してください。異なるコア向けのJSON設定はそのまま併用せず、特にトランスポート、セキュリティ、ルーティングの項目を確認しましょう。

Windows、macOS、Linuxのデスクトップではv2rayN、Androidでは通常、Xrayコアを使うv2rayNGを選びます。既存の設定がV2Flyの動作に明確に依存している場合は、v2flyNGも検討してください。いずれもサブスクリプションやサーバー設定をコアに渡して動作しますが、メニューや対応プロトコル、詳細設定は同じではありません。まずOSに合うクライアントを選び、サーバーのプロトコルとトランスポート方式を確認しましょう。乗り換える前にサブスクリプションURLと必要な設定を保存してください。別のアプリのデータフォルダー全体を、そのままインポート設定として使うことはできません。

クライアントのインストールが完了しても、ローカルの管理画面と実行環境が準備できただけで、接続可能なサーバーが自動で用意されるわけではありません。利用権限のあるサブスクリプションURLを追加するか、サーバーアドレス、ポート、ユーザーID、対応するトランスポート設定を入力してください。サブスクリプションはサーバー設定を配布するためのもので、クライアントそのものではありません。有効性やサーバーへの接続可否は、提供元のサービスによって異なります。設定の入手元と有効期限を確認してから追加し、使用するサーバーを選びましょう。認証情報を含むサブスクリプションURLを、公開コメントやスクリーンショット、オンライン変換ツールに載せないでください。

システムプロキシは、システム設定に従うアプリにローカルのプロキシポートへリクエストを渡すよう指示します。ターミナルの一部のコマンドやアプリは、この設定を参照しません。ルーティングは、通信がコアに届いた後、ドメイン名やIPアドレスなどの条件に基づいて、プロキシ、直接接続、遮断のいずれにするかを決めます。TUNモードは仮想ネットワークインターフェースで対象の通信を取り込み、通常はシステムのネットワーク権限、ルーティングテーブル、DNSに関わります。トラブル対処では、まず通常のローカルプロキシでサーバーに接続できることを確認し、その後システムプロキシかTUNを個別に有効にしてください。3つの設定を同時に変更すると、問題の発生箇所を特定しにくくなります。

比較的新しいAndroid端末の多くではarm64版を選べます。universal版は複数のアーキテクチャに対応するため、通常は容量が大きく、端末のアーキテクチャが分からない場合に適しています。購入時期だけでは判断できません。プロセッサが64ビット対応でも、インストールされているOSやアプリの実行環境が32ビットの場合があります。端末の仕様や信頼できるシステム情報画面で確認してください。arm64版でアーキテクチャ不一致と表示されたら、universal版を試します。署名の競合はアーキテクチャの問題ではありません。既存アプリの入手元とアプリ識別子を確認し、設定をバックアップしてからインストールの競合に対処してください。

貼り付けるのはサブスクリプションの完全なURLです。サービスの管理画面トップ、決済ページ、ブラウザーでログインした後のページURLではありません。v2rayNではサブスクリプショングループ設定を開き、グループを追加してURLを保存した後、サブスクリプションを更新します。v2rayNGでも、先にグループを保存してから該当グループを更新してください。コピー時は先頭・末尾の空白や改行、途中で切れたクエリパラメーターがないか確認します。ログにHTMLが返されたと表示される場合は、ログインページやエラーページを取得している可能性があります。正しいURLを入手し直してください。URLの問題を隠すためにエンコード方式を何度も変えたり、認証情報を含む完全なURLを公開したりしないでください。

まず、ディストリビューションのパッケージ形式を確認します。Debian、Ubuntuとその派生ディストリビューションでは通常deb、FedoraなどRPM系では通常rpmを選びます。次にuname -mを実行してアーキテクチャを確認します。x86_64はx64、aarch64は通常arm64に対応します。パッケージ形式とCPUアーキテクチャは別々の条件なので、両方を一致させてください。依存関係を適切に処理できるよう、ディストリビューションのソフトウェアインストーラーまたはパッケージマネージャーを使ってインストールします。依存パッケージが不足していると表示されたら、まず具体的なパッケージ名を確認してください。依存関係を強制的に無視して続行したり、通常のインストールのためにデスクトップクライアントをroot権限で常時起動したりしないでください。

まずTUNを無効にし、通常のローカルプロキシで接続できることを確認してから、システムの権限設定に進みます。Linuxでは、TUNデバイスに加え、仮想インターフェースの作成やルート変更に必要な権限が求められます。具体的な許可方法は、使用中のv2rayNの案内とディストリビューションの仕組みに従ってください。出所の分からないプログラムに安易に高い権限を与えないようにしましょう。Windowsではクライアントの案内に従って必要な操作を許可します。macOSではシステム設定から該当するネットワークまたはVPNの許可を確認してください。AndroidではシステムのVPN接続要求を許可します。通常、VPN接続を使用中の別アプリと同時には実行できません。許可したら接続を再起動し、ログで失敗した操作を確認してください。

まずサブスクリプションを更新し、現在のコアと互換性のあるプロトコルのサーバーを選びます。サーバー名や地域だけで判断せず、クライアントの実接続テストで実際のハンドシェイクを確認してください。通常のレイテンシ測定と実接続テストでは確認経路が異なる場合があるため、どちらか一方の結果だけで実際のアクセス可否は判断できません。使用するサーバーに設定したら必要なプロキシを有効にし、明示したHTTPSのURLにアクセスして、ログに該当リクエストが記録されるか確認します。初回の確認中はルーティングモードを変えず、サーバーやDNSを続けて切り替えないでください。まず同じ手順で再現できる接続経路を確立すると、他の設定と比較しやすくなります。

ターミナルのプログラムは、デスクトップ環境のシステムプロキシを参照するとは限りません。まずクライアントでローカルのHTTPまたは混合待ち受けポートを確認します。10808であれば、curl -I -x http://127.0.0.1:10808 https://example.com を実行して、プロキシを明示してテストできます。SOCKSのみで待ち受けている場合は、その方式に合ったオプションを使い、HTTP用の書式をそのまま流用しないでください。一時的に環境変数を使う場合は、現在のターミナルでhttp_proxyとhttps_proxyを設定し、テスト後に解除します。明示的なプロキシ指定では成功し、通常のcurlでは失敗する場合、すぐにサーバーを変更せず、プログラムがプロキシ設定を読み取る方法を確認しましょう。

まずクライアントのルーティングプリセットを使い、必要なルールだけを追加してください。LANとプライベートIPアドレスは直接接続に振り分けます。特定のサイトにはドメイン名ルールを使いましょう。サイトのトップページから解決された単一のIPアドレスだけを指定すると、複数のサブドメインやCDNアドレスを使うサイトをカバーできない場合があります。ルールは通常、順番に評価されますが、具体的な動作は使用するコアによって異なります。より具体的な例外ルールを適切な位置に置いてください。ルールを保存して適用したら、ログでどのアウトバウンドに一致したか確認します。DNSの名前解決方法もIPベースの判定に影響するため、DNSとルーティングを同時に大きく変更しないでください。

まずクライアントに備わっているエクスポートまたはバックアップ機能を使います。設定フォルダーをコピーする場合は、書き込み途中のファイルが含まれないよう、クライアントを完全に終了してください。サブスクリプショングループ、手動追加したサーバー、カスタムルーティング、必要に応じてDNS設定を保存します。バックアップにはユーザーID、パスワード、サブスクリプションの認証情報が含まれることがあるため、安全な場所に保管してください。新しい端末ではまずサーバー情報を復元し、待ち受けポート、システムプロキシ、TUNの権限を確認します。システム環境に依存する設定は、そのまま引き継がないでください。別のクライアントに移行する場合は、サブスクリプションを再登録し、アプリのデータフォルダー全体を上書きしないようにしましょう。

まずサブスクリプションURLが完全で、サービスが有効であることを確認し、更新ログに記録されたエラーの種類を確認します。タイムアウトは、制限時間内に接続経路が確立できなかったことを示します。ドメイン名の解決に失敗する場合は、現在のDNSを確認してください。HTTP 401または403の場合は、アクセス権限、URLの有効性、サーバー側の制限を確認します。プロキシ経由での更新機能がある場合は、現在のプロキシサーバーが使えることを先に確認してください。プロキシが無効なのにそれを使って更新を続けると、処理が循環することがあります。直接接続と、すでに使えるプロキシ経由の両方を個別に試し、一度に変更するのは1項目だけにします。ログに機密情報を含むURLがある場合は、共有前に認証情報を隠してください。

まず端末自体が正常にインターネットへ接続できることを確認し、サーバーのドメイン名、ポート、プロトコル、トランスポート設定が設定元の情報と一致しているか確認します。TLS serverNameやWebSocket pathなどを手動入力している場合、値が違うとポートへの接続が確立してもハンドシェイクに失敗することがあります。クライアントのログで、名前解決の失敗、接続タイムアウト、接続拒否、TLSエラーを区別し、システム時刻も正確か確認してください。既知の正常な設定や別のネットワークで比較できますが、一度に変更する条件は1つにします。一度のタイムアウトだけでサーバー停止と決めつけたり、接続のために証明書検証を安易に無効化したりしないでください。

起動中という表示は通常、コアのプロセスが動き始めたことを示すだけで、サーバーとのハンドシェイクやWebサイトへのアクセス成功を意味しません。まずローカルプロキシを明示したリクエストでテストし、ローカルポートとサーバー間の接続を確認します。次にブラウザーがシステムプロキシを使用しているか、最後にルーティングとDNSを確認してください。明示的なプロキシ指定では成功し、ブラウザーでは失敗する場合は、拡張機能、個別のプロキシ設定、接続キャッシュを確認します。特定のドメインだけ失敗する場合は、該当するルーティングルールの適用状況とDNSログを確認してください。TUNを有効にした後に問題が起きた場合は、まずTUNを無効にして比較し、他のVPNやネットワークフィルタリングソフトとの競合がないか確認します。複数の通信制御ツールを同時に有効にしないでください。

Linuxのプロキシ設定はデスクトップ環境、アプリ独自の設定、プロセスの環境変数などに分かれており、すべてのプログラムが同じ経路を使うとは限りません。まずシステムプロキシのアドレスがローカルのループバックアドレスか、ポートがクライアントのHTTPまたは混合待ち受けと一致するか確認し、プロキシを明示したリクエストで待ち受けが使えることを検証します。ブラウザーに個別のプロキシ設定や拡張機能がある場合は、別途確認してください。すでに起動しているアプリは再起動が必要なことがあります。ターミナルではhttp_proxy、https_proxy、ALL_PROXY、NO_PROXYの設定が競合していないか確認します。どうしてもプロキシに対応しないアプリでTUNを検討する場合は、権限やルーティングへの影響を理解したうえで使用してください。