v2rayNの日常的な操作は、サブスクリプションの整理、使用するサーバーの選択、システムプロキシまたはTUNによる通信の取り込み、ログでのコアとルーティングの確認という4つに分けられます。クライアントを起動したものの、一覧での選択と実際の有効化の違いが分からない方に向けて、サブスクリプションの更新から接続問題の切り分けまで、基本的な確認手順を解説します。
まずは4つのエリアを確認：一覧・グループ・ログ・実行状態
先に結論をお伝えすると、サーバー一覧に項目があってもコアが正常に動作しているとは限りません。また、コアが正常でもブラウザーがプロキシを使用しているとは限りません。メイン画面には異なる段階の状態が表示されるため、接続状況を判断するには、遅延の数値だけでなく、複数の情報を組み合わせて確認してください。
以下では、デスクトップ版の中国語UIで一般的なメニュー名を使って説明します。バージョンやOS、ウィンドウ幅によってメニューの位置が変わったり、ログ欄が折りたたまれていたりする場合があります。表示名が異なる場合は機能名を手掛かりに探し、ボタンの位置だけを固定の操作手順と考えないようにしてください。
| エリア | 主な用途 | 確認する状態 |
|---|---|---|
| サーバー一覧 | ノードの確認、接続テスト、使用サーバーの切り替え | 選択中の行ではなく、現在有効な項目 |
| サブスクリプショングループ | サブスクリプションごとにノードを管理・更新・絞り込み | 現在のグループや検索条件によって、他のノードが非表示になっていないか |
| ログウィンドウ | 起動、リスニング、接続、エラー情報の確認 | 操作した時刻と、最初に現れた関連エラー |
| ステータス欄と設定メニュー | システムプロキシ、ルーティング、TUN、実行パラメーターの調整 | 通信の取り込み方法と現在のルーティング設定 |
サーバー一覧：選択・有効化・右クリックメニューの違い
行をクリックすると、通常は項目が選択され、編集、コピー、テスト、削除などの操作ができるようになります。実際に使用するサーバーを切り替えるには、右クリックメニューから「アクティブサーバーに設定」を選び、アクティブ状態の表示と画面下部のログを確認します。バージョンによってはダブルクリックでも切り替えられますが、初めて使う場合は右クリックメニューのほうが操作内容を確認しやすいでしょう。
一覧の備考はノードの識別に使います。アドレスとポートはサーバー側の接続先、VMessやVLESSなどのプロトコルは接続方式を示しますが、それだけで通信速度は判断できません。トランスポートやセキュリティの設定もサーバー側と一致させる必要があります。備考の変更は通常接続に影響しませんが、アドレス、ポート、TLS関連の設定を変えると、ハンドシェイクに失敗することがあります。
- 編集：ノードを1つ選択し、右クリックメニューから編集画面を開きます。プロトコル、サーバーポート、トランスポート設定を確認するときは、元に戻せるよう元の設定を残しておきましょう。
- テスト：メニューで選べるのが接続遅延なのか、実際の接続遅延なのかを確認してから結果を見ます。テスト方法によって対象や手順が異なるため、2種類の数値を同じ指標として比較しないでください。
- 共有リンクをコピー：単一ノードの移行に使います。通常、クライアントのルーティングやDNS設定全体は含まれません。共有リンクには認証情報が含まれる場合があるため、公開の掲示板などには貼り付けないでください。
- 削除：削除対象の範囲を確認してから実行します。サブスクリプション由来のノードは手動で削除しても、次回更新時に再表示されることがあります。特定の配信元を継続して無効にする場合は、サブスクリプショングループの管理画面で設定してください。
サブスクリプショングループ：配信元の更新と一覧の絞り込みは別の操作
サブスクリプショングループには、配信元の管理と表示内容の絞り込みという2つの役割がありますが、分けて考える必要があります。グループを切り替えると表示されるノードが変わりますが、アクティブサーバーが自動で切り替わるわけではありません。サブスクリプションを更新すると配信元の内容を再取得し、ノード設定の追加、削除、上書きが行われる場合があります。
-
グループ設定を開く
メイン画面の「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、グループの備考とURLを確認します。サブスクリプションURLには通常アクセストークンが含まれるため、信頼できる配信元から取得した完全なリンクだけを保存してください。
-
サブスクリプションを更新
「サブスクリプショングループ」メニューに戻り、「現在のサブスクリプションを更新（プロキシを使用しない）」を選んで対象グループを更新します。配信元へのアクセスにプロキシが必要だと明確に分かっている場合は、利用可能な接続を確立したうえで「プロキシ経由」に対応する更新項目を使ってください。
-
表示の絞り込みを解除
すべてのノードが表示されるグループ表示に切り替え、検索ボックスを空にします。更新ログが成功を示しているのに一覧が空の場合は、すぐに再インポートせず、グループとキーワードによる絞り込みが重なっていないか確認してください。
-
アクティブ項目を再確認
更新後のサーバー一覧から対象を選び、右クリックして「アクティブサーバーに設定」を選択します。その後、ログで設定の読み込み結果を確認し、更新前の別ノードを使い続けていないか確かめてください。
日常の管理では、似たような地域名をグループごとに付けるのではなく、配信元が分かる名前を付けるのがおすすめです。同じ配信元に複数の地域が含まれる場合も、同じ地域のノードが複数の配信元から提供される場合もあります。配信元が分かる備考を付けておくと、どのサブスクリプションを更新したのか把握しやすくなります。サブスクリプションのノードを手動で変更する場合は、次回更新で上書きされる可能性も考慮してください。継続して使う変更は別途バックアップしておきましょう。
システムプロキシ・ルーティング・TUN：3つの設定が制御するもの
システムプロキシは、システム設定に従うアプリのリクエストをどこへ送るかを決めます。TUNは仮想ネットワークインターフェースを使い、設定条件に合う通信を取り込みます。ルーティングルールは、コアに届いたリクエストをプロキシ、直接接続、ブロックのどれにするかを決めます。これらは別々の設定であり、すべて有効にすれば必ず安定するというものではありません。
まずはシステムプロキシ
おすすめWindowsのメイン画面でシステムプロキシメニューを開き、「システムプロキシを自動設定」を選択します。その後、システムプロキシに従うブラウザーで動作を確認してください。通信の取り込み範囲を把握しやすく、まず確認可能な状態を作るのに適しています。
おすすめの用途：初期設定、ブラウザーでのアクセス、基本的な接続確認。
必要に応じてTUNを有効化
システムプロキシに従わないアプリの通信も扱う必要がある場合に、TUNの利用を検討します。有効化する前に、使用中のプラットフォームで必要な権限を確認し、仮想ネットワークアダプター、DNS、ルートの作成に関するログを確認してください。通信の取り込み範囲は実際の設定によって異なります。
おすすめの用途：アプリがシステムプロキシを無視する場合、通信をまとめて取り込みたい場合。
プロキシを手動設定
プロキシ設定に対応したアプリに、ローカルアドレス、ポート、プロキシの種類を指定します。特定のアプリだけを個別に確認するのに便利ですが、アプリ内の設定がシステムプロキシより優先される場合があります。元に戻す方法も記録しておきましょう。
おすすめの用途：コマンドラインツール、単独のアプリ、個別の問題切り分け。
ルーティング設定を切り替えたら、新しい設定が読み込まれたことを確認してください。直接接続ルールに一致したリクエストがプロキシを経由しないのは想定どおりの動作であり、すぐにノードの障害と判断する必要はありません。ルールの順序やアウトバウンドの意味を確認したい場合は使い方ガイドを、複雑な通信取り込みの問題は詳しいトラブルシューティングを参照してください。
ログウィンドウ：時刻・レベル・接続段階を確認
ログは「状況が分かる操作を1回行い、その後の記録を読む」と把握しやすくなります。たとえば、現在の時刻を確認してからアクティブサーバーを設定し、対象へ1回だけアクセスします。こうすれば起動時の失敗とアクセス時の失敗を分けられ、過去の大量のログから関連しそうな単語を探し回らずに済みます。
画面側のログにはサブスクリプションの更新結果が含まれることがあり、コアの出力には設定の読み込み、リスニング、接続に関する情報が主に記録されます。すべてのバージョンでアクセスの詳細が標準表示されるわけではありません。ログレベルが高いと特定のリクエストが表示されないことがありますが、記録がないからといってリクエストが発生していないとは限りません。必要なときだけ一時的に詳細度を上げて問題を再現し、デバッグ出力を常時残さないようにしましょう。
| ログの内容 | 主な段階 | 次に確認すること |
|---|---|---|
address already in use | ローカルリスナーの起動 | ローカルポートが別のプロセスに使用されていないか、クライアントを二重に起動していないか確認する |
failed to load config | 設定の読み込み | 続く具体的なエラーを確認し、カスタム設定や項目の互換性を調べる |
timeout | 接続またはリクエストの待機 | 接続先のアドレスを手掛かりに、サーバー接続、DNS、接続先へのアクセスのどこでタイムアウトしているか確認する |
certificate | TLS検証 | システム時刻、サーバー証明書、TLSのサーバー名設定を確認する |
設定：まずリスニングポートとコアを確認
「設定」→「パラメーター設定」を開いたら、まず現在の値を記録し、一度に1項目だけ変更します。日常の接続に影響しやすいのは、ローカルリスニング、コアの選択、DNS、起動時の動作であり、画面テーマではありません。コア関連の設定はバージョンによって「Coreタイプ」または独立したコア設定ページにあります。ノードのプロトコルと、使用中のコアが対応しているかを基準に選んでください。
上記はローカルプロキシアドレスの説明であり、サーバーノードの設定ではありません。アプリに設定するローカルプロキシは127.0.0.1:10808のように指定できますが、接続先のリスナーがアプリで選んだHTTPまたはSOCKSの種類に対応していることを確認してください。新旧バージョンではポート構成が異なる場合があります。古い解説を根拠に、別のポートも必ず存在すると考えないでください。
- リスニングポート：パラメーター設定の基本設定でローカルのリスニング値を確認します。変更した場合は、プロキシを手動設定しているアプリの値も更新し、システムプロキシが反映されているか確認してください。
- LANからの接続：他のデバイスから接続する必要がある場合にのみ有効にしてください。他のデバイスからこのPCの
127.0.0.1には接続できません。PCのLANアドレスを使い、ファイアウォールとアクセス範囲も確認してください。 - Coreタイプ：VLESSやVMessはプロトコル、XrayやV2Rayはコア、v2rayNはクライアントです。コアを切り替えてもノードが切り替わるわけではなく、互換性のないサーバー設定が自動で使えるようになるわけでもありません。
- DNS：まずシステムプロキシとTUNのどちらを使っているか確認し、次にドメイン名の名前解決経路を調べます。問題箇所が分からないうちに、DNS、ノード、ルーティングを同時に変更しないでください。
- 起動時の動作：OS起動時に起動する、起動後に最小化する、システムプロキシを自動設定する、はそれぞれ別の項目です。1つを有効にしても、ほかの項目が自動で有効になるわけではありません。
設定を保存したら、ログで再読み込みが正常に完了したか確認し、メイン画面に戻ってアクティブサーバーとプロキシの状態を確認します。問題が起きた場合は、サブスクリプション全体を再インポートするより、直前に変更した項目を元に戻すほうが原因を特定しやすくなります。
v2rayNのメイン画面でよくある疑問：最短手順で問題を切り分ける
ノードをクリックしたのに、接続元が変わらないのはなぜ？
該当行を右クリックして「アクティブサーバーに設定」を選び、アクティブ表示が切り替わったことを確認してから、ログで設定の読み込み結果を確認してください。アクティブ項目が切り替わっている場合は、接続先が直接接続ルールに一致していないか、ブラウザー独自のプロキシ設定が使われていないかも確認します。行を選択しただけでは、実際の接続先が変わらない場合があります。
サブスクリプションの更新は成功したのに、ノードが表示されないのはなぜ？
まず検索ボックスを空にし、すべてのノードが表示されるビューに切り替えます。それでも空の場合は、「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、更新した配信元と現在のグループが一致しているか確認します。ログでURLへのアクセスだけでなく、ノードの解析まで完了しているかも確認してください。
ログが流れ続けている場合、どの部分をコピーすればいい？
繰り返しテストを止め、時刻を記録してから、切り替えまたはアクセスを1回だけ行います。その操作の開始から最初の関連エラーまで、該当時刻の前後のログをコピーしてください。起動に失敗する場合は、リスニングまたは設定読み込みの部分を優先し、アクセス履歴全体を送る必要はありません。
クライアントを終了した後、ブラウザーがネットに接続できないのはなぜ？
システムの接続先が、すでに停止したローカルプロキシのままになっていないか確認してください。v2rayNを再起動できる場合は、システムプロキシメニューから「システムプロキシを解除」を選んでから終了します。ブラウザーやほかのアプリに手動プロキシが個別設定されていないかも確認してください。
日常の確認手順を、グループとアクティブサーバーの確認、ローカルリスナーの確認、アプリの通信取り込み方法の確認、今回のアクセスに対応するルーティングとエラーログの確認、の順に固定すると効率的です。「ノードが使えない」「アプリがプロキシを通っていない」「ルールで直接接続が選ばれている」を別々の問題として切り分けられ、根拠のない設定変更を減らせます。