クライアントのよくある質問

Windows、macOS、Linuxのデスクトップではv2rayN、Androidでは通常、Xrayコアを採用したv2rayNGを選びます。V2Flyの設定との互換性が必要な場合は、v2flyNGも検討してください。まずOSを確認し、次にサーバーが指定するプロトコル、トランスポート、安全性の設定を確認しましょう。3つのクライアントではメニュー名や設定の対応状況が異なるため、名前が似ているだけで設定を使い回すことはできません。REALITYなどを使う場合は、選択したコアとクライアントのバージョンが必要な項目に対応しているかも確認してください。

クライアントは設定の読み込み、接続、ルーティングルールの適用を行いますが、インストールするだけで利用可能なサーバーが用意されるわけではありません。利用権限のあるサブスクリプションURL、共有リンク、またはサーバー情報一式を準備し、アドレス、ポート、認証情報、トランスポート、安全性の設定がそろっていることを確認してください。サブスクリプションURLや共有リンクには認証情報が含まれる場合があります。公開の掲示板などに貼り付けたり、設定画面のQRコードを他人に送ったりしないでください。必要な情報が一部しかない場合は、補完してから追加・接続を試しましょう。

VLESSはプロキシプロトコル、REALITYはトランスポートのセキュリティ方式、Xrayはそれらの設定を実行するコアです。役割の異なる3つを、同じ階層の選択肢として入れ替えることはできません。クライアントでは、プロトコルにVLESS、セキュリティ設定にREALITYを選び、サーバーの指定に従ってトランスポート方式などを設定するのが一般的です。プロトコル名をREALITYに変更するだけでは設定できず、コアを切り替えるだけで不足項目が補われるわけでもありません。設定に対応していない場合は、まずクライアントとコアの対応状況を確認し、サーバーが指定する組み合わせと照らし合わせてください。

デスクトップのシステムプロキシは、設定に従うアプリにプロキシの接続先を通知しますが、無視するアプリもあります。TUNは仮想ネットワークインターフェースを使い、ルールに一致する通信を取り込みます。通常、権限やルーティング、DNSの設定も必要です。Android版v2rayNGはシステムのVPNインターフェースを使ってローカルの転送経路を作り、初回接続時にシステムの許可を求めます。すべての通信が必ずリモートサーバーを経由するという意味ではなく、実際の経路はルーティングや対象アプリの設定によって決まります。トラブル対処では、まず通信を取り込む方法を1つ選び、複数のプロキシツールを同時に使って経路が重複しないようにしてください。

近年の主流Androidスマートフォンではarm64が使えることが多いものの、最終的にはプロセッサーの型番や購入時期ではなく、端末のOSが対応するアプリのアーキテクチャを確認してください。64ビットARMアプリに対応していると確認できた場合はarm64を選びます。アーキテクチャが分からない場合は、複数のアーキテクチャを含むuniversalを選べますが、ファイルサイズは大きくなる傾向があります。インストール時に解析エラーが出た場合は、OSのバージョン要件、ダウンロードの完了状況、旧バージョンとの署名の競合も確認してください。既存のクライアントをすぐにアンインストールせず、必要な設定を先にエクスポートしてから対応を決めましょう。

コピーしたものがサブスクリプションURLか、単一の共有リンクかを確認しましょう。サブスクリプションURLはサブスクリプショングループに追加し、共有リンクはクライアントが対応するリンクのインポート機能を使います。クリップボードに説明文や改行、前後の空白、チャットアプリが付けた句読点が混ざっていないかを確認し、アプリがクリップボードを読み取れる状態かも確認してください。サブスクリプショングループを作成しても一覧が空の場合は、サブスクリプションを更新する必要があります。URLを保存しただけでは、取得に成功したことにはなりません。それでも失敗する場合は更新ログを確認し、URLにアクセスできない問題と、取得した内容を解析できない問題を切り分けてください。

v2rayNGで初めて接続するときは、システムに表示されるVPN接続リクエストで許可してください。拒否した場合は接続を停止し、再度起動して許可します。VPNインターフェースを使用する別のアプリ、仕事用プロファイルのポリシー、常時接続VPNの制限も確認してください。デスクトップのTUNでは、クライアントの案内に従って必要なサービスをインストールまたは有効化し、必要な権限を付与します。Androidと同じ手順は使えません。それでも失敗する場合は、ログに権限エラーや仮想インターフェースのエラーがないか確認しましょう。システムの許可に関する問題を解決するために、プロトコルを何度も変更する必要はありません。

まず現在のクライアントにあるエクスポートまたはバックアップ機能を使い、サブスクリプショングループ、手動追加したサーバー、カスタムルーティングを保存します。ローカルポート、DNS、対象アプリの設定も記録してください。バックアップに認証情報が含まれる場合があるため、安全な場所に保管しましょう。新しいクライアントにインポートしたら項目を照合し、動作確認済みの設定を1つ選んで接続を確認します。コアによっては拡張項目を完全に移行できない場合があります。再取得できるサブスクリプションの項目と手動編集した項目は分けて扱い、移行が完了してから古い設定を整理してください。再インストールを最初の対処にするのは避けましょう。

まず目的に合ったルーティングプリセットを選び、LANのアドレス、直接接続するドメイン、デフォルトの出口を確認します。カスタムルールは通常、上から順に適用されるため、具体的な例外を広い範囲のルールより前に配置してください。また、参照するgeositeやgeoipのデータが現在のコアで利用可能か確認しましょう。ページが開くかどうかだけでルーティングを判断せず、クライアントのログで接続先アドレスと出口の選択を確認してください。ルールを変更したらテスト接続をやり直し、必要に応じてアプリの既存接続を切断します。接続が再利用されると、以前のルーティング結果が残ることがあります。

クライアントで有効な設定が選択され、コアが正常に起動していることを確認します。次に、システムプロキシの接続先が実際に有効なローカルの待受アドレスとポートを指しているか確認してください。SOCKSの10808やHTTPの10809はよく使われる設定ですが、現在のクライアントの設定を優先し、決めつけて入力しないでください。続いて、ブラウザー拡張機能、アプリ独自のプロキシ設定、ほかのプロキシツールがシステム設定を上書きしていないか確認します。手動プロキシに対応するアプリで同じローカルポートを指定して比較できます。手動プロキシは使えるのにシステムプロキシが効かない場合は、アプリがシステム設定に従っているかを重点的に確認してください。

サブスクリプションの項目は通常、取得した内容に基づいて管理され、更新時に再生成または置き換えられる場合があります。長く使いたい変更をサブスクリプションの項目だけに加えるのは避けましょう。トランスポートやメモなどを変更する場合は、クライアントが対応していれば独立した項目として複製し、用途が分かるように名前を付けてください。独立した項目もサーバー側の変更で使えなくなる可能性があります。ルーティングルール、サブスクリプショングループの設定、サーバー項目は別々の設定階層です。バックアップ時にそれぞれ確認しましょう。更新後は、選択中のサーバーが残っているか確認し、削除または置き換えられた項目を使い続けないようにしてください。

まず、システムによるバックグラウンド停止と、接続の再試行が続く状態を切り分けます。前者はアプリが終了されたあとに通信経路が消えることが多く、後者はログに接続エラーが繰り返し記録されます。必要に応じてクライアントのバックグラウンド実行を許可し、バッテリー最適化や自動起動の制限を確認してください。そのためにすべてのアプリの省電力設定を無効にする必要はありません。不要な自動テスト、頻繁すぎるサブスクリプション更新、詳細ログの常時記録を減らし、同じネットワークで動作を確認します。電池の消耗は電波状況、トランスポート方式、通信量にも左右されるため、プロトコル名だけで省電力かどうかを判断できません。

まずログで応答を取得できているか確認します。接続タイムアウト、証明書エラー、取得内容の解析失敗は、それぞれ異なる問題です。サブスクリプションURLの期限が切れていないか、認証情報が有効かを確認し、取得内容がログインページやエラーページになっていないか、クライアント非対応の形式ではないかも確認してください。既存のプロキシ経由で更新する必要がある場合は、まずそのプロキシが使えることを確認してから、適切な更新方法を選びます。サブスクリプションURL全体を公開の場に貼り付けて相談したり、グループを何度も削除して作り直したりしないでください。元の設定を残して順番に確認すれば、更新が復旧するまで既存の有効な項目を使い続けられます。

テストのタイムアウトは、制限時間内にそのテストが成功しなかったことを示すだけです。テスト先のアドレス、DNS、接続方式、サーバーの状態などが影響し、すべての通信が使えないことを意味するわけではありません。まずテストがTCP接続の確認なのか、実際のリクエストなのかを確認します。同じ設定でテスト用のページにアクセスし、ログも確認してください。実際のリクエストも失敗する場合は、アドレス、ポート、認証、トランスポート、安全性の設定を順に照合し、別のネットワークでも試します。テストを何度も繰り返した際の偶然の結果を性能の評価に使ったり、テストの数値1つだけで設定を選んだりしないでください。

接続済みの表示は、ローカルのコアやVPNインターフェースが起動したことを示すだけの場合があり、リモート接続、DNS、ルーティングの正常動作を保証しません。まずログに認証、ハンドシェイク、名前解決のエラーがないか確認し、ブラウザーの通信がクライアントに届いているかも確認してください。ドメインを解決できない場合は、DNS設定と問い合わせ経路を確認します。一部のサイトだけ開けない場合は、ルールの適用先と出口を確認してください。すべてのリクエストが失敗する場合は、サーバーの設定とシステム時刻を確認します。一度に変更する設定の種類は1つに絞り、変更前の値を残しましょう。DNS、プロトコル、ルーティングを同時に変更すると、原因を特定しにくくなります。

証明書の検証を無効にすることを、通常の解決方法としておすすめしません。まず端末の日付と時刻、サーバー名、サーバー側の証明書設定、使用するプロトコルに対応したセキュリティ項目を確認してください。TLSではサーバー名と接続先アドレスが異なる場合があるため、サーバーの案内に従って入力します。REALITYの場合は公開鍵やshort IDなども照合してください。適当な名前に変更しても一致するとは限りません。エラーの種類と発生した段階を記録し、必要な設定項目を提供元に確認しましょう。特定のネットワークだけでエラーが起きる場合は、別のネットワークでも比較できますが、まず原因を特定してからセキュリティ設定を変更してください。