V2Rayのよくある質問とトラブルシューティング

V2Rayコアはプロトコル処理、ルーティング判断、接続の転送を担当し、GUIクライアントはサブスクリプション管理、パラメーター入力、システムプロキシの切り替え、ログ確認を担当します。v2rayNはデスクトップ向けGUIクライアントで、v2rayNGとv2flyNGはAndroid向けです。通常はGUIクライアントだけをインストールすればよく、各クライアントの配布形態に必要なコアが含まれます。コアと操作画面を別々に設定する必要はありません。

Windows、macOS、Linuxのデスクトップ環境では、サブスクリプション、ルーティング、システムプロキシ、TUNなどを一通り設定できるv2rayNがおすすめです。Androidでは通常、Xrayコアを使用するv2rayNGを選びます。サブスクリプションのパラメーターがv2flyコアに適している場合や、コアごとの互換性を確認したい場合はv2flyNGを使用できます。同じ端末で2つのクライアントのVPNまたはシステムプロキシを同時に有効にしないでください。

サブスクリプションURLでは、サーバーが複数のノードをまとめて提供します。クライアントが更新すると、ノードの追加・削除やパラメーターの変更も同期されます。個別ノード設定に含まれるのは一度読み込んだ接続情報だけで、その後サーバー側の変更は自動反映されません。長期利用では、サブスクリプションを専用グループに保存し、適切な自動更新間隔を設定すると便利です。一時的に設定を試す場合は、既存のサブスクリプショングループを上書きしないよう、ノードを個別に読み込んでください。

システムプロキシモードはOSのプロキシ設定を変更し、ブラウザーやシステムプロキシに従うアプリがクライアント経由で接続します。ただし、一部のゲーム、コマンドラインツール、独自にネットワークを管理するアプリは設定を読み取らない場合があります。TUNモードは仮想ネットワークインターフェースを使って、より低い層で通信を引き受けるため対象範囲が広い一方、追加の権限が必要です。まずはシステムプロキシで設定を確認し、対象にできないアプリがある場合にTUNを有効にしてください。

2015年以降に発売された一般的なAndroidスマートフォンやタブレットは、通常64ビットARMプロセッサーを搭載しています。まずはファイルサイズが小さいことの多いarm64版を選ぶとよいでしょう。プロセッサーのアーキテクチャが不明な場合、端末が古い場合、またはarm64のインストール時に互換性エラーが出る場合は、universal版を試してください。主な機能は同じで、違いは対応するプロセッサーアーキテクチャの範囲です。両方を同時にインストールする必要はありません。

Androidクライアントのインストールパッケージを見る

まず、コピーした内容が完全なサブスクリプションURLであり、余分なスペース、改行、チャットアプリが付けた句読点などがないことを確認します。v2rayNでは、サブスクリプショングループの設定からURLを追加して保存し、その後にサブスクリプションを更新します。v2rayNGでは、サブスクリプショングループの画面から追加して更新できます。形式エラーが表示される場合は、提供元にURLが有効か、クライアントが対応する形式の内容を返しているか確認してください。

サブスクリプションの読み込み手順を見る

まずブラウザーでサブスクリプションURLに正常にアクセスできるか確認し、次にURLの有効期限が切れていないか、再生成されていないかを確認します。その後、クライアントの更新ログを確認し、ドメイン名の解決失敗、接続タイムアウト、返却内容のエラーを切り分けます。URLへのアクセスにプロキシが必要な場合は、利用可能なノードに接続してから、プロキシ経由で更新する設定を有効にしてください。それでも失敗する場合は、一時グループを作成してテストし、古いキャッシュやグループ設定の影響を避けます。

デスクトップOSで仮想ネットワークインターフェースを作成するには、通常管理者権限が必要です。まずクライアントを完全に終了し、OSの管理者として起動する方法で再起動してから、TUNをもう一度有効にします。Androidでは初回有効化時にVPN接続の許可が表示されるため、確認して許可してください。端末上で別のVPNアプリが動作している場合は、先に切断します。通常、同時にシステムのVPNインターフェースを使用できるアプリは1つだけです。

初めてノードを確認するときは、ルーティングルールによる影響を減らすため、短時間だけグローバルモードを使えます。接続を確認できたら、普段はルールモードに切り替え、ドメイン、IP、ルールセットに応じて直結とプロキシを振り分けます。直結モードでは通常のリクエストをプロキシの出力先へ送らず、一時的にプロキシを停止したり、ローカルネットワークを切り分けたりする際に使います。モードを切り替えたらテストページに再アクセスし、クライアントの接続表示だけで判断しないでください。

遅延テストで分かるのは、テスト時点におけるクライアントからノードへの応答状況だけです。実際のダウンロード速度を示すものではなく、すべてのプロトコルハンドシェイクの成功を単独で証明するものでもありません。実際の接続テスト、Webページへのアクセス、実行ログを合わせて判断してください。遅延が低いのにWebページを開けない場合は、転送パラメーター、TLSドメイン、ユーザー情報、ルーティング設定が一致していない可能性があります。1台のノードを繰り返し測るより、複数のノードを続けてテストしたほうが問題の範囲を判断しやすくなります。

通常は数時間に1回から1日1回程度に設定し、サブスクリプション提供元がノードを変更する頻度に合わせます。間隔が短すぎると同じリクエストを繰り返し、ネットワークが不安定なときに失敗記録が頻繁に表示されることもあります。更新後に現在のノードが削除されていた場合は、利用可能なノードを選び直す必要があります。重要な接続の前には手動で一度更新し、現在のグループ、アクティブなノード、ルーティングモードが意図せず変わっていないか確認してください。

ルーティング設定でLANアドレスを直結にすると、ルーターの管理画面、プリンター、LANストレージがプロキシへ送られるのを防げます。一般的なプライベートアドレス範囲やローカルドメインも、優先的に直結へ設定してください。カスタムルールを追加するときは、範囲が具体的なルールを汎用ルールより前に置き、対応する出力先を明確に選びます。変更後はローカル機器、通常のWebサイト、プロキシが必要な宛先をそれぞれテストし、早い段階で適用されたルールに誤って振り分けられていないか確認してください。

ルーティング設定リファレンスを見る

まず同じサブスクリプション内の別のノードへ切り替えます。すべてのノードでタイムアウトする場合は、ローカルネットワーク、システム時刻、DNS、サブスクリプションの更新状況を優先して確認します。1つのノードだけがタイムアウトするなら、そのノードのアドレス、ポート、サービス状態が変わった可能性が高いでしょう。プロトコル、転送方式、TLS、REALITYのパラメーターがすべて揃っているかも確認してください。ログのconnection timeoutは、規定時間内に接続を確立できなかったことを示します。ドメイン名の解決、TCP接続、プロトコルハンドシェイクのどの段階でタイムアウトしたかをさらに切り分けます。

接続済みという表示は、クライアントのプロセスとローカルプロキシの入口が動作していることを示すだけで、接続先ノードが利用可能とは限りません。まずシステムプロキシまたはTUNが実際に有効になっているか確認し、ブラウザーで複数のサイトへアクセスして、別のノードでも再テストします。次に、ルーティングモードが誤って直結になっていないか、DNSリクエストが失敗していないか、ローカルポートを別のプログラムが使用していないか確認してください。プロキシを無効にしてもアクセスできない場合は、クライアントのパラメーターを変更し続けるのではなく、まず基本的なネットワーク接続を復旧します。

まずブラウザーが独自のプロキシ設定や拡張機能のルールを使っていないか確認します。これらの設定がシステムプロキシを上書きしている可能性があります。ブラウザーを完全に終了して再起動すると、新しいプロセスがシステム設定を読み直します。コマンドラインターミナルや一部の開発ツールは、通常システムプロキシに自動追従しません。各ツールのドキュメントに従って、HTTP、HTTPS、SOCKSプロキシの環境を設定してください。クライアントのローカル待受ポートも確認し、HTTPポートをSOCKSポートに誤って入力しないよう注意します。

rejectedは、処理のいずれかの段階で接続が拒否されたことを示し、ルーティングによる遮断、宛先への到達不能、プロトコル条件の不一致などで発生します。timeoutは、名前解決、接続、ハンドシェイクが制限時間内に完了しなかったことを示します。invalid userは通常、ユーザー識別子または認証情報がサーバー側と一致していないことを意味します。確認時はまずエラーの発生時刻と対象を記録し、ローカルのインバウンド、ルーティングルール、リモートのアウトバウンドの順に調べてください。一度に複数のパラメーターを変更しないことが重要です。