V2Rayのよくある質問

まず使用するデバイスに合わせて選び、必要な設定を確認します。Windows、macOS、Linuxではv2rayNを使用します。Androidでは通常、Xrayコアを採用したv2rayNGを選び、v2flyコアが必要な場合はv2flyNGを検討します。クライアントは画面表示やサブスクリプション管理、モード切り替えを担当し、コアは各プロトコルを処理します。名前が似ていても設定がすべて共通とは限りません。特に通信方式やセキュリティ設定はサーバー側と一致させる必要があります。すでにサブスクリプションを利用している場合は、提供元が指定するクライアントとコアを確認してください。プロトコル名だけで互換性を判断せず、クライアントを切り替える前に現在の設定を控えておくと比較しやすくなります。

クライアント自体に、そのまま接続できるサーバーが含まれているわけではありません。設定を始める前に、利用権限のあるサブスクリプションURL、単一ノードの共有リンク、またはサーバー設定一式を用意し、デバイスがローカルネットワークに正常に接続できることを確認してください。手動で入力する場合は、アドレス、ポート、ユーザーID、通信方式、TLSなどの項目を一つずつ照合し、不明な値を推測で補わないでください。まずデバイスの日付とタイムゾーンを正しく設定し、利用できることが分かっている設定を一つインポートしてテストします。サブスクリプションURLや共有リンクには認証情報が含まれる場合があります。公開ページに掲載したり、内容全体を見知らぬ人に渡して調査を依頼したりしないでください。

単一ノードの共有リンクは通常、vmess://やvless://などのプロトコルで始まり、1つの接続設定を表します。サブスクリプションURLは一般にアクセス可能なHTTPSアドレスで、クライアントがそのURLにアクセスしてノード一覧を取得します。単一ノードのリンクをコピーした場合は、クリップボードからインポートする機能を使います。サブスクリプションを追加する場合は、サブスクリプション管理画面でURLを保存してから更新します。サブスクリプションURLをサーバーアドレスとして入力しても、正しい設定にはならないのが一般的です。単一ノードをインポートしても元のリンクの変更は自動反映されませんが、サブスクリプションは次回更新時にノードを同期できます。ただし、更新の成否はサブスクリプションサービスとネットワークの状態によります。

それぞれ異なるレイヤーの設定です。システムプロキシを使うアプリは、リクエストをローカルのプロキシポートに送ります。TUNは仮想ネットワークインターフェースで通信を受け取り、システムプロキシを参照しない一部のアプリにも対応できます。グローバルルーティングは、コアに入った通信の出口を決める設定であり、すべてのアプリの通信がコアに入ることを保証するものではありません。そのため、適切な通信の取り込み方式を有効にせずグローバルルーティングだけを切り替えても、一部のアプリは直接接続する可能性があります。初めて設定する場合は、まずシステムプロキシでブラウザーの接続を確認し、必要に応じてTUNを有効にしてください。切り替える際は、LAN、DNS、除外ルールに注意し、一度に多くの設定を変更しないようにしましょう。

OSのバージョンだけでなく、デバイスのプロセッサアーキテクチャを確認してください。比較的新しいAndroidスマートフォンの多くはarm64なので、通常は対応するインストールパッケージを選びます。universalパッケージは複数のアーキテクチャに対応することが多く、ファイルサイズは大きめです。アーキテクチャを確認できず、パッケージがデバイスに対応している場合に適しています。インストール非対応と表示されたら、システムのデバイス情報や信頼できる仕様情報でアーキテクチャを確認し、ダウンロードページで適切なものを選び直してください。上書きインストールに失敗する原因には、署名の違い、バージョンの巻き戻し、空き容量不足もあります。既存アプリをすぐにアンインストールせず、先に設定をバックアップしてください。アンインストールするとサブスクリプション、ノード、カスタムルールが消える場合があります。

まず、単一ノードのインポートではなく、サブスクリプションの追加を実行したか確認してください。サブスクリプション管理画面でURLがすべてコピーされているかを確認し、余分な空白、改行、説明文を取り除きます。保存後に手動で更新し、該当するサブスクリプショングループを開いてください。それでも空の場合は、更新時にアクセス失敗、解析失敗、内容が空のどれが表示されたか確認します。Webページやログイン画面が返された場合、または対応していない形式の場合、ノードを認識できないことがあります。そのURLが現在のクライアントに対応しているか、アカウントが有効かを提供元に確認してください。URLを見知らぬオンライン変換サービスに貼り付けないでください。調査用のスクリーンショットを共有する際も、URL内の認証情報を隠してください。

まずプロセッサアーキテクチャとインストールパッケージの形式を確認します。Windowsではダウンロードページの案内に従ってデスクトップ版と従来のWPF版を選び、システムが選択したバージョンの要件を満たすか確認してください。macOSでは「このMacについて」でチップを確認し、Apple SiliconまたはIntel向けの項目を選びます。Linuxではディストリビューションのパッケージ形式に合わせてdebまたはrpmを選び、さらにx64とarm64を区別します。インストールパッケージをダウンロードできても、現在のシステムに対応しているとは限りません。システムのセキュリティ警告が表示されたら、ファイルの入手元と警告の理由を確認し、セキュリティ機能を一括で無効にしないでください。初回起動後は、まず通常のプロキシ接続を設定します。仮想ネットワークインターフェースや追加の権限は、必要な場合に設定してください。

設定を保存して接続を停止し、仮想ネットワークインターフェースの作成、ルートの変更、デバイスへのアクセスのどの段階で拒否されたかをログで確認してください。Windowsでは通常、クライアントの案内に従って管理者権限で実行するか、必要なサービスをインストールします。macOSとLinuxの認証方法はバージョンやパッケージ形式によって異なるため、現在のクライアントの案内に従い、他のプラットフォーム向けの権限昇格コマンドをそのまま使わないでください。Androidでは初回接続時にシステムのVPN接続を許可し、他のVPNアプリが接続を使用中でないか確認します。許可後に該当機能を再起動し、ログから権限エラーが消えたか確認してください。問題を回避するためにシステムのセキュリティ機能を常時無効にするのは避けてください。

サブスクリプションURLに実際にアクセスできる方法を選びます。現在のネットワークからURLに直接アクセスできるなら、まず直接接続で更新してください。プロキシ経由でなければアクセスできず、使用可能なノードがある場合に限り、プロキシ経由で更新します。すべてのノードが使えなくなっていると、そのノードを使ってサブスクリプションを更新することはできず、解決できない循環に陥ります。アクセス可能なネットワークを使うか、提供元から有効な新しいURLを入手してください。更新前に現在のグループとエラーメッセージを記録し、更新後はノードが実際に変わったか確認します。短時間に何度もリクエストしないでください。サービス側で頻度が制限されている場合があります。また、端末での名前解決失敗、証明書エラー、アカウント期限切れを同じ更新エラーとして扱わないようにしましょう。

通常は必要ありません。既存のグループから使いたいノードを選び、現在の接続先に設定してから、クライアントの案内に従って再接続または設定を再読み込みします。ノード単体をテストする場合は、ルーティング、DNS、プロキシモードを同時に変更しないでください。違いの原因を特定しにくくなります。サブスクリプションの更新でノードIDが置き換わることがあるため、更新後は選択中の項目が引き続き有効か確認し、削除済みの項目を参照しないようにしてください。重要なカスタム設定は更新前に記録し、サブスクリプションから生成された設定を永続的な保存場所と誤認しないようにしましょう。サブスクリプションURLの変更、元のグループの破損、設定形式の変更が必要な場合に限り、サブスクリプションの再追加を検討してください。

まず用途に合ったルーティングルールセットを有効にし、各ルールの適用順を確認します。多くのルールは上から順に照合されるため、LANアドレスや特定ドメインなど、優先したいルールを適切な位置に置き、より広い範囲のルールに先に一致しないようにしてください。ドメインルール、IPルール、DNSの名前解決方針は相互に影響します。「直接接続」の指定を一つ変更しただけで、すべての通信が想定どおりになるとは限りません。変更後はLAN内のサービス、直接接続させるWebサイト、プロキシ経由にするWebサイトをそれぞれテストし、ログで確認できる場合は実際の出口も確認します。グローバルプロキシモードではルールの適用方法が変わる場合があるため、振り分けをテストする前に適切なルールモードが選択されているか確認してください。

よくある原因は、停止したローカルプロキシポートをシステムが引き続き参照していることです。通常の手順で終了する場合は、接続を停止する前にクライアントでシステムプロキシを無効化または解除してください。クライアントが異常終了した場合は、再起動してプロキシを解除するか、システムのネットワーク設定でプロキシの有効・無効とアドレスを確認し、今回の設定で残ったローカルプロキシ項目を削除します。TUNを使っていた場合は、仮想ネットワークインターフェースとルートが復旧しているかも確認してください。必要なら通常の手順で再接続してから停止します。職場や学校のネットワークで必要な固定設定は削除しないでください。変更前に元の値を記録しておきましょう。最後にブラウザーをいったん終了して開き直し、通常のネットワーク接続が復旧したか確認します。

まず通常のネットワークが使えることを確認し、次にノードのアドレスとポート、サブスクリプションの有効期限を確認します。テストの種類も区別してください。TCP接続テストに失敗する場合、宛先に到達できない、ポートが制限されている、サーバーが待ち受けていないなどの原因が考えられます。実際の接続テストでは、プロトコルのハンドシェイク、TLS、DNS、テスト対象のWebサイトも関係します。ある種類のテストがタイムアウトしただけで、すべてのアプリが使えないとは判断できません。設定を一つ変えずに保ち、利用できることが分かっている別のノードと比較し、該当時刻のログを確認します。1つのノードだけ失敗する場合は、そのノードとサーバーの状態を優先して確認してください。すべて失敗する場合は、端末のファイアウォール、ネットワーク環境、デバイスの時刻、コアの起動状態を確認します。

接続済みという表示は、通常、ローカルサービスやVPNトンネルが起動したことを示すだけで、リモートへのリクエストが成功したことを意味しません。まずコアが正常に動作しているか確認し、ブラウザーのリクエストがクライアントに届いているかを確認してください。リクエストのログがない場合は、システムプロキシ、ブラウザー独自のプロキシ設定、ローカルの待ち受けポートを優先して確認します。リクエストは届いているのに接続できない場合は、ノードの設定、サーバーの状態、TLSエラーを確認してください。ドメインを名前解決できない場合は、DNS設定とDNSサービスへの到達性を確認します。一度に変更する項目は一つにして、同じテストを繰り返してください。すべての保護機能を無効にしたり、証明書設定を安易に変更したりしないでください。特に、証明書検証をスキップする方法を一般的な解決策として使わないでください。

まず、そのアプリがシステムプロキシを参照するか確認してください。独自のネットワーク設定やプロキシ拡張機能、別のネットワークインターフェースを使うアプリもあり、システムプロキシを有効にしても接続方法が自動で変わるとは限りません。システムプロキシに従うブラウザーで比較し、対象アプリがHTTPまたはSOCKSプロキシを個別に設定できるか確認してください。設定できる場合は、クライアントが実際に待ち受けているアドレスとポートを入力します。アプリ側で設定できない場合は、TUNが適しているか検討し、除外ルールと権限も確認してください。端末上のアプリを接続させる目的で、安易にLANからのアクセスを許可しないでください。待ち受け範囲が広がるうえ、端末のシステムプロキシが有効かどうかとは別の問題です。

障害の発生時刻、OSとクライアントのバージョン、使用中のコア、プロキシモード、実行したテスト、エラー前後の関連ログを残してください。接続を停止し、同じ操作を一度再現してから短い範囲のログを切り出すと、過去のログ全体より原因を特定しやすくなります。共有前にサブスクリプションURL、ユーザーID、パスワード、アクセストークン、個人を特定できる情報を隠してください。スクリーンショットに含まれるQRコードや共有リンクも隠します。認証情報全体を公開せず、アドレスの種類やエラーの分類を伝えることはできます。ログに起動成功の情報しかない場合は、実際にリクエストを送った後のログを追加し、すべてのアプリで失敗するのか、特定のWebサイトやアプリだけで問題が起きるのかを説明してください。