V2Ray よくある質問

いいえ。V2RayはProject Vのプロキシツールエコシステムに属し、V2Flyは関連するコアをコミュニティで引き継いで保守しています。Xrayは別系統のコアで、対応するプロトコルや機能はバージョンによって異なります。v2rayNはサーバー、サブスクリプション、ルーティング、コアの起動を管理するGUIクライアントです。設定をインポートした後、実際に接続を処理するのはクライアントが呼び出すコアです。プロトコル非対応や起動エラーが発生した場合は、ウィンドウに表示された製品名だけでなく、クライアントとコアの両方の情報を確認してください。特にREALITYなどの設定では、サーバー側の要件と使用中のコアの対応状況を確認する必要があります。プロトコル名を変更するだけでは解決しません。

Windows、macOS、Linuxのデスクトップでは、まずv2rayNを検討し、OSとプロセッサのアーキテクチャに合ったインストーラーを選びます。Androidでは、Xrayコアを採用したv2rayNG、またはV2Flyコアを採用したv2flyNGを選べます。サービス提供元が指定するプロトコル、通信方式、安全設定を確認し、クライアントに含まれるコアが対応しているか確かめてください。2つのAndroidクライアントは設定画面や機能が完全に同じとは限らないため、別のクライアントの設定をそのまま適用するのは避けましょう。安定して使えている設定はバックアップを残し、必要に応じてクライアントの変更を検討してください。名前を切り替えてもサーバーの品質は変わりません。

クライアントは設定を読み込んで接続を確立するもので、インストーラーにサーバーは含まれていません。利用権のあるサービス提供元からサブスクリプションURL、共有リンク、または手動設定用の情報を取得し、クライアントにインポートしてください。サブスクリプションはサーバー設定を更新するための入口で、個別の共有リンクは通常1つの設定を表します。それぞれ適切な方法でインポートしましょう。購入ページ、ログインページ、一般のWebページのURLをサブスクリプションURLとして使うことはできません。サブスクリプションURLにはアクセス情報が含まれる場合があるため、機密情報として保管し、スクリーンショットやフォーラム、ログに公開しないでください。出所が不明なリンクをそのままインポートして有効化するのも避けましょう。

システムプロキシは、端末のプロキシアドレスをOSの設定に登録します。通常、この設定に従うアプリだけがプロキシを使用します。TUNは仮想ネットワークアダプターとシステムルートを使って通信を取り込み、より広い範囲をカバーしますが、権限が必要で、ほかの仮想アダプターやVPNと競合することがあります。ルーティングルールは、コアに入ったリクエストの出口を決めるもので、すべてのアプリの通信を自動的にクライアントへ取り込む機能ではありません。トラブル時は、通信がクライアントに入っているか、入った後どこへ向かっているかを分けて確認しましょう。初めて設定する場合は、まずシステムプロキシでWebページを開いてノードの動作を確認し、その後TUNを有効にすると、権限・DNS・ノードの問題を切り分けやすくなります。

2015年以降の一般的なAndroidスマートフォンでは、まずarm64を検討できますが、最終的には端末が対応するアプリのアーキテクチャを確認してください。購入年だけでは判断できません。64ビットCPUを搭載していても、OSが32ビットアプリにしか対応していない端末では、arm64版をインストールできない場合があります。universal版は複数のアーキテクチャに対応する分、ファイルサイズが大きくなる傾向があり、アーキテクチャが不明な場合やarm64版をインストールできない場合に適しています。別のパッケージを試す前に、OSのバージョン、空き容量、インストール時のエラーを確認しましょう。同じアプリがすでにインストールされている場合は、署名の違いによって上書きできないこともあります。必要に応じて設定をバックアップしてから、旧アプリをアンインストールするか判断してください。

まず、サブスクリプションURLが末尾まで正しくコピーされ、余分な空白や改行、説明文が混ざっていないか確認してください。v2rayNでは、サブスクリプションURLをサブスクリプショングループの設定に登録してから更新します。個別のサーバー共有リンクは、サーバー用のインポート機能を使います。入口を取り違えると、解析に失敗することがあります。URLを取得できてもエラーが出る場合は、取得した内容がログインページや有効期限切れの案内になっていないか、クライアントが対応していない形式ではないか確認しましょう。ブラウザーでURLを開けるだけで、サブスクリプションが有効だとは判断できません。元のURLは変更せずに保管し、対応クライアントと形式を提供元に確認してください。URLのパラメーターを自分で変更するのは避けましょう。

まずサービスアカウントとサブスクリプションの有効期限、提供元によるURL変更の有無を確認し、現在のネットワークからサブスクリプションサービスにアクセスできるか確かめてください。更新リクエストは既存のプロキシ経由で送る場合と、直接接続する場合があります。クライアントの更新オプションと提供元の案内に従い、設定をむやみに切り替えないでください。取得に成功してもノードが表示されない場合は、内容の形式、サーバーのフィルター条件、コアとの互換性を確認します。更新前に使える設定を残し、グループ全体をすぐ削除しないでください。サーバーから空の内容が返っている場合、何度更新しても解決しないことがあります。エラーメッセージと発生時刻を記録し、問い合わせる際はサブスクリプションURL全体を隠してください。

まずTUNを無効にし、通常のプロキシ接続が使えることを確認してから、システム権限を確認します。Windowsではクライアントの案内に従って管理者権限で実行するか、サービスモードが正しくインストールされ、起動しているか確認してください。macOSとLinuxでは、使用中のバージョンの説明に従って必要な権限を許可します。Androidでは、システムのVPN許可ダイアログで、使用中のクライアントに許可を与えてください。同時に通信を取り込むアプリは、できるだけ1つだけ起動します。許可済みでもエラーが出る場合は、ログで仮想アダプター、デバイスの作成、ルート設定に関するエラーを確認してください。最初からすべてのセキュリティ機能を無効にしたり、出所不明の場所からドライバーをインストールしたりするのは避けましょう。

まずクライアントが起動していて、サーバーが選択され、システムプロキシが有効になっていることを確認します。次に、OSに登録されたプロキシアドレスとポートが、現在のローカル待ち受け設定と一致しているか確認してください。ブラウザー拡張機能、独自のプロキシ設定、除外リスト、PACルールによって、実際の通信経路が変わることがあります。システム設定を読み直すために再起動が必要なアプリもあれば、システムプロキシをまったく使わないアプリもあります。ブラウザーのプロキシ拡張機能を一時的に無効にし、プロキシ経由になるはずのリクエストを送って、クライアントのログに接続記録が残るか確認しましょう。記録がなければ入口を、記録があればルーティングとノードを確認します。Webページが開けるかどうかだけで、プロキシが有効だと判断しないでください。

まず直接接続したいドメインやアドレス範囲を決め、ルーティング設定にルールを追加して、直接接続の出口を選択します。ルールは通常、上から順に照合されますが、詳しい動作はコアと生成された設定によって異なります。明確な例外ルールは、それを上書きする可能性のある広い範囲のルールより前に配置してください。ドメインルールとIPルールは同じではなく、名前解決の結果も照合に影響します。一度に変更する条件は1種類にし、設定を適用した後、実際にアクセスしてログから出口を確認しましょう。1つのWebサイトのためにすぐ全通信を直接接続にしたり、優先順位を理解しないまま複数のルールセットを同時にインポートしたりするのは避けてください。複雑な設定はバックアップを取ってから、段階的に検証しましょう。

必ずしも必要ではありません。システムDNS、ブラウザーのセキュアDNS、コアのDNSはそれぞれ異なる階層にあり、クライアントを経由するかどうかはプロキシモード、リクエスト方法、ルーティング設定によって異なります。まず問題が名前解決にあるのか、接続自体にあるのかを確認してから、変更する階層を決めてください。ブラウザーで独自のセキュアDNSを有効にしている場合、システム側のテストとは結果が異なることがあります。TUNモードではDNSの取り込みが有効かも確認しましょう。変更前に元の設定を記録し、一度に変えるのは1項目だけにして、必要に応じて関連するキャッシュを消去してから再テストしてください。複数のDNSサービスを同時に変更してFakeDNSも有効にすると、どの設定が問題を解決または発生させたのか判断しにくくなります。

まず2台の端末を、相互に通信できる信頼済みのLANに接続します。v2rayNでLANからの接続を許可し、ローカルのHTTPまたはSOCKS待ち受けポートを確認してください。他の端末にはループバックアドレスではなく、パソコンのLAN内アドレスと対応するポートを設定します。システムのファイアウォールでは、信頼済みネットワークに対して使用するポートだけを許可します。ルーターのゲストネットワーク分離によって通信できない場合もあります。端末のプロキシ設定は待ち受けプロトコルに合わせてください。テレビやアプリの中には、システムプロキシを使用しないものもあります。共有を終えたらLANからの接続を無効にし、ポートをインターネットに公開しないでください。パソコンのスリープ、IPアドレスの変更、クライアントの終了によって共有は中断します。

まずプロキシを無効にして端末の基本的なネットワーク接続を確認し、システム時刻を合わせます。次に、正しいサーバーと動作モードが選択されているか確認してください。その後、サーバーアドレス、ポート、ユーザー情報、通信方式、TLSまたはREALITYの設定を確認し、最後にDNSとコアのログを調べます。一度に変更するのは1項目だけにし、元の設定も残してください。TCPの接続テスト、実際のプロキシリクエスト、速度テストはそれぞれ意味が異なります。テストがタイムアウトしても、すべての接続が使えないとは限りません。ほかの正常なノードが使える場合は、問題がそのサーバーや設定に絞られる可能性があります。すべて失敗する場合は、端末のネットワーク、プロキシの入口、コアが正常に起動しているかを優先して確認してください。

接続済みという表示は、ローカルのコアやVPNサービスが起動したことを示すだけで、リモートサーバーへのリクエストが成功するとは限りません。Webページにアクセスしたとき、接続ログが記録されるか確認しましょう。記録がなければ、システムプロキシ、アプリ独自のプロキシ設定、TUNによる通信の取り込みを確認します。記録があれば、出口、DNS、ハンドシェイク、タイムアウトに関する情報を調べてください。複数のWebサイトにアクセスし、特定のサイトだけの問題か、接続全体の問題かを切り分けることもできます。正常に使える設定に切り替えて復旧した場合は、元のノード設定とサービスの状態を確認しましょう。リクエストがクライアントに届いているか確認する前にDNSを何度も変更したり、タスクトレイのアイコンやAndroidのVPNマークだけで接続可能と判断したりしないでください。

まずTUNを無効にして元の接続方法に戻し、エラーログを残したうえで、権限、仮想ネットワークアダプター、DNSの取り込み、ルートの設定が正常に行われたか確認します。ほかのVPN、仮想マシンのネットワーク、セキュリティソフトがTUNと競合することがあります。関連するアプリを1つずつ終了して試し、複数の設定を同時に変更しないでください。FakeDNSを使っている場合は、関連するルーティングとDNSの設定が対応しているか確認します。基本的なTUNが動作しない場合は、まず通常の名前解決に戻しましょう。クライアントを終了してもネットに接続できない場合は、システムプロキシの設定が残っていないか、ネットワークアダプターに異常がないか確認してください。必要ならシステムを再起動して復旧させてから、手順を追って再試行します。システムのネットワークコンポーネントを直接削除するのは避けてください。

OS、クライアントとコアの情報、使用モード、失敗するまでの手順、発生時刻、関連するエラーログを伝えてください。問題を一度再現し、同じ時間帯の起動エラーや接続エラーを記録します。直接接続が正常か、ほかの設定が使えるか、最近変更した項目も説明してください。サブスクリプションURL全体、ユーザーID、パスワード、秘密鍵、設定ファイル全体は公開しないでください。スクリーンショットにアドレスバーやサーバーの詳細情報が写っていないかも確認しましょう。タイムアウト、名前解決の失敗、権限拒否、ハンドシェイクエラーは、それぞれ異なる問題箇所を示します。「使えない」とだけ書くより、エラーの原文を残すほうが役立ちます。共有前に、デバッグログに機密性の高いリクエスト情報が含まれていないか確認してください。