V2Rayのよくある質問。

V2RayはProject Vのプロキシ技術エコシステムに属し、V2FlyとXrayは関連するコアの系統です。コアはプロトコル、トランスポート、ルーティング、DNSを処理します。v2rayNはデスクトップ向けGUIクライアント、v2rayNGはAndroid向けGUIクライアントで、サブスクリプションの管理やサーバーの選択、実行用設定の生成を担います。トラブル対処では、クライアントのバージョンと実際に使っているコア名を記録してください。画面に項目が表示されていても、現在のコアがその設定項目に対応しているとは限りません。設定例を使う際は対象のコアを確認し、ファイル名がどちらもconfig.jsonだからと安易に流用しないでください。

クライアントはローカルでの設定と接続を行うもので、インストールしただけでは接続先サーバーは追加されません。利用権のあるサブスクリプションURL、ノード共有リンク、または必要な設定情報を用意し、対応する方法でインポートしてください。サブスクリプションURLは通常、複数の設定を取得するためのものです。一方、ノードリンクは個別の設定を表すため、インポート先を取り違えないようにしましょう。サブスクリプショングループがあるのに一覧が空の場合は、更新結果とフィルター条件を確認してください。何度も再インストールする必要はありません。画面を共有する際は、URL内のトークン、サーバーの認証情報、個人用メモを隠してください。

システムプロキシはローカルのプロキシアドレスをOSに設定し、その設定に従うアプリに適用されます。独自のネットワーク設定を持つアプリや、直接接続するプログラムには適用されない場合があります。TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。適用範囲が広い一方、権限やルーティング、DNSの設定がより重要です。初めて使う場合は、まずシステムプロキシでノードの動作を確認し、その後TUNを検討しましょう。TUNを有効にしても、すべての通信がプロキシ経由になるわけではなく、最終的な接続先はクライアントの分割ルールに左右されます。対処中は、通信を取り込むツールを複数同時に動かさないでください。

プロトコル名だけで選ぶのではなく、サーバー側で実際に提供されているプロトコルと設定に合わせてください。VMess、VLESS、Trojan、Shadowsocksでは認証項目やセキュリティ設定が異なり、トランスポート層、TLS、SNIなども接続先と一致させる必要があります。手動でプロトコルを変更するより、共有リンクを設定ごとインポートするほうが確実です。サブスクリプション内の設定で接続できている場合、別のプロトコルを試すために種類だけを変え、古い設定を残すのは避けてください。未対応の項目に関するエラーが出たら、まずクライアントとコアの互換性を確認しましょう。プロトコル名だけで速度、遅延、接続の安定性が決まるわけではありません。

まず、URLの保存、サブスクリプションの取得、内容の解析のどの段階で失敗したかを切り分けます。URLをコピーする際は、全体が正しくコピーされているか、空白や改行、全角の句読点が混ざっていないかを確認し、管理画面のURLと取り違えていないかも確認してください。URLを保存できてもノードが追加されない場合は、更新ログを確認しましょう。ログイン画面やエラーページが返された場合、または形式に対応していない場合は、解析に失敗することがあります。サブスクリプションURL全体を公開の掲示板に投稿したり、見知らぬ変換サイトに入力したりしないでください。配布元を確認して元のURLをコピーし直し、単一ノードのインポート欄ではなく、サブスクリプショングループから更新してください。

2015年以降の一般的なAndroidスマートフォンでは、まずarm64版を検討できます。ただし、最終的にはOSが対応するABIを確認してください。プロセッサーが64ビット対応でも、OS上で該当アプリを実行できるとは限りません。universal版は複数のアーキテクチャに対応しているため、種類を確認できない場合に試せますが、ファイルサイズは大きくなる傾向があります。インストールできない場合は、まずOSのバージョン、空き容量、インストール権限を確認し、その後パッケージのアーキテクチャを調べてください。同名アプリがインストール済みの場合は、署名の不一致やダウングレード制限にも注意が必要です。アンインストールすると設定が消える場合があるため、必要なデータは先にクライアントのエクスポート機能で保存してください。

まずTUNを停止し、ログにある権限、仮想インターフェース、ルート作成に関する最初のエラーを確認してください。Windowsでは通常、管理者権限またはクライアントが対応するサービスモードが必要です。ほかのデスクトップOSではクライアントの案内に従って必要な権限を許可してください。Windows向けの手順をそのまま適用しないようにしましょう。ほかのVPNやTUNツールが通信経路を使用していないことを確認してから、利用中のクライアントの説明に従って再度有効にしてください。ファイアウォールやセキュリティ機能を無効にすることを、通常の解決策にしないでください。システムプロキシは動作するのにTUNだけ失敗する場合は、ノードを何度も変更するのではなく、権限、インターフェース、ルーティングを優先して確認しましょう。

ほかの解説にあるポートをそのまま使わず、クライアントに現在表示されているローカルの待ち受け設定を確認してください。アプリがSOCKS5を要求する場合は、実際に設定されているSOCKSまたは互換性のある混合待ち受けポートを指定します。HTTPプロキシが必要な場合は、HTTPに対応した待ち受けポートを入力してください。同じ端末内で使う場合、アドレスには通常127.0.0.1を指定します。10808はよくある例であり、すべてのバージョンで固定されているわけではありません。LAN内のほかの端末から接続する場合は、待ち受けアドレス、アクセス認証、ファイアウォールルールを別途検討してください。ローカル専用の設定を、そのまま外部ネットワークに公開しないでください。

TCP遅延テストで確認できるのは、通常、接続先ポートに接続できることまでです。認証、TLS、プロキシの出口、DNSが正常かどうかは確認できません。実接続テストは実際のリクエストに近いものの、その時点でテスト先に到達できるかを示すにとどまります。選択中のノードとテスト対象のノードが同じことを確認し、システムプロキシまたはTUNが動作しているかを調べて、Webサイトへのアクセス時に新しいログが記録されるか確認してください。テスト先の1つに接続できなくても、ノードが必ず使えないとは限りません。遅延値が表示されても、すべてのWebサイトにアクセスできる証明にはなりません。ブラウザーでのアクセス結果と実際の出口の変化を合わせて判断してください。

ルールモードはドメイン名やIPなどの条件に応じて通信の出口を選ぶため、用途に合わせた日常的な振り分けに適しています。グローバルプロキシは通常、既定の出口をプロキシに変更するため、振り分けルールがアクセスに影響しているか一時的に確認する際に役立ちます。直接接続モードでは、通常、通信が接続先へ直接送られます。モードの名称や適用範囲はクライアントによって異なるため、具体的なルーティングルールも確認してください。特定のWebサイトを調べる場合は、比較のため一時的にグローバルプロキシへ切り替え、確認後に元の設定へ戻しましょう。グローバルプロキシにしても、すべてのアプリの通信が取り込まれるわけではありません。どの通信をクライアントに渡すかはシステムプロキシまたはTUNが決め、取り込まれた通信の行き先はルーティングモードが決めます。

サブスクリプションを更新すると、通常はサーバーから取得した内容に基づいてノードが再構成または統合されます。具体的な動作はクライアントのバージョンとグループ設定によって異なります。提供元が名称、アドレス、ノード識別子を変更すると、以前の並び順やメモ、選択中のノードがそのまま維持されない場合があります。更新前に使用中の設定を記録し、更新後に選択中のノードを確認して実接続テストを行ってください。長期保存が必要な手動設定は専用のグループに置き、自動更新されるサブスクリプションと混在させないようにしましょう。一覧の先頭にあるノードが前回使ったサーバーだと決めつけないでください。

まずプロキシを有効にする前のアクセス状況を記録します。対象ノードを有効にしたら、ブラウザーでテストページにアクセスして出口IPを比較し、該当するリクエストがログに記録されているか確認してください。出口の結果はIPv4、IPv6、通信の振り分け方針に左右されるため、一度の確認だけですべてのアプリの動作は判断できません。AndroidではVPNの許可とアプリごとの振り分け範囲も確認し、テスト対象のアプリが除外されていないか確かめてください。終了前にシステムプロキシまたはTUNをオフにし、通常のネットワークに戻ったことを確認してからプログラムを終了します。異常終了によってシステムプロキシの設定が残った場合は、システムのネットワーク設定から元の値に戻せます。ネットワーク全体をすぐにリセットする必要はありません。

インポート失敗はURLや内容を認識できない場合に起こり、更新失敗は既存のグループがサーバーから内容を取得する際に起こることが多いです。まずログを読み、ドメイン名の名前解決失敗、接続タイムアウト、証明書エラー、HTTPステータスコードを切り分けてから、サブスクリプションの期限切れやリセットがないか確認してください。端末の時刻が正しいことを確認し、実際のネットワーク状況に応じて直接更新するか、利用可能なプロキシ経由で更新します。プロキシが使えないのに、それを使ってサブスクリプションを取得しようとすると、自力で復旧できない状態になりかねません。現在使えるノードを残し、先にすべての設定を削除しないでください。サーバー側の制限を招くおそれがあるため、短時間に何度もリクエストを送るのも避けましょう。

まず通信を取り込むモードをオフにし、端末の基本的なネットワーク接続と一般的なドメイン名の名前解決が正常か確認します。次にシステム時刻を確認し、ネットワークへの接続にWebログインが必要か調べてください。その後、サブスクリプションが有効か確認し、同じノードでポートテストと実接続テストをそれぞれ行って、接続拒否、ハンドシェイク失敗、認証エラーがないかログを確認します。特定のネットワーク環境ですべてタイムアウトする場合に限り、利用権のある別のネットワークで比較してください。一部のノードだけ失敗する場合は、該当するサーバーの状態と設定を優先して確認します。DNS、トランスポート、ルーティングを一度に変更すると、元に戻しても原因を特定しにくくなります。

「接続済み」は、ローカルのコアやAndroidのVPNサービスが起動したことを示すだけの場合があり、サーバー側での認証や通信転送が成功したとは限りません。まずコアのエラーを確認し、実接続テストでサーバーまでの経路を調べてください。経路が使える場合は、対象ドメインの名前解決に失敗していないか、リクエストが実際にどの出口へ送られたかを確認します。グローバルプロキシに一時的に切り替えてアクセスが回復した場合は、通常、振り分けルールとその順序を見直します。ログに名前解決のタイムアウトが記録されている場合は、DNSサーバーへの到達経路とDNSルーティングを確認してください。WebサイトのIPアドレスへ直接アクセスする方法に頼り続けないでください。HTTPS証明書やサイトの仮想ホストもドメイン名に依存します。

まず、システムプロキシの接続先が現在のクライアントの待ち受けアドレスとポートになっていることを確認し、クライアントのコアが動作中か調べてください。ブラウザー拡張機能、アプリ独自のプロキシ設定、プロキシの除外リスト、既存の接続によって結果が変わることがあります。設定を変更した後、対象アプリを再起動してテストしてみましょう。ログにそのアプリの新しいリクエストがない場合、システムプロキシに従っていない可能性があります。アプリ内で対応するHTTPまたはSOCKS5プロキシを設定するか、TUNの利用を検討してください。ログにリクエストがあるのにアクセスできない場合は、適用されたルールとサーバー側のエラーを確認します。クライアントに届いた後の問題を、システムプロキシが効いていないと誤認しないようにしましょう。