v2rayN・v2rayNGのよくある質問

デスクトップでは、Windows・macOS・Linuxに対応するv2rayNが候補です。AndroidではXrayコアを採用したv2rayNGを優先し、V2Flyコアが必要な場合はv2flyNGを検討してください。クライアントを選んだら、サーバー設定で使うプロトコル、トランスポート方式、安全レイヤーが、そのコアでサポートされているか確認しましょう。3つは同じプログラムの別デザインではないため、設定場所や設定のインポート方法が異なる場合があります。移行する際は、まず設定を1つインポートして動作を確認してから、サブスクリプションやルーティング規則を移してください。別のクライアントのデータフォルダーをそのまま上書きするのは避けましょう。

Project Vは関連するプロキシツールのエコシステムの背景にあり、V2FlyとXrayは代表的なコアの系統です。GUIクライアントはサブスクリプションの管理、設定の編集、起動の操作を担い、コアは実際の接続、ルーティング、転送を処理します。クライアントの画面が開いていても、コアが正常に起動したとは限りません。トラブル対処では、クライアントのバージョン、コアの種類、起動ログをそれぞれ記録してください。未対応の設定項目が見つかった場合は、クライアント名だけで互換性を判断せず、その項目に対応するコアとバージョンを確認しましょう。コアを更新しても、サブスクリプションの設定値が自動的に正しくなるわけではありません。

VMess、VLESS、Trojanはプロキシプロトコルです。REALITYはXrayのエコシステムで使われる安全レイヤーの方式で、アドレス、ポート、ユーザー識別情報の代わりになる単独のノード種別ではありません。接続設定にはトランスポート方式やTLS・REALITYのパラメーターも含まれるため、サーバー側の設定と一つずつ照合する必要があります。プロトコルの選択だけをVMessからVLESSに変えても、元の設定がそのまま使えるとは限りません。REALITYを使う場合は、サーバー側から提供された公開鍵、サーバー名、shortIdなどを特に注意して確認してください。項目が不足している場合は、適当な値を試すのではなく設定の提供元に確認しましょう。

vmess://、vless://、trojan://で始まる文字列は、通常1件分の共有リンクです。インポートすると接続設定が1件保存されます。一方、サブスクリプションURLは通常HTTPSのアドレスで、クライアントがアクセスして複数の設定を取得し、あとから更新できます。ブラウザーでURLを開けても、クライアントが読み込める形式とは限りません。ログイン画面やエラーメッセージが返る場合もあります。1件の共有リンクはクリップボードからインポートし、サブスクリプションURLはサブスクリプショングループに登録してください。URLにアクセス認証情報が含まれていることがあるため、スクリーンショット、ログ、問い合わせ内容ではURL全体とクエリパラメーターを必ず隠しましょう。

2015年以降の一般的なAndroidスマートフォンではarm64が有力ですが、最終的には端末が対応するアプリABIを確認してください。プロセッサーが64ビット対応でも、OSが64ビットアプリ環境を提供しているとは限りません。universalは複数のアーキテクチャを含むため、容量は大きめですが、端末の構成がわからない場合に試せます。インストールパッケージを解析できない場合は、OSのバージョン要件、ダウンロードの完了状況、元のアプリとの署名の互換性も確認しましょう。アーキテクチャを試すために何度もアプリをアンインストールするのは避けてください。削除前に設定をバックアップし、バックアップにはサブスクリプションURLや接続認証情報が含まれる場合があることにも注意しましょう。

まず、インポートする内容を確認します。1件の共有リンクはクリップボードからインポートし、サブスクリプションURLはサブスクリプショングループの設定に登録します。コピーする際はURLの前後にある空白、改行、日本語の句読点を取り除き、ウェブページのタイトルまで貼り付けていないか確認してください。グループを保存しただけでは設定は表示されず、通常はサブスクリプションを更新する必要があります。更新後も空の場合は、URLの有効期限、ログインの要否、クライアントが対応する形式かどうかを確認しましょう。サブスクリプションURLをノードのサーバーアドレスとして入力してはいけません。エラーを報告する際はエラーの種類を残し、サブスクリプションの認証情報や個人設定は伏せてください。

システムプロキシとTUNは、異なる方法で通信を取り込む機能です。システムプロキシは、OSのプロキシ設定に従うアプリで使われます。TUNは仮想ネットワークインターフェースを通じて通信を取り込み、対象範囲はルーティング、除外ルール、DNS設定にも左右されます。初めて設定する場合は、まずシステムプロキシだけで動作を確認し、必要に応じてTUNを試してください。複数の設定を同時に変更するのは避けましょう。環境によっては併用できますが、両方を有効にすれば必ずより広く通信を扱えるとは限りません。切り替え前に元の設定を記録し、クライアントを終了したあと、システムプロキシとネットワークルートが復元されているか確認してください。複数のネットワークツールを使っている端末では特に注意が必要です。

まず起動ログを確認し、権限の許可、仮想インターフェースの作成、ルートの設定のどの段階で失敗したかを特定します。デスクトップでは、クライアントの案内に従って必要なシステム権限を許可してください。Windowsでは管理者権限やサービスモードが必要な場合があり、ほかのデスクトップOSでもネットワークコンポーネントのインストール許可を求められることがあります。AndroidではVPN接続を許可し、別のVPNアプリが接続を使用していないか確認してください。エラーを回避するためにすべてのセキュリティ機能を無効にしたり、システムのネットワークアダプターを削除したりしないでください。TUNを有効にしてネットワークが切れた場合は、まずTUNを無効にして通信を復旧させてから、競合するツール、インターフェース設定、ルートを順に確認しましょう。

テスト結果は、テスト方法によって異なります。TCPテストでわかるのは、通常、対象ポートに接続できるかどうかです。実際のリクエストテストでは、プロキシのハンドシェイク、接続先のウェブサイト、DNSも関係します。あるテストが成功しても、すべてのアプリがプロキシ経由で通信していることや、すべての接続先にアクセスできることの証明にはなりません。まずクライアントがどの方式でテストしているか確認し、同じ設定で明確なHTTPS接続先にアクセスして、対応するリクエストが接続ログに記録されるか見てください。テスト数値の順に並べるだけで、利用可能かどうかを判断しないようにしましょう。テストのタイムアウトは接続先自体が原因の場合もあります。設定を何度も切り替えるのではなく、通常の通信とログを照らし合わせて原因を絞り込みましょう。

モードの名称はクライアントによって異なるため、実際に生成されたルーティング規則を確認してください。ルールモードではドメイン、IPなどの条件に応じて通信の出先を選びます。グローバルプロキシでは、取り込まれた通信を通常プロキシ経由で送ります。直接接続では、遠隔のプロキシを経由しません。グローバルプロキシを有効にしても、クライアントに取り込まれていないアプリの通信まで自動的に処理されるわけではありません。同じ接続先に固定して、まずアプリの通信がクライアントに入っていることを確認し、次に適用された出先のタグを確認しましょう。グローバルプロキシでは接続できるのにルールモードで失敗する場合は、サーバーアドレスやユーザー識別情報をすぐに変えず、ルールの順序、ルールデータファイル、DNSを先に確認してください。

まず、残しておきたいものがサブスクリプションで取得したノード、手動で追加したノード、クライアント全体のルーティングやDNS設定のどれかを確認しましょう。更新によって対象グループ内の項目が再生成されることがあり、サブスクリプションのノードを直接編集すると、次の更新で変更が失われる場合があります。長期的に維持したい設定は独立したグループにコピーし、クライアントのエクスポートまたはバックアップ機能で保存してください。バックアップ後は、完了メッセージだけに頼らず、ファイルが実際に作成されたか確認しましょう。復元する際は、まず少数の設定で互換性を検証してください。エクスポートした内容には機密情報が含まれることが多いため、管理された場所に保管し、公開の添付ファイルとして送らないでください。

まず、システムDNS、ブラウザーのセキュアDNS、コアのDNSを区別してください。それぞれ異なる段階で使われる場合があります。アプリが独自にドメインを名前解決すると、コアが意図したとおりにドメインルールを適用できないことがあります。TUNモードではDNSを取り込む設定も関係します。元の値を記録し、一度に変更するのは1か所だけにして、同じ接続先で確認しながらログを見ましょう。パブリックDNSのアドレスを入力すればすべて直るとは限りません。domainStrategyやqueryStrategyを変更する前に、現在のコアが対応する値と適用される段階を確認してください。ルーティング時の名前解決方針と、問い合わせるアドレスファミリーの方針は別の設定です。

まず端末から通常のウェブサイトにアクセスできるか確認し、次に現在の設定にあるサーバーアドレス、ポート、プロトコル、安全レイヤーのパラメーターに入力ミスがないか確認してください。設定が1件だけ失敗する場合は、その設定とサーバーの状態を優先して確認します。すべて失敗する場合は、ローカルネットワーク、コアの起動状態、システム時刻を確認してください。接続タイムアウト、認証エラー、証明書エラーは原因が異なるため、ログに記録されたエラーの種類を残しましょう。ネットワークを切り替えると問題の範囲を絞れますが、一度に変更する条件は1つだけにしてください。ハンドシェイクエラーを隠すために証明書検証を無効にしたり、ポートに接続できるだけでプロキシ接続が確立したと判断したりしないでください。

接続済みという表示は、多くの場合、クライアントのサービスやローカルインターフェースが起動したことを示すだけで、遠隔サーバーとの接続成功を保証するものではありません。まずログを開いてからウェブページにアクセスしてください。リクエストが記録されない場合は、アプリがシステムプロキシを使っているか、ローカルポートが正しいか、別のプロキシ拡張機能が通信を処理していないか確認します。リクエストが記録されている場合は、DNS、ハンドシェイク、出先に関するエラーを確認してください。ルーティングの競合を減らすため、まずTUNを無効にし、1つの接続方式だけで動作を確認しましょう。ドメイン名でのアクセスだけが失敗する場合は、名前解決の経路を重点的に確認してください。HTTPSサイトのIPアドレスへ直接アクセスする方法だけで判断しないでください。証明書やサイトの選択にドメイン名が必要な場合があります。

まずコアが起動していることを確認し、クライアントが実際に待ち受けているアドレスとHTTPまたはSOCKSのポートを確認してください。解説記事に記載されたポート番号をそのまま使わないようにしましょう。ブラウザーではプロキシ拡張機能、個別のプロキシ設定、既存の接続を確認し、必要であればブラウザーを再起動して試します。コマンドラインのプログラムはシステムプロキシを参照しないことがあります。その場合、プログラム固有のプロキシオプションやHTTP_PROXY、HTTPS_PROXYなどの環境変数が必要です。NO_PROXYで接続先が除外されていないかも確認してください。プロトコルの接頭辞は待ち受けサービスと一致させる必要があります。古い環境変数が意図した設定を上書きすることもあるため、ブラウザーとターミナルを別々にテストし、片方の成功だけで両方に設定が反映されたと判断しないでください。

まず現在使えている設定を残し、更新時に表示されたエラーを記録してください。接続タイムアウトの場合は、ネットワーク経路と、クライアントがプロキシ経由の更新に対応しているかを確認します。HTTP 401または403の場合は、認証情報、有効期限、アクセス制限を確認してください。更新が成功しても一覧が空の場合は、内容の形式と、サブスクリプションに項目が残っているかを確認しましょう。設定テキストではなくウェブページを返すURLもあります。ブラウザーでページが表示されても、サブスクリプションが有効とは限りません。更新にプロキシ接続が必要な場合は、更新に使う設定が接続できることを先に確認し、まだ更新に成功していないグループに依存しないようにしてください。原因の特定に必要な情報を失わないよう、グループを何度も削除して作り直すのは避けましょう。