V2Rayのよくある質問

V2RayはProject Vのプロキシツールエコシステムに属し、V2FlyはV2Rayをコミュニティで引き継いで開発しています。Xrayはこのエコシステムから派生したコアです。コアはプロトコル処理、ルーティング、データ転送を担い、v2rayN、v2rayNG、v2flyNGは設定管理やGUI操作を提供します。v2rayNGはXray、v2flyNGはV2Flyを使用します。v2rayNで実際に使われるコアは、バージョンや設定によって異なります。利用するプロトコルに対応しているか確認するには、画面上に似た名称があるかだけでなく、クライアントのバージョン、実際に起動するコア、サーバー側の設定をあわせて確認してください。

クライアントをインストールしただけでは、ローカルのツールが使える状態になったにすぎず、接続先のサーバーが用意されたわけではありません。通常は有効なサブスクリプションや共有リンクを読み込むか、サーバーから提供されたアドレス、ポート、認証情報、通信パラメーターを手動で入力します。当サイトではクライアントの案内と設定ドキュメントを提供していますが、ノードやサブスクリプションは提供していません。設定済みの場合も、有効期限、サービスの稼働状況、プロトコルの互換性を確認してください。提供元が不明なサブスクリプションで既存の設定を上書きせず、まず別のグループを作成して入手元と用途を確認し、ノードを選んで接続テストを行いましょう。

システムプロキシは、システムのプロキシ設定に従うアプリにローカルのプロキシアドレスを提供しますが、すべてのプログラムで使えるとは限りません。ルーティングルールは、通信がコアに届いた後でどのアウトバウンドを使うか決めるもので、クライアントを経由していない通信を自動的に取り込むことはできません。TUNは仮想ネットワークインターフェースを使って対象の通信を取り込み、システムルート、DNS、権限にも関係します。トラブル対処では、アプリの通信がクライアントに届いているか、ルールに一致しているか、アウトバウンドが使えるかの順に確認してください。初期設定では、まずシステムプロキシでブラウザーの接続を確認し、その後TUNを個別にテストすると、複数の入口を同時に変更せずに済みます。

Windows、macOS、Linuxのデスクトップでは、まずv2rayNを確認してください。AndroidではXrayコアを採用したv2rayNGが第一候補です。V2Flyコアが必要な場合はv2flyNGも検討しましょう。選ぶ際は名称の似かよりではなく、OS、デバイスのアーキテクチャ、既存設定のプロトコル要件を基準にします。Windows版v2rayNにはクロスプラットフォームUIのデスクトップ版と、従来型UIのWPF版があり、メニューの位置が異なる場合があります。クライアントを切り替える前に設定をバックアップし、移行先が既存の通信・セキュリティパラメーターに対応しているか確認してください。別のクライアントの内部データベースをそのままコピーするのは避けましょう。

arm64は64ビットARMシステムを搭載したデバイス向けです。2015年以降の一般的なAndroidスマートフォンではまず候補になりますが、最終的には端末のシステムが対応するABIを確認してください。universal版には複数のアーキテクチャ向けネイティブコンポーネントが含まれており、アーキテクチャを確認できない場合に選べますが、ファイルサイズは大きくなる傾向があります。CPUが64ビット対応でも、インストールされているOSが64ビットとは限りません。パッケージに互換性がないと表示された場合は、OSのバージョンとABIを確認します。署名の競合と表示された場合は、既存アプリと新しいパッケージの署名が一致していません。universal版を選ぶだけでは解決できません。

まず、サブスクリプションURLと個別ノードの共有リンクを区別します。サブスクリプションURLはグループに追加して更新し、個別ノードのリンクはクリップボードからの読み込みなど、ノード用の追加機能を使います。コピー時に先頭・末尾の空白や改行、文字の欠落がないか確認し、チャットアプリでURLが途中までしかコピーされていない可能性にも注意してください。一覧が空の場合は、サブスクリプションの更新ログを確認し、グループの絞り込みで新しいノードが隠れていないか見直します。ログイン画面やエラーページ、空の内容を返すURLは、有効なサブスクリプションとして解析できません。サーバー側の形式にクライアントが未対応の場合は、提供元に対応形式を確認してください。URLの認証情報を何度も書き換えて直そうとするのは避けましょう。

macOSでは「このMacについて」でチップ情報を確認し、Apple Siliconならarm64、Intelならx64を選びます。LinuxではCPUアーキテクチャとディストリビューションのパッケージ形式を確認してください。DebianやUbuntu系では通常deb、Fedoraなどでは通常rpmを使います。ARMデバイスでは対応するarm64パッケージが必要です。インストール後に起動できない場合は、ノードを変更する前に、システムが表示する依存関係、権限、互換性に関するメッセージを確認しましょう。アプリは開くのにコアが起動しない場合は別の問題です。ログ、ランタイムライブラリ、ファイルの実行権限を調べ、ソフトウェアのインストール問題をネットワーク障害と混同しないようにしてください。

まず、使用中のクライアントのバージョンがTUNに対応していることを確認し、そのバージョンの案内に従って仮想インターフェースの作成やルート変更に必要な権限を付与します。Windowsでは通常、管理者権限またはクライアント付属のサービス機構が必要です。macOSとLinuxの認証方法はバージョンによって異なるため、別のOSの手順をそのまま使わないでください。AndroidではシステムのVPN許可を確認し、ほかのVPNアプリが接続を使用していないか調べます。機能に必要な権限だけを付与し、セキュリティ保護を丸ごと無効にしないでください。トラブル対処の前にTUNを無効にして通常のプロキシが使えるか確認します。基本のアウトバウンド接続に失敗している場合、権限を強化してもリモート接続は直りません。

まず手動で更新が成功することを確認してから、クライアントのサブスクリプショングループ設定またはサブスクリプション設定で自動更新を探します。項目名、時間の単位、実行条件はバージョンによって異なるため、現在の画面に従ってください。提供元の更新頻度に合わせて間隔を設定し、極端に短い間隔で繰り返しリクエストしないようにしましょう。デスクトップクライアントは終了すると通常、独自の定期処理を実行しません。Androidではバックグラウンド制限により更新が遅れる場合もあります。更新にプロキシが必要な場合は、利用可能なノードを一つ残し、更新リクエストの通信経路を確認してください。自動更新は設定内容を更新する機能であり、サブスクリプションの有効期限を延長したり、停止中のサービスを復旧したりするものではありません。

通常は必要ありません。サブスクリプションはノード設定をまとめて取得・更新するためのもので、ノードの切り替えは既存の一覧から使用する設定を選ぶ操作です。切り替え後は、新しい設定がクライアントに適用されたか、再読み込みに失敗したログがないか確認してください。ブラウザーの既存の長時間接続は古い接続を使い続けることがあります。テスト時は元のページを閉じて開き直し、必要なら該当アプリを再起動してください。一覧が自動選択や負荷分散ルールで制御されている場合、画面で選んだノードが最終的な出口とは限りません。現在のモードを確認しましょう。ノードのパラメーターが変わった場合、設定が期限切れの場合、または一覧の更新が必要な場合にのみ、サブスクリプションを更新してください。

まずコアが正常に起動していることを確認してからシステムプロキシを有効にし、プロキシのアドレスとポートがクライアントのローカルインバウンドと一致しているか調べます。新しいブラウザーのページを開きながらクライアントのアクセスログを確認し、該当するリクエストが記録されていれば、その通信がコアに届いています。ログが無効の場合は適切なレベルで有効にし、テスト後に元の設定に戻してください。ブラウザー拡張機能、個別のプロキシ設定、アプリ独自の接続ポリシーがシステム設定より優先されることがあります。遅延テストに成功しても、確認できるのはテスト経路が使えることだけで、ブラウザーが接続されている証明にはなりません。外部IPアドレスも参考情報にすぎず、ダイレクト接続ルールによりリクエストごとに出口が異なる場合があります。

まず現在のクライアントにあるバックアップまたはエクスポート機能を使い、サブスクリプショングループ、使用中のノード、ルーティングモード、ローカルポート、DNS設定を記録します。エクスポートしたデータにはサブスクリプションの認証情報やノードの認証情報が含まれる場合があります。安全な場所に保管し、公開の掲示板などにアップロードしないでください。更新前に移行先バージョンのシステム要件と設定移行の案内を確認します。移行後は基本的な接続をテストしてから、カスタムルートやTUNを一つずつ戻してください。サブスクリプションのノード設定は次回更新時に上書きされる可能性があるため、カスタマイズした内容は別途保存します。別のクライアントに移行する場合は、汎用の共有リンクか、対応する設定形式で読み込む方法が安全です。

まずデバイスが通常のネットワークに接続できることを確認し、サーバーのアドレスとポート、サブスクリプションの有効状態を調べます。実際の接続テストがタイムアウトする原因には、名前解決、接続確立、TLSハンドシェイク、テスト先への到達不能などがあり、1回の結果だけでノードが恒久的に使えないとは判断できません。同じ時刻のログを確認して、ドメイン名の解決失敗、接続拒否、ハンドシェイクエラーを区別してください。同じネットワークで既知の正常な設定を使って比較し、利用が許可された別のネットワークでは元の設定を試す方法もあります。すべての設定で失敗する場合は、まずローカルネットワークとコアを確認します。特定の設定だけ失敗する場合は、その設定の通信・セキュリティパラメーターとサーバーの稼働状況を調べてください。

「接続済み」は、ローカルのVPNインターフェースやコアのプロセスが起動したことを示すだけで、リモートへのリクエストが成功したとは限りません。まずブラウザーのリクエストがアクセスログに記録されているか確認します。記録がなければ、システムプロキシ、ブラウザー設定、TUNの対象範囲を調べます。記録がある場合は、一致するアウトバウンドとエラーログを確認してください。ドメイン名でのアクセスだけ失敗し、ほかの接続が正常なら、DNS設定とシステム時刻を重点的に確認します。特定のサイトだけ失敗する場合は、該当するルーティングルールと接続先の稼働状況を調べましょう。トラブル対処ではまず簡単な設定に戻し、重複するプロキシの入口を無効にします。一度に一つだけ変更して再テストし、DNS、ルーティング、ノードを同時に変更して原因が分からなくなるのを避けてください。

まずクライアントのコアがローカルインバウンドを正常に待ち受けているか確認し、システムプロキシに設定されたホストとポートを照合してください。システムプロキシのスイッチがオンかどうかだけでは判断できません。システムプロキシを参照しないプログラムでは、アプリ内に対応するHTTPまたはSOCKSの接続先を設定するか、TUNの利用を検討します。ログにaddress already in useと表示された場合は、重複起動したクライアントを終了するか、ローカルの待ち受けポートを未使用のポートに変更し、そのポートを参照するアプリの設定も更新してください。用途を確認できないシステムプロセスは終了しないでください。プロキシ拡張機能やほかのネットワークツールが設定を繰り返し上書きしている場合は、競合する項目を無効にしてからシステムプロキシを再設定します。

サブスクリプションの更新失敗は、内容の取得または解析時に発生します。リンクの有効期限、認証状態、リクエストの通信経路、証明書エラーを確認してください。まずシステム時刻が正しいことを確認し、直接接続での更新と、利用可能なプロキシ経由での更新をそれぞれ試します。公開ログにサブスクリプションURL全体を載せないでください。コアの起動失敗はローカル設定の読み込み時に発生するため、ログにある最初の具体的なエラーを探します。たとえばJSONの構文エラー、未知のフィールド、ファイル不足、ポート競合などです。更新に失敗しても既存ノードは使い続けられる場合がありますが、コアが起動しないと、そのコアに依存する接続は確立できません。まず障害が起きた段階を特定して該当する設定を修正し、最初からすべての設定を消去するのは避けましょう。