v2rayNのよくある質問

Windows、macOS、Linuxのデスクトップ環境ではv2rayN、Androidでは通常、Xrayコアを使用するv2rayNGを選びます。既存の設定がV2Flyの動作に明確に依存している場合は、v2flyNGも選択肢になります。クライアントは画面表示やサブスクリプション管理、プロキシの切り替えを担いますが、利用できるプロトコルは搭載コアとそのバージョンにも左右されます。選ぶ前に、プラットフォーム、CPUアーキテクチャ、サーバー側の要件を確認しましょう。アプリ名だけで互換性を判断しないでください。いずれのクライアントも利用可能なサーバー設定が必要で、インストールしただけでは接続できません。

VMessとVLESSはプロキシプロトコル、REALITYはセキュリティ層に関わる技術です。3つを同じ種類の設定として、そのまま置き換えることはできません。接続には通信方式、ポート、セキュリティ関連のパラメーターも関わるため、サーバー側の設定と一致させる必要があります。たとえばVLESSでREALITYを使う場合は、公開鍵、serverName、shortIdなどの項目を正しく入力し、flowもサーバー側の指定に合わせます。インポート後に未対応の項目が表示された場合は、プロトコルを安易にVMessへ変更せず、クライアントとコアの対応状況を確認してください。

サブスクリプションURLは、クライアントが設定一覧を取得するためのアドレスで、更新時に内容を再取得します。共有リンクは通常、サーバー1台分の設定を表し、vmess://、vless://、trojan://、ss://などの形式があります。JSON設定には、inbound、outbound、ルーティング、DNSなど、コアの設定一式を含められます。通常のサブスクリプションとして読み込めるとは限りません。内容に応じて、サブスクリプショングループへの追加、クリップボードからのインポート、カスタム設定の読み込みを使い分けてください。サブスクリプションURLに認証情報が含まれる場合があります。スクリーンショットを共有したり相談したりする際は、URL全体と関連パラメーターを必ず隠してください。

システムプロキシは、プロキシのアドレスをOSの設定に登録します。主にその設定を参照するアプリが対象で、独自に直接接続するアプリや個別にプロキシを設定したアプリには適用されないことがあります。TUNモードは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。権限やDNS、ネットワークの経路設定も関係します。すべての通信が必ずプロキシ経由になるわけではなく、最終的な経路はルールに左右されます。初めて設定する場合は、まずシステムプロキシでサーバーに接続できることを確認し、必要に応じてTUNを有効にしましょう。複数の設定を同時に変更すると、問題の切り分けが難しくなります。

2015年以降に発売された主流のスマートフォンでは、arm64パッケージが候補になります。ただし、最終的には端末のOSが対応するABIを確認してください。CPUが64ビットに対応していても、OSが該当アプリに対応しているとは限りません。universalパッケージは複数のアーキテクチャ向けのファイルを含むため、アーキテクチャを確認できない場合に便利ですが、ファイルサイズは大きくなりがちです。インストール時に端末との互換性エラーが出たら、OSのバージョンとアーキテクチャを確認して、適合するパッケージを選びましょう。署名の競合は、アーキテクチャを何度も変更しても解決しません。上書きインストールの前に設定を保存し、アンインストールによるサブスクリプションやカスタムルールの消失を防いでください。

まず、コピーしたものがサブスクリプションURL全体であることを確認します。管理ページのURLや説明文、単一の共有リンクではありません。前後の空白や改行も取り除いてください。URLをサブスクリプショングループに追加した後、サブスクリプションの更新も実行します。一覧が空の場合は、ログでリクエスト結果と解析エラーを確認しましょう。ログインページが返る場合は、URLや認証に問題がある可能性があります。形式を認識できない場合は、提供元が指定するクライアントの種類を確認してください。トラブルの相談時にサブスクリプションURL全体を公開せず、エラーの種類、応答ステータス、機密情報を隠した内容の特徴だけを共有しましょう。

現在のサーバーが選択され、コアが動作していることを確認します。次にOSのプロキシ設定を開き、アドレスとポートがクライアントの実際の待ち受け先を指しているか確認してください。例として示されたポート番号が常に使われるとは限りません。更新やカスタム設定によって待ち受けポートが変わる場合があります。続いて、ブラウザーがシステムプロキシを使う設定になっているか、プロキシ拡張機能が設定を上書きしていないか確認しましょう。独自のネットワーク設定があるアプリでは、プロキシを個別に指定する必要があります。他のプロキシツールを終了してから、同じ接続先で再テストしてください。一部のサイトだけ直接接続する場合は、ルーティングルールでdirectに振り分けられていないか確認します。

デスクトップOSで仮想インターフェースを作成したりルートを変更したりするには、通常、管理者権限が必要です。クライアントの現在のバージョンに表示される手順に従って権限を付与し、関連サービスや仮想インターフェースが正常に作成されているか確認してください。Androidでは、システムのVPN許可ダイアログで承認します。同じ通信を制御する別のツールを同時に有効にしないでください。許可後も失敗する場合は、ログで失敗した手順を確認し、セキュリティソフトによるブロックや残存インターフェースの有無を調べます。対処のためにシステム保護を長期間無効にするのは避けてください。TUNを停止したら、通常のネットワーク接続が復旧したことを確認してから、次の切り分けに進みます。

Tcpingで確認できるのは、主に接続先のアドレスとポートにTCP接続できるかどうかです。プロキシプロトコルのハンドシェイクや認証、接続先サイトへのアクセスまでを完全に検証するものではありません。実接続の遅延テストでは、プロキシ経由で指定のテスト先にアクセスするため、実際の利用経路に近い結果が得られます。ただし、テスト先やDNS、テスト時のネットワーク状態にも左右されます。ポートに接続できても実接続に失敗する場合は、プロトコルのパラメーターとログを確認してください。1回のテスト結果だけでサーバーを選ばず、接続先を固定して繰り返し確認しましょう。そのうえでブラウザーからアクセスし、実際に使うアプリがプロキシ経由になっているか確認します。

普段は用途に応じて、中国本土への通信を除外するなどのルーティング方式を選べます。どのルールが適用されるかは、ルールの内容と順序によって異なります。特定の接続先で問題が起きた場合は、その通信を一時的にプロキシ経由にするか、クライアントのグローバルプロキシ用ルートに切り替えて比較します。その際、サーバーとテスト先は変えないでください。切り替え後に接続できる場合は、ルールの優先順位、ルールデータ、ドメイン名の解決方法を重点的に確認します。システムプロキシの切り替えは、アプリからクライアントへリクエストを送る方法を決めるものであり、コアのグローバルルーティングとは別です。テスト後は必要なルーティング設定に戻してください。

サブスクリプションを更新すると、そのグループ内にサブスクリプションから生成されたサーバー項目が上書きされることがあります。自動更新される項目に、長期的に使う変更を直接保存するのは避けましょう。設定を変更する場合は、クライアントで可能なら手動管理の別グループに複製し、比較用に元のサブスクリプションを残します。更新前にサブスクリプショングループ、ルーティングルール、必要なカスタム設定をバックアップしてください。バックアップファイルも安全に保管しましょう。更新後に接続中のサーバーが使えなくなった場合は、現在選択されているサーバーと所属グループを確認します。同じ名前でも、以前と同じアドレスやパラメーターとは限りません。

まずコアが正常に動作していることを確認し、対象アプリの通信経路が、システムプロキシ、手動プロキシ、TUNのどれなのかを特定します。同じアプリから、プロキシ経由になるはずの接続先へアクセスしながら、クライアントの接続履歴やアクセスログでinboundとoutboundの記録を確認してください。ページが開けるだけでは、プロキシ経由だとは限りません。接続先へ直接アクセスできる場合や、directルールが適用される場合もあります。テスト中はログレベルを一時的に上げ、終了後は通常の設定に戻しましょう。ログを共有する前に、サーバーアドレスやサブスクリプションのパラメーター、個人の活動に結び付く可能性のある情報を隠してください。

まず、端末の通常のネットワーク接続が使えることと、サーバーのアドレスやポートに不足がないことを確認します。次に、ドメイン名の解決失敗、TCP接続のタイムアウト、プロトコルのハンドシェイク失敗を切り分けます。名前解決に失敗する場合はDNS、接続がタイムアウトする場合はサーバー側の待ち受け状態や通信経路、ハンドシェイクに失敗する場合はプロトコルやセキュリティ層、認証項目を確認してください。端末の時刻が大きくずれていると、認証や証明書の検証に影響することもあります。サーバーを1つに固定して比較し、変更は一度に1項目だけにします。同じ設定が別のネットワークでは使える場合、クライアントを何度も再インストールするより、まずローカルのネットワーク環境を比較しましょう。

クライアントが起動し、ローカルで待ち受けを開始できたとしても、それは通信を取り込む入口が動作しているだけです。リモートへのリクエストがすべて成功したことを示すものではありません。まず実接続テストとアクセスログを確認し、リクエストがクライアントに届いているか調べます。記録がない場合は、アプリのプロキシ設定を確認してください。記録はあるのにoutboundが失敗する場合は、サーバーとプロトコルのパラメーターを確認します。ログにドメイン名の解決エラーが多い場合は、DNSとそのルーティングを調べ、まだ確立していないプロキシに名前解決を依存させないようにします。一部の接続先だけで失敗する場合は、適用されたルールと接続先の到達性を比較しましょう。証明書検証を無効にするのは、一般的な解決策ではありません。

まず、エラーがリクエストのタイムアウト、認証拒否、内容の解析失敗のどれにあたるか確認します。認証拒否の場合は、サブスクリプションの有効期限やURLが変更されていないかを確認してください。解析に失敗する場合は、返された内容がWebページに変わっていないか、または非対応の形式ではないかを調べます。クライアントが直接接続とプロキシ経由の両方で更新できる場合は、利用可能な接続がある状態で比較します。すでに使えないサーバーに更新リクエストを依存させないようにしましょう。システム時刻、DNS、ローカルのセキュリティソフトの記録も確認してください。古い項目がまだ使える場合は残しておき、比較用の設定を失わないよう、すべてのグループをすぐに削除しないでください。

ポートの競合は通常、別のプロセスや重複して起動したコアが、同じアドレスで待ち受けていることを示します。クライアントの重複起動を終了し、OS上でポートを使用しているプロセスを確認してください。そのプロセスを停止するか、設定でローカルの待ち受けポートを変更します。アプリに手動でプロキシを設定している場合は、そちらのポートも合わせて変更してください。異常終了後にインターネットへ接続できない場合は、まずシステムプロキシが停止済みのローカル待ち受け先を指していないか確認し、次にTUNインターフェースとルートが復旧しているか調べます。クライアントは通常の停止・終了手順を使ってください。復旧しない場合はエラー記録を保存し、OSのネットワーク設定を項目ごとに確認します。