V2Rayのよくある質問

Windows、macOS、Linuxのデスクトップではv2rayNを使い、OSとCPUアーキテクチャに合ったものをインストールします。Androidでは通常、Xrayコアを使用するv2rayNGを選びます。既存の設定がV2Flyの動作に明確に依存している場合は、v2flyNGも検討してください。GUIクライアントはサブスクリプションの追加、サーバーの選択、設定の管理を行い、実際の接続とルーティングはコアが担います。クライアント名が似ていても、機能が完全に同じとは限りません。特にプロトコル、安全レイヤー、トランスポート方式を確認しましょう。移行前に元の設定を保存し、まず動作確認済みの設定を1つ試してから、ほかのグループを追加してください。

クライアントをインストールしても、設定や接続に使うツールが用意されるだけで、接続可能なサーバーが自動的に作られるわけではありません。自分で管理する、または使用許可を得たサブスクリプションURLや共有リンク、あるいはサーバーの接続情報一式を用意してください。サブスクリプションURLからは複数の設定を取得でき、共有リンクは通常1つの設定に対応します。どのインポート方法でも相互に使えるとは限らないため、提供元の説明を確認してから、サブスクリプショングループへの追加かクリップボードからのインポートを選びましょう。サブスクリプションURLにはアクセス情報が含まれる場合があります。パスワードと同様に扱い、公開コメントやスクリーンショット、オンライン変換サイトに掲載しないでください。当サイトはクライアントの使い方を解説しており、サブスクリプションは配布していません。

VMess、VLESS、Trojan、Shadowsocksはプロキシプロトコルです。REALITYはセキュリティレイヤーの方式で、別のプロキシプロトコルとして置き換えられるものではありません。接続にはトランスポート方式、セキュリティレイヤー、サーバーアドレス、認証情報も関わるため、サーバー側の設定と一つずつ一致させる必要があります。たとえば、サブスクリプション内のVLESS設定にREALITYのパラメーターが含まれる場合があります。インポート後も公開鍵やサーバー名などの指定を維持してください。プロトコルのプルダウンだけを変更しても、接続が復旧するとは限りません。まずサーバー側の設定とクライアントの対応状況を確認し、必要な機能を比較して選びましょう。名称だけから速度を判断しないでください。

2015年以降の一般的なAndroidスマートフォンではarm64を選べることが多いものの、最終的にはOSが対応するアプリのアーキテクチャを確認してください。CPUの仕様だけでは判断できません。ハードウェアは64ビットに対応していても、OSが32ビットのアプリ環境しか提供しない端末では、arm64版をインストールできない場合があります。アーキテクチャが分からない場合はuniversalを選ぶ方法があります。複数のアーキテクチャ向けコンポーネントを含むためファイルサイズは大きくなりますが、最低OSバージョンの制限はあります。解析エラーやインストール失敗が発生したら、OSのバージョン、空き容量、インストール済みアプリとの署名の競合を確認してください。同じ非対応パッケージを何度もダウンロードするのは避けましょう。

まず、クリップボードの内容が共有リンク、サブスクリプションURL、ウェブページの本文のどれかを確認します。共有リンクは説明文が混ざったり、改行で途切れたり、チャットアプリが句読点を付けたりしないよう、全体を正しくコピーしてください。サブスクリプションURLは個別サーバーとしてではなく、サブスクリプショングループに追加して更新します。インポート後も一覧が空なら、クライアントのログに非対応形式、必須項目の不足、解析失敗などが記録されていないか確認しましょう。調査のためでもURL全体を他人に送らず、プロトコルの種類とエラーの概要だけを伝えてください。クライアントがプロトコルとセキュリティレイヤーに対応していることを確認し、必要に応じて提供元に対応形式を問い合わせます。

サブスクリプショングループを開き、末尾のパラメーターが欠けていないかなど、URL全体を確認します。そのうえでグループを更新し、ログを確認してください。認証失敗やアクセス拒否の場合は、サブスクリプションの利用権限、有効期限、提供元のアクセス要件を確認します。接続タイムアウトなら、現在のネットワークと更新リクエストのプロキシ経路を確認しましょう。解析に失敗する場合は、ログインページや非対応の内容が返されている可能性があります。プロキシ経由で更新する設定があっても、現在のプロキシが動作している場合に限って使ってください。使えない設定に依存して新しい設定を取得しようとしないようにしましょう。先に既存のグループを削除するのは避けてください。設定を残しておけば、更新前後の変化を比較できます。

TUNは仮想ネットワークインターフェースを使って通信を取り込むため、通常のシステムプロキシとは必要な権限が異なります。まずTUNを無効にし、同じサーバーが通常のプロキシ方式で接続できることを確認します。その後、使用中のv2rayNのバージョンとOSの案内に従い、管理者権限の許可、サービス、仮想インターフェースのコンポーネントを設定してください。Windowsでは、管理者として実行すると権限エラーが解消するか確認します。macOSとLinuxでは、それぞれのOSの権限設定に従い、ほかのOS向けの手順をそのまま適用しないでください。仮想インターフェースを使用中のツールや、ルートを変更するほかのツールも終了します。起動直後にネットワークが切れた場合は、TUNを無効にして接続を復旧し、インターフェース、ルート、権限に関するログを記録してください。

まずクライアントのバックアップまたはエクスポート機能を使い、サブスクリプショングループ、手動で追加したサーバー、ルーティングルール、カスタムDNS設定を保存します。ローカルの待ち受けポートとシステムプロキシのモードも記録しておきましょう。バックアップにはサブスクリプションの認証情報が含まれる場合があるため、安全に管理できる場所に保管してください。デスクトップ版と従来のWPF版の切り替え、OSをまたぐ移行、大幅なバージョンアップでは、用途が分からない設定フォルダーを直接上書きしないでください。ポートの競合を避けるため、旧クライアントを終了してから新しいバージョンを起動します。まず新バージョンで個別の設定とサブスクリプションの更新を検証し、ルールの動作に問題がないことを確認してから、旧環境を整理するか判断してください。

システムプロキシが適用されるのは、その設定を参照するアプリだけです。端末上のすべての通信がクライアントを経由するわけではありません。クライアントが起動しており、コアが正常に動作していることを確認し、システムプロキシのアドレスとポートが現在の待ち受けポートと一致するか確認してください。ブラウザー拡張機能、アプリ独自のプロキシ設定、企業のポリシーによって、システム設定が上書きされる場合があります。個別のプロキシ設定がないブラウザーで動作を比較してみましょう。プロキシを手動入力する場合は、HTTPかSOCKSかも合わせて指定します。ポート番号だけをコピーしないでください。対象アプリがシステムプロキシに対応していない場合はTUNを検討します。通常のプロキシを確認する前に、複数の通信取り込み方式を同時に有効にしないでください。

システムプロキシモードは、アプリがリクエストをクライアントに渡すかどうかを決めます。ルーティングモードは、コアに届いたリクエストをプロキシ経由、直接接続、またはブロックのどれにするかを決めます。そのため、プロキシ経由のルートを選んでも、システムプロキシを無視するアプリが自動的にクライアントを経由するわけではありません。システムプロキシを解除しても、TUNやアプリに手動設定した通信が止まるとは限りません。トラブル対処では、まず通信の入口を固定し、その後ルーティングルールを変更して、同じ接続先で結果を比較します。「中国本土を除外」などのプリセットは、具体的なルールとドメインの名前解決結果に依存します。カスタムルールが優先して適用される場合もあります。変更前のモードを記録し、入口、ルート、DNSを同時に変更してどの設定が効いたのか分からなくならないようにしましょう。

v2rayNGのアプリごとのプロキシ設定では、選択したアプリだけをプロキシ経由にするのか、選択したアプリを除外するのかを最初に確認してから、対象のアプリを選びます。この2つはリストの意味が逆なので、チェックの有無だけでは判断しにくい場合があります。保存後、画面の案内に従って接続し直し、対象アプリから実際に通信して確認してください。アプリが既存の接続を維持している場合は、終了して再起動する必要があります。システムコンポーネントや共有サービス、アプリが呼び出す外部プログラムも動作に影響することがあります。ほかのアプリが意図せず直接接続する場合は、サーバーをすぐに変更したり設定をすべて消去したりせず、まずリストのモードと選択範囲を確認し、その後ルーティングを調べてください。

まず、切断が画面ロック中、バックグラウンドでの待機中、またはネットワーク切り替え後にのみ発生するかを確認します。システムがv2rayNGのバックグラウンド動作、バッテリー使用、モバイルデータ通信を制限していないか調べ、端末の設定で必要なバックグラウンド動作を許可してください。端末によっては、自動起動やバックグラウンドでの固定といった設定もあります。変更後はしばらく画面をロックして動作を確認し、省電力設定を一度にすべて変更するのは避けましょう。接続を維持すると一定のバッテリーを消費します。アプリごとのプロキシ設定で対象を絞れますが、どのような状況でも消費を抑えられるとは限りません。前面で使用中にも頻繁に切断される場合は、バックグラウンド権限をさらに広げるのではなく、回線、サーバー、ログを確認してください。

1回のタイムアウトだけでは、サーバーが使えないとは判断できません。まずTCP接続テストと実接続テストを区別してください。前者は主に接続先ポートへの接続を確認し、後者はプロキシのハンドシェイク、テスト先、関連する名前解決にも左右されます。同じサーバーで少数回のテストを繰り返し、動作確認済みの別の設定と比較しましょう。1つだけ失敗する場合は、アドレス、ポート、認証情報、セキュリティレイヤーのパラメーターを確認します。すべて失敗する場合は、まずローカルネットワーク、コアの起動状態、テスト先への接続可否を確認してください。システム時刻のずれが認証や証明書の検証に影響することもあります。時刻を同期してから、ログをもとに原因を調べましょう。

「接続済み」は、ローカルのプロキシサービスやAndroidのVPNインターフェースが起動したことを示すだけの場合があり、サーバーとのハンドシェイクが成功したとは限りません。正しいサーバーを選んでいるか確認し、実接続テストを行ってログを確認してください。次に、ブラウザーが現在のプロキシを実際に使っているか、システムプロキシのポートが一致しているか、通信を取り込むほかのツールが同時に動作していないかを調べます。一部のサイトだけ使えない場合は、ルーティングルールとDNSを確認してください。すべて使えない場合は、まず動作確認済みの設定と比較します。設定は一度に1つだけ変更し、元の値を記録しておきましょう。クライアントを終了しても直接接続できない場合は、システムに終了済みのポートを指す手動プロキシ設定が残っていないか確認してください。

まず、名前解決できないのがサーバーのドメイン名なのか、プロキシ経由でアクセスする接続先のドメイン名なのかを確認します。前者の場合はサーバーへの接続を確立できないため、ローカルネットワークの名前解決とサーバーのドメイン名の入力を確認してください。後者の場合は、コアのDNS設定、ルーティングルール、名前解決リクエストの送信経路を調べます。TUNを使っている場合は、システムのDNSが取り込まれているか、ほかのネットワークツールが設定を同時に書き換えていないかも確認しましょう。すべてのリゾルバーを一度に置き換えたり、サーバー名の検証が必要なドメインを安易にIPアドレスに置き換えたりしないでください。具体的なエラーとドメインの種類を記録し、動作する設定に戻してから一つずつ変更します。

まず、クライアントが重複して起動していれば終了し、ほかのプロキシツールが同じポートを待ち受けていないか確認してください。Windowsではリソースモニターのネットワーク画面で、待ち受けポートと対応するプロセスを確認できます。ほかのOSでは、ポートを確認できるツールを使用してください。プロセスの用途を確認してから終了を判断し、正体の分からないシステムサービスは停止しないでください。v2rayNのパラメーター設定で空いているローカルポートに変更し、関連サービスを再起動する方法もあります。ポートを変更したらシステムプロキシを再設定し、ブラウザー、ターミナル、その他のアプリに手入力したプロキシアドレスも更新してください。HTTPとSOCKSの待ち受け設定は、使用中のバージョンの画面で確認します。すべてのバージョンで同じポートが使われるとは限りません。