V2Rayのよくある質問
サブスクリプション・プロキシ・TUN

まず、コアとGUIクライアントを区別しましょう。V2RayはProject Vのエコシステムに属し、V2Flyが関連コアを開発しています。Xrayは別系統のコアで、対応するプロトコルやトランスポートはバージョンとともに進化しています。v2rayNはデスクトップ向けGUIを提供し、サブスクリプショングループ、サーバー、ルーティングを管理して、選択したコアで接続を実行します。設定が使えるか判断するには、クライアントがリンクを解析できるか、コアが設定項目に対応しているかの両方を確認してください。クライアント名だけで、REALITYや特定のトランスポートが必ず使えるとは判断できません。

クライアントは設定を読み込んで接続しますが、インストールしただけで利用可能なサーバーが手に入るわけではありません。サブスクリプションURLは複数のサーバー設定を取得するためのもので、通常は設定の提供元から発行され、アカウント情報が含まれる場合もあります。URLを取得したらサブスクリプショングループに登録し、更新を実行してください。URLを登録しただけで更新していない場合、サーバー一覧が空のままになることがあります。まずサービスの稼働状況と有効期限を確認してから、クライアントの設定を見直しましょう。URL全体を公開の掲示板に投稿しないでください。トラブル対処用のスクリーンショットでも、クエリパラメーターや個人を特定できる情報を隠してください。

サブスクリプションURLは通常、ネットワーク経由で複数の設定を取得するもので、サブスクリプショングループで継続的に管理するのに適しています。個別ノードの共有リンクは1台のサーバー設定を表し、vmess://、vless://、trojan://などの形式があります。QRコードの見た目だけで種類を判断せず、デコードした内容を確認してください。個別リンクはクリップボードからのインポートなどで追加し、サブスクリプションURLはサブスクリプショングループに登録します。手動でインポートしたノードは、サブスクリプションを更新しても変更されないことがあります。提供元がポートや認証パラメーターを変更した場合は、再インポートするか設定項目を確認してください。

それぞれ別の機能です。システムプロキシは、システム設定に従うアプリにローカルプロキシの接続先を提供します。グローバルルーティングは、コアに渡されたリクエストの通常の出力先を決めます。TUNは仮想ネットワークインターフェースを使って、条件に合うトラフィックを取り込みます。グローバルルーティングを有効にしても、システムプロキシを使わないアプリが自動的にコアへ接続されるわけではありません。TUNを有効にしても、すべてのルートがプロキシ経由になるとは限りません。まずアプリの通信がクライアントに届く経路を確認し、その後ルーティングの出力先を確認しましょう。最初の動作確認では取り込み方式を1つだけ有効にし、複数の入口や他のネットワークツールが同時に動作しないようにしてください。

Androidのバージョンだけでなく、まず端末のCPUアーキテクチャを確認してください。比較的新しい一般的なスマートフォンなら、通常はファイルサイズの小さいarm64版が適しています。アーキテクチャが分からない場合や、インストール時に非対応と表示される場合はuniversal版を選べますが、universal版にも最低OSバージョンなどの条件があります。デスクトップ端末も対応するアーキテクチャを選び、Apple Silicon用とIntel用のインストール方法を混同しないでください。アップデート前にサブスクリプションURLと必要な設定を控え、ダウンロードセンターで該当プラットフォームを選びましょう。アーキテクチャの問題を解決するために、出所不明のインストーラーで上書きしないでください。

まず、コピーした内容がサブスクリプションURL全体であることを確認し、前後の空白や改行、チャットアプリが付け加えた文字を削除してください。サブスクリプショングループの設定を開き、URLを「Url」欄に入力し、グループが有効になっていることを確認してから更新します。解析エラーが出る場合、返された内容がログインページやエラーメッセージ、非対応のサブスクリプション形式である可能性があります。提供元に、使用するクライアントに対応した形式か確認してください。更新成功と表示されてもノードがない場合は、グループの絞り込みやフィルター用正規表現を解除して確認します。同じ名前のグループを何度も作って、元のエラーを見えなくしないでください。

まず現在のネットワークから「プロキシを経由せずにすべてのサブスクリプションを更新」を試し、ログに記録されたネットワークエラーやHTTPステータスを確認してください。URLへのアクセスに既存の有効なプロキシが必要な場合は、現在のアクティブノードとローカルプロキシが実際に使えることを確認したうえで、「プロキシ経由ですべてのサブスクリプションを更新」を試します。すでに使えないノードを使って、同じサブスクリプションを更新しようとしないでください。認証失敗、URLの期限切れ、サーバーから返されたエラー内容は、更新方法を切り替えても解決しないことがほとんどです。URL、サービス状況、応答形式を順に確認し、ログを共有する前にサブスクリプションのパラメーターを隠してください。

まずコアが起動しており、ローカルの待ち受けポートが存在することを確認します。次に、システムプロキシのアドレスとポートがクライアントの設定と一致しているか確認してください。その後、ブラウザー独自のプロキシ設定や拡張機能のルール、直接接続の例外設定を確認します。システムプロキシを参照しないアプリもあります。ブラウザーを完全に終了して再起動し、同じテストURLへのアクセスをクライアントのログと照合する方法もあります。他のネットワークツールがシステムプロキシを繰り返し書き換える場合は、競合するツールを終了してから設定してください。システムプロキシが担うのは入口までで、実際にプロキシ経由になるかはコアのルーティングルールによって決まります。

まずTUNを無効にし、ログを読んで、権限、仮想インターフェースの作成、ルートの追加のどこで失敗しているか確認してください。Windowsでは通常、管理者権限が必要です。macOSとLinuxでは、使用中のクライアントのバージョンに応じた案内に従って、権限付与やサービス設定を行います。すべてのエラーを権限不足と決めつけないでください。Androidで初めて接続する場合は、システムのVPN許可と、ほかのアプリがVPN接続を使用していないかを確認します。許可後も失敗する場合は、必要なコンポーネントが揃っているか、セキュリティソフトがブロックしていないかを確認してください。権限の問題をサブスクリプションの無効化と誤認しないよう、一時的にシステムプロキシへ切り替えてノードを検証しましょう。

TCPingで分かるのは主にサーバーポートへのTCP接続状況で、認証やトランスポートのハンドシェイク、宛先へのリクエストが成功することまでは確認できません。実際の接続遅延はノード経由でテスト先にリクエストを送り、実際の利用経路に近い結果を測定しますが、テスト先への到達性、ルーティング、ネットワーク負荷にも左右されます。まずテスト先と測定設定を揃えてからノードを比較してください。一度だけ低い数値が出ても、安定した速度とは限りません。TCPingは成功するのに実際の接続遅延が失敗する場合は、サーバーポートだけでなく、プロトコルの設定、TLSハンドシェイク、テスト先も確認しましょう。

該当するサブスクリプショングループに切り替えて更新結果を確認し、サーバー一覧で現在選択されている項目を確かめてください。更新によってノード名、アドレス、並び順が変わることがあるため、以前と同じ行にあることを識別の目印にしないでください。使うサーバーを選んでアクティブにし、ログで設定が再読み込みされたか確認します。必要に応じて接続を停止してから再起動してください。サブスクリプション内のノードを手動で変更しても、次回更新で変更が上書きされることがあります。カスタム設定を長期保存する場合は、別の設定として保存し、どこで管理するものか明確に分けてください。

まずテストするドメインを1つ決め、想定したルールに一致するか、そのルールが指定する出力タグが存在するか確認してください。ルーティングは通常、上から順に照合されます。広い範囲を対象にするルールが先にあると、後続の詳細なルールに一致しないことがあります。ドメイン解決ポリシーのAsIs、IPIfNonMatch、IPOnDemandは、照合時に名前解決を行うかどうかや、IPベースのルール判定に影響します。ログに記録された宛先と出力先を確認し、ブラウザーでページが開くかどうかだけで判断しないでください。設定を変更したら再読み込みし、新しいリクエストでテストします。既存の長時間接続は、変更前の経路を使い続けることがあります。

まずプロキシを有効にする前にテストページに表示される外部IPを記録し、次にプロキシを有効にして同じページへアクセスします。クライアントのログに記録されたリクエストと出力先も照合してください。テスト先がプロキシ経由になる想定のルールに含まれているか確認しましょう。対象外なら、IPが変わらなくても通常の直接接続である可能性があります。ブラウザーの結果から分かるのは、そのブラウザーの通信経路だけで、すべてのアプリが接続されているとは限りません。結果が想定と異なる場合は、システムプロキシ、アプリ独自のプロキシ、ルーティング、TUNの状態を順に確認します。設定変更後は新しいタブか新しい接続で再テストし、キャッシュや既存の接続の影響を避けてください。

まず現在のエラー情報を残し、同じネットワークで、利用できることが分かっている別のノードを試してください。特定ノードだけの問題か、端末全体の通信経路の問題かを切り分けられます。1つのノードだけ失敗する場合は、アドレス、ポート、認証パラメーター、サービス状況を確認します。すべてのノードが失敗する場合は、端末のネットワーク、DNS、ファイアウォール、現在選択されているコアを確認してください。先にポートをテストしてから実際の接続遅延を測ると、原因を絞り込みやすくなります。ただし、ポートに接続できてもプロトコルが使えるとは限りません。ポート、トランスポート、セキュリティ設定を一度に変更しないでください。設定は1項目ずつ変更して再テストし、元に戻せるよう変更前の設定も残しておきましょう。

まずシステムプロキシとTUNを無効にし、通常のネットワークでこれまでアクセスできていたサイトが開くか確認してください。通常のネットワークに問題がある場合は、先にネットワークを修復します。次にコアを起動して、起動失敗や待ち受けエラーがないか確認し、アクティブノードの実際の接続遅延をテストします。ノードのテストに成功したら、通信を取り込む方法を1つだけ有効にし、アプリのリクエストがログに記録されるか確認します。リクエストが記録されるのに宛先へアクセスできない場合は、ルーティング、DNS、対象サイトの状態を確認してください。接続アイコンが示すのは稼働状態にすぎず、すべてのリクエストの成功を保証するものではありません。最初から設定をすべて削除せず、最小限の設定で問題を再現しましょう。

まず、コアの起動段階と接続段階を切り分けます。コアの起動に失敗した場合は、最初に記録されたエラー行を確認し、ポートの競合、JSONの構文、未知の設定項目、選択したコアが対応していないプロトコルがないか調べてください。終了時の最後の行だけを見るのでは不十分です。接続段階でTLSやx509のエラーが出た場合は、まずシステムの日付とタイムゾーンを合わせ、SNI、証明書のドメイン名、提供元が指定するセキュリティ設定を確認します。証明書検証を無効にする方法を常用の対処法にしないでください。ログを共有する必要がある場合は、該当する時間帯だけを抜き出し、アドレス、ユーザー情報、サブスクリプションのパラメーターを隠しつつ、エラーのキーワードは残してください。