v2rayN メイン画面の機能を俯瞰：サーバー一覧・購読グループ・ログ・設定への入口

初めて v2rayN を開くと、メイン画面にボタン、サーバー行、グループタブ、スクロールするログが一度に表示されます。情報量は多く見えますが、実際の操作手順は複雑ではありません。メイン画面は5つの層に分けて考えると分かりやすくなります。上部のコマンドエリアは操作を開始し、購読・グループエリアは対象を絞り、サーバー一覧は設定を選択し、ログペインは実行結果を示し、下部のステータスエリアは現在のプロキシ状態を確認します。

バージョンやデスクトップ環境、ウィンドウ幅によってボタンの並び方が変わり、表示文言にも多少の違いが出ることがあります。ただし基本的な関係は共通です。購読からサーバー設定が生成され、その設定が Xray コアに渡され、コアがローカルのインバウンドポートを開いてルーティング規則に従ってトラフィックを転送します。その後、システムプロキシまたは TUN モードによって、どのアプリの通信をこれらのポートへ送るかが決まります。この流れを理解すれば、画面上のほとんどの入口を迷わず見つけられます。

上から順にメイン画面の構成を把握する

メイン画面の上部には、通常メニューバーとショートカットコマンドがあります。メニューバーにはすべての機能が収まり、ショートカットにはサーバー追加、購読更新、サーバーテスト、アクティブサーバーの設定、設定画面の表示など、頻繁に使う操作が並びます。ウィンドウが狭い場合、一部のボタンが「その他」メニューに入ることがあります。アイコンが見つからないときは、機能が削除されたと判断する前に、該当メニューを展開してみてください。

中央のエリアがサーバー管理の中心です。通常は、購読グループの選択、検索または絞り込みの入口、そして最も大きな面積を占めるサーバーテーブルで構成されます。各行は、コアが利用できる1つのアウトバウンド設定を表します。設定の取得元には、手動追加、共有リンクからのインポート、クリップボードからの一括インポート、購読更新などがあります。VMess、VLESS など複数のプロトコルを同じ一覧に表示できますが、各行はそれぞれ独立したアドレス、ポート、トランスポート、安全設定を保持しています。

サーバー一覧の下には、通常ログペインがあります。ログは飾りではなく、「操作が成功したか」を判断する最初の証拠です。購読の更新、コアの起動、サーバーの切り替え、システムプロキシの有効化、接続の確立を行うと、関連する結果がここに表示されます。画面最下部のステータスエリアでは、アクティブな設定、ローカルポート、プロキシモード、コアの稼働状態をすばやく確認できます。

普段の確認は、視線の順番を固定すると効率的です。まず現在のグループ、次にアクティブサーバー、その後にプロキシモード、最後にログに連続したエラーがないかを確認します。設定画面を何度も開くより速く、「一覧にノードがある」ことと「通信がノード経由になっている」ことを取り違えるのも防げます。

上部メニューとショートカットコマンドの役割

サーバーコマンド：個別の設定を管理する

サーバー関連のメニューでは、1行または複数行の設定を扱います。よく使う操作は、手動追加、クリップボードからのインポート、編集、複製、削除、遅延テスト、アクティブサーバーへの設定です。編集画面はプロトコルパラメータの確認に便利ですが、購読から生成された設定を長期的に手動編集するのはおすすめしません。次回の購読更新で、サーバーから配信された内容がその行を上書きする可能性があるためです。

VLESS の設定を手動編集する場合、アドレス、ポート、ユーザー識別子、トランスポート方式、安全レイヤー、SNI、フィンガープリント、flow などの項目をサーバー側と一致させる必要があります。VMess でも、ユーザー識別子、alterId または互換パラメータ、トランスポート、TLS 設定を合わせなければなりません。重要な項目に少しでも違いがあると、サーバー名が正常に見えても有効な接続は確立できません。

購読コマンド：設定を一括生成・更新する

購読の入口では、遠隔で管理されるサーバー記録のまとまりを扱います。一般的な流れは、まず購読URLを追加し、その後に更新を実行することです。v2rayN が内容を取得して解析すると、認識できた記録が対応する購読グループに追加されます。更新に成功したからといって、すべてのノードが利用できるとは限りません。取得と変換が完了したことを示すだけで、ノードの接続性は別途テストする必要があります。

一覧に同じ名前のサーバーが大量に現れても、すぐに1行ずつ削除しないでください。まず同じ購読を重複して追加していないか、または1つの購読を複数グループに入れていないか確認します。一括管理では、次回更新後に重複が再発しないよう、先に購読設定で取得元を整理するのが効果的です。

テストコマンド：接続性・遅延・実効速度を分けて考える

テストメニューには複数の結果が表示されることがありますが、同じ指標として扱ってはいけません。ポート接続テストで分かるのは、対象のアドレスとポートに基本接続できるかどうかです。実際の遅延は通常、プロキシ経由で指定されたテスト先へリクエストして測定します。ダウンロード速度は、テスト用リソース、回線の混雑、本機のネットワーク環境にも左右されます。ある行の遅延が低くても、大容量ファイルの転送が速いとは限らず、すべてのサイトへの経路が同じとも限りません。

サーバー一覧の各列の見方

サーバー一覧はメイン画面の中心ですが、最初からすべての列を確認する必要はありません。初めて使う場合は、別名、アドレス、ポート、プロトコル、トランスポート、安全レイヤー、購読グループ、テスト結果を押さえれば十分です。その他の列は詳しい診断に使うため、初回から項目ごとに調整する必要はありません。

別名とアクティブ表示

別名はローカルで表示する名前で、地域、回線、用途を見分けるために使います。ネットワークのハンドシェイクには関与しません。アクティブ表示は現在選択されている出口設定を示すもので、この2つを混同しないでください。別名を変更しても接続パラメータは変わりませんが、購読を更新すると名前が購読内容に合わせて変わることがあります。

アドレスとポート

アドレスはサーバーのドメイン名またはネットワークアドレス、ポートはサーバー側の待受入口です。この2つによって、クライアントが最初に接続する先が決まります。ログに接続タイムアウトや接続拒否が繰り返し表示される場合は、ルーティング規則を変更する前に、本機のネットワーク、名前解決、アドレス、ポートを確認してください。ルーティング規則はトラフィックをどのアウトバウンドへ渡すかを決めるもので、到達できないサーバー入口を修復することはできません。

プロトコル・トランスポート・安全設定

プロトコル欄には VMess または VLESS が表示されることがよくあります。トランスポート欄には TCP、WebSocket、gRPC などが表示され、安全関連の欄には TLS、REALITY、その他バージョンに対応した設定が表示される場合があります。これらの項目が接続条件を構成するため、プロトコル名だけを見てはいけません。どちらも VLESS を使っていても、トランスポート、安全レイヤー、flow が異なればパラメータを流用できません。

一覧をコンパクトに保つため、表示されるのは概要の一部だけであることが多いです。SNI、Host、パス、サービス名、フィンガープリントを確認する場合は、編集画面を開いて完全な設定を確認してください。照合するときはサーバー側から提供された情報を基準にし、ノード名からパラメータを推測しないでください。

購読グループとテスト結果

購読グループ欄は、その行がどの取得元によって管理されているかを示します。重複ノードや一括更新の問題を特定するのに役立ちます。テスト結果欄には、遅延値、失敗メッセージ、空欄などが表示されます。空欄は通常、該当するテストをまだ実行していないことを示し、ノードの無効を直接意味するものではありません。失敗した場合も、テスト先に到達できないのか、サーバーがタイムアウトしたのか、プロトコルのハンドシェイクに失敗したのかをログと照らし合わせて判断します。

購読グループの整理と更新方法

サーバー数が少ないうちは、1つの一覧で十分です。購読元が増えたら、グループ分けによってメイン画面の見やすさを保ちます。頻繁に一時的な遅延値で名前を変えるのではなく、取得元や用途でグループを分けるのがおすすめです。取得元ごとのグループなら更新の管理元を把握しやすく、用途は分かりやすく固定した別名で補足できます。

1. まず購読設定で各URLに分かりやすい名前を付け、識別しにくい長いURLだけを残さないようにします。
2. 新しい購読を1件だけ更新し、解析結果とサーバー数を確認してから、すべての購読を更新します。
3. メイン画面で対応するグループに切り替え、プロトコル、アドレス、別名が想定どおりか確認します。
4. 少数のサーバーで実際の遅延を測定し、毎回すべての記録で速度テストを行う必要はありません。
5. 利用できることを確認した設定をアクティブサーバーに設定し、ステータスエリアとログを確認します。

購読更新後にサーバー数が0になった場合、購読URLにアクセスできない、返却内容が空、内容形式を認識できない、購読権限が変更された、といった原因が考えられます。まず購読更新のログを確認してください。ログにネットワーク要求の失敗が明確に出ていれば、問題は取得段階にあります。要求は成功したのに設定が生成されない場合は、返却内容と解析結果を確認します。

購読ノードは、購読機能に継続して管理させるのが適しています。特定のパラメータを長期保存したい場合は、独立した手動設定を作成し、分かりやすい別名で区別してください。そうしないと、次回の更新で購読元の値に戻り、変更したパス、SNI、ポートなどが消える可能性があります。

グループによる絞り込みは、現在表示されている行にだけ影響し、コアのルーティング規則は変えません。ルーティングにおける「グループ」は、通常ルールセット、アウトバウンドタグ、ドメイン分類などを指し、メイン画面の購読グループとは別の概念です。前者は接続経路を決め、後者は主にサーバー設定を管理します。

ログペインを正しく読む順番

ログは最後の1行だけでなく、操作を行った時点から読み始めます。正常な起動では通常、設定生成、コア起動、ローカルのインバウンドポート待受などの段階が含まれます。その後、アプリの通信がプロキシに入ると、接続先、ルーティングの判断、失敗原因などが表示されます。バージョンによって出力形式は変わりますが、「動作・対象・結果」の順に読む方法は共通です。

まずコアが起動しているか確認する

アクティブサーバーを切り替えた直後にログへ設定エラーが表示される場合、コアがまだ待受段階に入っていない可能性があります。この状態では、システムプロキシが設定済みでも、通信をローカルポート経由で転送できません。該当するサーバー設定を開き、必須項目、ポート形式、トランスポートパラメータ、安全パラメータを確認してください。

次にローカルポートが待ち受けているか確認する

コアが起動すると、本機に SOCKS、HTTP、または混合インバウンドポートが作成されます。ポート番号は設定によって異なります。ログにポート使用中と表示される場合、別の v2rayN プロセス、他のローカルネットワークプログラム、または前回の異常終了後に残ったプロセスがポートを使用している可能性があります。まず重複プロセスを確認し、その後にローカルポートの変更を検討してください。

最後にリモート接続とルーティングを確認する

接続タイムアウトは、対象サーバーに到達できない、ネットワーク経路が妨げられている、名前解決に失敗しているといった状態を示すことが多いです。接続拒否は、対象ホストには到達できるものの、該当ポートが接続を受け付けていないことを示します。ハンドシェイクや認証のエラーは、プロトコル、安全レイヤー、時刻、サーバー側パラメータの不一致を示す可能性が高いです。特定のサイトだけ異常で他の要求が正常なら、DNS とルーティング規則を確認し、サーバー全体が無効だとすぐに判断しないでください。

ログをトラブル対応のために共有する前に、サーバーアドレス、ユーザー識別子、購読URL、その他のアカウント情報を削除してください。ログレベルを常に最も詳細な状態にしておくのも避けましょう。詳細ログは問題の再現に適していますが、普段の運用では標準レベルのほうが重要なエラーを見つけやすくなります。

設定画面にある4つの主要項目

設定画面には多くの項目がありますが、最初はローカルポート、システムプロキシ、コアとルーティング、TUN の4エリアを理解すれば十分です。初回起動後に大量のパラメータを同時に変更しないでください。一度に1項目だけ変更し、変更前の値を記録しておくと、ログ結果を比較できます。

ローカルポート

ローカルポートは、アプリと Xray コアの間にある入口です。ブラウザーや他のプログラムでプロキシを手動設定する場合は、ここに表示された待受アドレスとポートを指定します。システムプロキシモードを有効にすると、v2rayN は対応する情報をデスクトップシステムのプロキシ設定に書き込みます。ポートを変更すると、古いポートを使い続けるアプリはすぐに接続できなくなるため、手動プロキシの設定も合わせて更新してください。

システムプロキシモード

システムプロキシは、デスクトップシステムのプロキシ設定に従うアプリが、リクエストを v2rayN に渡すかどうかを決めます。一般的な状態には、システムプロキシを設定、システムプロキシを解除、システムプロキシを変更しない、などがあります。具体的な名称はバージョンによって多少異なります。「変更しない」はプロキシを有効にする設定ではなく、v2rayN が現在のシステム値を変更しないことを意味します。

システムプロキシを読み取らないアプリもあり、すべてのネットワーク通信が HTTP や SOCKS リクエストというわけでもありません。この場合、システムプロキシが有効なのに対象プログラムが直接接続していても矛盾ではありません。まずそのプログラムがプロキシに対応しているか確認し、プログラム内で手動プロキシを設定するか、TUN モードを使うか判断してください。

コアとルーティング

コア設定では、実行するコンポーネント、ログレベル、DNS などの基本動作を指定します。ルーティング設定では、接続先ごとにプロキシ、直接接続、ブロックのどのアウトバウンドへ振り分けるかを決めます。標準ルールで通常の用途はカバーできるため、使い始めの段階で大量のカスタムルールを重ねるのはおすすめしません。ルールは一致条件に従って実行されるため、範囲が広すぎるドメイン規則やネットワーク規則が後続の項目を先に捕捉することがあります。

ルーティングを変更したら、直接接続を想定した対象とプロキシ接続を想定した対象を分けてテストし、実際のアウトバウンドをログで確認してください。Webページが開くかどうかだけでは、振り分けが想定どおりか判断できません。直接接続とプロキシ接続のどちらでも成功する可能性があり、経路だけが異なるためです。

TUN モード

TUN モードは仮想ネットワークインターフェースを通じて、より広範なシステム通信を取り込みます。システムプロキシを読み取らないアプリにも適しています。一方で、ルーティングテーブル、DNS、権限が関係するため、通常のシステムプロキシよりトラブル対応は複雑です。有効にする前に、通常のプロキシモードでサーバー自体が利用できることを確認してください。そうしないと、ノードの問題と通信取り込みの問題が重なってしまいます。

一連の操作が各エリアをどう通るか

画面の各エリアをつなげると、初回利用時の安定した手順が見えてきます。1つ目は、購読設定で取得元を追加して更新することです。2つ目は、メイン画面で対応するグループに戻り、サーバー行が生成されていることを確認します。3つ目は、1行を選んで実際の遅延テストを実行し、ログと合わせて結果を判断します。4つ目は、利用できることを確認したサーバーをアクティブサーバーに設定します。5つ目は、適切なシステムプロキシ状態を選びます。6つ目は、テスト先へアクセスしながら、ログにリクエストとルーティングの記録が出るか確認します。

5つ目以降で通信が発生しない場合は、購読を追加し直す前に、画面下部のステータスとシステムプロキシを確認してください。ログに通信記録はあるのにリモート接続に失敗するなら、サーバー行に戻ってパラメータを確認するか、別のノードへ切り替えます。特定の対象だけ失敗する場合は、DNS とルーティングを確認します。現象ごとに対応する画面の層があるため、スイッチを無作為に切り替えるより、層ごとに処理するほうが効果的です。

v2rayN を終了する前に、システムプロキシをどう扱うかも確認してください。完全に使用を停止する場合は、プログラムが提供するプロキシコマンドでシステムプロキシを解除してから、通常どおり終了します。バックグラウンドに最小化するだけなら、トレイの稼働状態とアクティブサーバーが正常であることを確認してください。ウィンドウを閉じる動作は設定によって、バックグラウンドに隠す場合もあれば、プログラムを終了する場合もあります。メイン画面が見えるかどうかだけでコアの状態を判断しないでください。

10分で確認するチェックリスト

• 購読グループ名から取得元が分かり、一覧に明らかな重複購読がない。
• アクティブサーバーの表示が明確で、クリックして選択しただけの状態と切り替え済みの状態を混同していない。
• アドレス、ポート、プロトコル、トランスポート、安全レイヤーがサーバー側の設定と一致している。
• 遅延、ポートテスト、速度テストをそれぞれ別の指標として理解し、単一の数値だけで判断していない。
• ログでコアの起動とローカルポートの待受結果を確認できる。
• システムプロキシの状態が用途に合っており、手動プロキシを使うアプリが正しいローカルポートを指定している。
• 通常のプロキシでの検証を終えてから、ルーティングのカスタマイズや TUN による取り込みを検討する。
• 障害が起きたら現在の操作時点からログを読み、設定、ローカルポート、リモート接続、ルーティングの順に確認する。

これらのエリアを把握すると、v2rayN のメイン画面は互いに独立したボタンの集まりではなくなります。購読グループは「設定がどこから来たか」、サーバー一覧は「どの設定を使う準備ができているか」、アクティブ表示は「現在の出口がどれか」、システムプロキシと TUN は「どの通信がコアに入るか」、ログは「リクエストがどの段階で成功または失敗したか」を示します。今後、ルーティング、DNS、高度なトランスポートパラメータを学ぶときも、このメイン画面の地図をそのまま活用できます。