v2rayNの使い方：サブスクリプション追加から接続確認まで

初回設定では確認しやすい組み合わせを使う

初回は「システムプロキシ + ルール分岐」の組み合わせがおすすめです。システムプロキシを使うと、OSのプロキシ設定に従うアプリの通信をv2rayNへ渡せます。ルール分岐では、ドメイン、アドレス、あらかじめ用意されたルールに応じて通信先を決めます。影響範囲が分かりやすく、ブラウザーでそのまま確認でき、問題発生時にシステムプロキシが有効かどうかも確認しやすい組み合わせです。

「グローバル」は通常、取り込まれた通信の大部分を現在のノード経由にする設定です。「ルール」はルーティングルールで直接接続とプロキシを分け、「直接接続」はプロキシを経由せずにリクエストを送ります。バージョンによっては「グローバル」「LANと中国本土のアドレスをバイパス」「システムプロキシを解除」など、似た名称が使われます。ここで全ルールを詳しく調べる必要はありません。まずクライアントに用意されている一般的なルールモードを選び、システムプロキシが無効になっていないことを確認してください。

v2rayNデスクトップ版の設定

v2rayNのメインウィンドウ下部のステータスバーまたはシステムトレイメニューから「システムプロキシ」を探し、システムプロキシの自動設定またはシステムプロキシの設定を選びます。設定後、ステータスバーの表示が未有効から設定済みへ切り替わることを確認します。続いて「ルーティング」または「ルーティング設定」を開き、用意されているルール分岐の方式を選択します。保存してメインウィンドウに戻り、下部に現在のシステムプロキシ状態とルーティングモードが同時に表示されることを確認してください。

プロキシ設定に対応した特定のアプリだけでクライアントを使う場合は、システムプロキシを無効のままにして、アプリ側でローカルプロキシポートを手動入力する方法もあります。ただし、プロトコルの種類と待ち受けポートを別途確認する必要があるため、初回の手順としてはおすすめしません。このガイドではまずシステムプロキシで接続経路全体を確認し、正常に動作してからアプリごとの設定を検討します。

v2rayNG Android版の設定

v2rayNGは接続時にシステムのネットワーク接続設定を通じて通信を取り込むため、デスクトップ版とまったく同じ「システムプロキシの設定」ボタンはありません。設定またはルーティング設定を開き、クライアントに用意されているルールモードを選択してください。初回はほかの高度なパラメーターを初期値のままにし、ローカルDNS、アプリごとのプロキシ、トラフィック検出、下位トランスポートの項目を同時に変更しないでください。失敗した場合、どの変更が原因か分かりにくくなります。

接続ボタンをタップすると、システムからネットワーク接続の許可を求められる場合があります。アプリ名に間違いがないことを確認して接続を許可してください。通常、この許可画面が表示されるのは初回またはシステム設定が変わった後です。許可が完了しても、ノードが利用可能とは限りません。許可されるのはクライアントが本機の通信取り込み用トンネルを確立することだけで、実際の接続状態は次の手順でボタンの状態と実行ログを確認する必要があります。

TUNモードを検討するタイミング

一部のデスクトップアプリはシステムプロキシを読み込みません。ゲームランチャー、コマンドラインツール、独自のネットワークスタックを使うソフトウェアも、システムプロキシを迂回する場合があります。その場合は、クライアントがより低いレイヤーで通信を取り込むTUNモードを検討できます。ただしTUNには、仮想ネットワークインターフェース、DNS処理、管理者権限、ルーティングの優先順位が関係します。基本接続を確認できていない段階で有効にするのは適切ではありません。

まずシステムプロキシでサブスクリプションとノードが動作することを確認し、その後も特定のアプリを取り込めない場合にTUNへの切り替えを検討するのが正しい順序です。TUN、DNS、プラットフォーム固有の設定については完全なドキュメントをご覧ください。本ページでは基本モードのまま、ノードの選択と接続へ進みます。

新しいブラウザーウィンドウでテスト

クライアントの接続状態を維持し、事前確認に使った古いページを閉じて、新しいブラウザーウィンドウを開きます。まず普段直接アクセスできるサイトを開き、プロキシ設定によって基本ネットワークが途切れていないことを確認します。その後、現在のノードで処理したい対象サイトへアクセスします。新しいウィンドウを使うと、古い接続、キャッシュ、開いていたページのバックグラウンドリクエストが判定に与える影響を減らせます。

どちらの種類のサイトも正常に開き、アクセス時にクライアントのログへ新しい接続記録が追加されるなら、サブスクリプション、アクティブノード、プロキシモード、アプリの取り込みが一連の経路として機能しています。この時点でプロトコルパラメーターを調整し続ける必要はありません。現在のノードを普段使いのサーバーとして残し、必要なときにサブスクリプションを更新してください。

リクエストがクライアントに入ったかログで確認

Webページを開けない場合は、まず更新をクリックした後にログへ新しい記録が出るか確認します。ログがまったく変化しないなら、問題はアプリの取り込み段階にある可能性が高くなります。デスクトップではシステムプロキシが有効なままか確認し、Androidではクライアントの接続が動作中か確認します。ブラウザーを完全に終了してから開き直し、接続前に作られたセッションを使い続けないようにする方法もあります。

ログに対象ドメインや接続リクエストが出た後、タイムアウト、リモート拒否、ハンドシェイク失敗が続く場合、通信はクライアントに入っています。確認の重点をノードの状態、サブスクリプションの新旧、プロトコルパラメーターへ移します。まず既存のサブスクリプションを更新し、同じグループ内の別のノードに切り替えます。一度に1つの条件だけを変更すると、テスト結果を比較できます。

一部のサイトは正常で一部だけ失敗する場合、基本接続は成立しており、ルーティングルール、DNS解決、対象サービス自体の違いが原因と考えられます。この段階でクライアントを再インストールしたり、すべてのサブスクリプションを削除したりする必要はありません。失敗したサイト、現在のルーティングモード、ログの該当行を記録し、トラブル対応で障害の種類に沿って確認を続けてください。

失敗したときは決まった順番で確認

1. 基本ネットワークを確認：クライアントを一時的に切断し、通常のWebページへアクセスできるか確認します。基本ネットワークに異常がある場合は、本機のネットワーク接続を先に復旧します。
2. 既存のサブスクリプションを更新：グループを新しく作り直さず、現在のグループを直接更新して、サーバー一覧にノードが残っていることを確認します。
3. 別のノードに変更：プロキシモードは変えず、アクティブサーバーだけを切り替えて、同じサイトでもう一度テストします。
4. 取り込み状態を確認：デスクトップではシステムプロキシ、Androidでは実行中の接続を確認し、アプリの通信が実際にクライアントへ入っていることを確かめます。
5. 最新ログを読む：今回の接続後に記録された内容だけを確認し、タイムアウト、名前解決、ポート、設定に関する表示に応じて次の確認項目を選びます。

この順番で外側から内側へ段階的に問題を切り分けると、複数の設定を同時に変更せずに済みます。どこかの手順で正常に戻ったら、追加の変更を止めて再確認してください。本機の時刻、ポート競合、DNS、TUN、複雑なルーティングを確認する必要がある場合は、完全なドキュメントの該当章を参照します。