v2rayN 初回接続の手順：ノード選択・実測・プロキシ有効化の確認

v2rayN の初回接続は、ノードをダブルクリックすれば終わりというものではありません。設定をクライアントに取り込み、ノードを現在の出口として指定し、コアを正常に起動し、アプリの通信をローカルプロキシへ通し、遠隔接続が実際に利用できることまで確認する必要があります。どれか一つでも完了していないと、ウェブページが開かない、速度が不安定になる、クライアントは動作しているように見えるのにアクセス経路が変わらない、といった症状が現れます。

そのため、初回設定では決められた順序で操作し、プロトコル、DNS、ルーティング、プロキシモードを同時に変更しないでください。まず再現可能な基本接続を確立し、その後で利用範囲に応じて振り分けルールを調整します。問題が起きたときに、サブスクリプション、ノード、コア、システムプロキシのどの層に原因があるのかを切り分けやすくなり、複数の項目を手当たり次第に試す必要がなくなります。

接続前の準備：クライアント、設定元、システム時刻を確認

デスクトップ環境で v2rayN を使う場合は、まずプログラムが正常に起動し、コアコンポーネントをクライアントから呼び出せることを確認します。v2rayN は設定と実行を管理するインターフェースで、VMess や VLESS などの接続を実際に処理するのは対応するコアです。クライアントの画面が起動したからといって、プロキシのコアまで動作しているとは限りません。ステータスバー、実行ログ、実際のアクセス結果をそれぞれ確認してください。

ノード設定は、信頼でき、現在も保守されているサブスクリプションまたは単一の共有リンクから取得してください。サブスクリプションには通常、複数のサーバー情報が含まれており、一括更新に便利です。単一の共有リンクは一つのノードだけを記述するため、一時的な取り込みや個別テストに向いています。どちらの方法でも、サーバーアドレス、ポート、ユーザー識別子、転送方式、セキュリティ設定、パスなどの必須項目が必要です。項目が欠けていたり誤変換されたりすると、ノード名は一覧に表示されても接続を確立できません。

システムの日付とタイムゾーンを確認：一部の安全な接続では、端末の時刻が正しいことが前提になります。時刻が大きくずれていると、ハンドシェイクに失敗したり、証明書の時刻エラーが発生したりすることがあります。
ルーティングは一時的に初期設定のままにする：初回接続では基本的な出口を確認し、最初から大量のカスタムドメイン、IP、プロセスルールを追加しないでください。
既存のプロキシ状態を記録する：以前から別のローカルプロキシを設定している場合は、先に待ち受けポートと有効・無効の状態を確認し、ポート競合や設定の上書きを避けてください。
二つのテスト対象を用意する：一つは通常のネットワークにアクセスできることを確認するため、もう一つはプロキシ出口の変化を確認するために使い、一つのウェブページだけで判断しないようにします。

サブスクリプションを取り込み、ノードが更新されたことを確認

サブスクリプションアドレスを取り込む順序

v2rayN のサブスクリプショングループまたはサブスクリプション設定で新しいアドレスを追加し、識別しやすいメモを入力して保存した後、更新を実行します。「サブスクリプションを追加」しただけでは、通常ノード一覧は自動生成されません。必ずもう一度サブスクリプション更新を実行してください。更新後は、メイン一覧にノード名、アドレス、ポート、プロトコルなどが表示されるはずです。

サブスクリプショングループに更新方法の選択肢がある場合は、まず通常の更新を使います。内容に特定の変換処理が必要だと明確に分かっている場合だけ、関連する処理オプションを変更してください。誤ってデコードや変換を繰り返すと、有効な VMess や VLESS の共有データから項目が失われることがあります。ネイティブ JSON 設定と共有リンクは同じ構造ではないため、設定形式に合った取り込み入口を選ぶ必要があります。

取り込み後に確認する項目

ノード一覧に新しい項目が追加されているか。空のサブスクリプショングループが一つ増えただけになっていないか。
ノードの所属グループが正しいか。更新時に完了またはエラーの明確なメッセージが表示されたか。
サーバーアドレスとポートが空欄になっていないか。プロトコルの種類が設定元と一致しているか。
同名ノードが重複して取り込まれていないか。現在選択している項目が、更新したばかりのグループに属しているか。
サブスクリプションの更新に失敗したら、まず現在のネットワークからアドレスへアクセスできるか確認し、次にコピー時に空白や改行が混入していないか確認します。

単一の共有リンクの場合は、クリップボードからの取り込みなど、対応する機能を使えます。取り込み後は同じようにノード一覧へ戻って内容を確認してください。「取り込み成功」という表示だけを見て判断してはいけません。この表示で分かるのは、通常、クライアントがテキストを認識できたことだけです。遠隔サーバーがオンラインであることや、ローカルネットワークからそのサーバーへ到達できることまでは示しません。

現在のノードを選択し、遅延結果を正しく理解する

ノードを取り込んだら、そのうち一つを現在のアクティブサーバーに設定します。一般的にはノードをダブルクリックするか、メニューからアクティブサーバーに指定します。設定後、画面上で色、マーク、ステータス文字などにより現在のノードが示されます。一覧の行をクリックするだけでは項目を選択しただけで、実際の出口が変わるとは限りません。「現在のサーバー」の状態が更新されたことを確認してください。

まず基本的な遅延テストを実行

遅延テストは、完全に到達できないノード、名前解決に失敗するノード、ハンドシェイクを完了できないノードを素早く除外するのに役立ちます。数値が小さいほど、通常は端末からテスト対象への応答が速いことを示します。タイムアウトする場合は、ノードの停止、アドレス解決の失敗、ローカルネットワークによる遮断、パラメータの不一致、テスト方式の制限などを考慮します。

遅延の数値をダウンロード速度と直接同一視することはできません。遅延テストで転送するデータ量はごく小さく、主に接続の確立や応答取得にかかる時間を示します。実際のブラウジングやダウンロードには、回線の混雑、パケットロス、サーバー負荷、転送プロトコル、対象サイト、端末側のネットワーク状態も影響します。二つのノードの遅延が近い場合は、一覧の数字だけで並べ替えず、実接続テストを続けてください。

初回のノード選択で役立つ方法

設定項目が揃っており、基本遅延に応答するノードを選びます。
最初からすべての機能をテストせず、一つのノードで基準となる接続を確立します。
ノードがタイムアウトしたら、同じサブスクリプション内の別のノードに切り替えて比較します。
複数のノードがすべてタイムアウトする場合は、プロトコル項目を一つずつ変更するのではなく、サブスクリプション、DNS、端末のネットワーク、コアのログを優先して確認します。
一つのノードだけ失敗し、ほかのノードが正常な場合は、そのノードまたは経路に問題がある可能性が高くなります。

Android を使う場合、v2rayNG は Xray コア、v2flyNG は v2fly コアを使用します。画面操作はデスクトップ版と異なりますが、確認の順序は同じです。設定を取り込み、ノードを選び、接続を開始し、実際にアクセスしてからログを確認します。コアによって一部の拡張パラメータへの対応範囲が異なる場合があるため、設定を移行した後は再確認してください。すべての項目が完全に同等だと決めつけないことが大切です。

プロキシコアを起動し、システムプロキシを設定

ノードを選択したら、v2rayN で対応するコアを起動します。ステータスバーにコアの稼働状態が表示され、ローカルプロキシポートも正常に待ち受けている必要があります。ログにポート競合、設定解析エラー、コアコンポーネントが見つからない、プロセスが直ちに終了したなどの表示がある場合、システムプロキシを有効にしても正常な応答は得られません。

コアの稼働とシステムプロキシは別々の手順です。コアは端末上でプロキシポートを待ち受け、接続を転送します。システムプロキシは、OS の設定に従うアプリへ、このローカルポートに通信を送るよう指示します。コアだけを起動してシステムプロキシを有効にしない場合、ブラウザーなどは直接接続を続けることがあります。システムプロキシだけを設定してコアを起動していない場合、アプリは応答するサービスのないポートへリクエストを送り、すべてのウェブページが開かなくなります。

初回接続ではシステムプロキシを使う

初回確認では、複雑な通信取り込み方式よりもシステムプロキシのほうが挙動を確認しやすくなります。「システムプロキシを自動設定」または画面上の同等の項目を有効にし、テストページを開き直してください。システムプロキシに従うアプリは HTTP または HTTPS リクエストを v2rayN へ渡し、ローカルプロキシが現在のルーティングルールに従って直接接続、プロキシ経由、ブロックのいずれかを決めます。

システムプロキシですべてのプログラムを取り込めるとは限りません。独自のネットワークスタックや内蔵プロキシ設定を使うアプリ、OS のプロキシ設定を読み込まずに直接接続するアプリもあります。「ブラウザーでは有効だが、特定のプログラムでは使えない」場合は、すぐにノード障害と判断せず、そのプログラムがシステムプロキシに従うかを先に確認してください。より広い通信範囲を対象にする場合は、基本接続が成功してから TUN モードと権限、ルーティング、DNS の設定を調べます。

実接続の速度測定：遅延・スループット・安定性を区別する

v2rayN の実接続速度測定では、通常ノード経由で実際のネットワークリクエストを行い、一定時間内のデータ転送結果から利用可能なスループットを測ります。単純な遅延測定より日常の利用環境に近いものの、特定の時刻、対象、テストファイルにおける結果にすぎません。測定中のローカルダウンロード、無線ネットワークの変動、対象サーバーの速度制限、回線の混雑によって数値は変わります。

テスト前に、大容量ファイルの同期、動画再生、その他帯域を消費する処理を一時停止し、候補ノードを少数だけ選んで測定します。一度に多くのノードを測定すると、端末の帯域を奪い合って結果が不正確になることがあります。まず遅延テストで応答するノードを絞り、その後に一つずつ、または少数のグループに分けて実接続速度を測定するのがおすすめです。

ノードの使用感を判断する三つの観点

接続遅延：ページを初めて開くとき、新しい接続を確立するとき、操作に応答するときの速さに影響します。低遅延は頻繁なリクエストに向きますが、継続的な転送性能を単独で示すものではありません。
実効スループット：一定時間に転送できるデータ量を示し、ファイル取得やメディア読み込みに近い性能を反映します。
継続的な安定性：複数回のアクセスで頻繁に切断されないか、速度が大きく変動しないか、長時間の接続を維持できるかを確認します。一度だけ高い数値が出ても、長期的な安定性の証明にはなりません。

比較しやすい結果を得るには、同じネットワーク、同じ時間帯、同じプロキシモードで二つの候補ノードを測定します。各ノードで遅延テストを一回、実接続の速度測定を一回、数分間の通常のウェブ閲覧を行います。より長期的な安定性を比べる場合は、タイムアウトの有無を記録しながら測定を繰り返し、最高速度だけを残さないようにします。

実測は失敗したのに基本遅延が正常な場合、テスト対象にアクセスできない、ノードがハンドシェイクの一部しか完了できない、遠隔回線に問題がある、ルーティングルールによってテスト通信が想定外の出口を通っている、といった可能性があります。まず実際のウェブページを開いて確認し、その後ログにある対象アドレス、アウトバウンドタグ、エラーの種類を確認してください。一つの速度測定ボタンの結果だけで設定を削除しないでください。

プロキシの有効化を確認：プロセス・アクセス・出口の三層で確認

接続確認は少なくとも三つの層を対象にします。第一はプロセス層です。v2rayN のコアが稼働し続け、ローカルポートにエラーがないことを確認します。第二はアクセス層です。システムプロキシを有効にした状態で、テストアプリから対象ページを正常に開けることを確認します。第三は出口層です。信頼できるネットワーク情報ページで、現在のグローバルな出口が想定どおり変化したかを確認します。三つの結果が一致して初めて、初回接続が完了したと判断できます。

推奨する確認順序

現在のノードを変えず、コアのログに接続失敗が継続的に出ていないことを確認します。
システムプロキシを有効にし、テストブラウザーを完全に終了してから再起動します。古い接続が再利用されるのを避けるためです。
通常のウェブページを開き、ドメイン解決、ページのリソース、画像がすべて読み込まれることを確認します。
ネットワーク出口を確認できるページにアクセスし、現在の出口情報を記録します。
システムプロキシを一時的に無効にして再度アクセスし、有効化前後の出口が想定どおり変わるか比較します。
システムプロキシを再び有効にし、複数のサイトへ続けてアクセスして、偶然一度だけ成功したのではないことを確認します。

システムプロキシを無効・有効にしても出口がまったく同じ場合は、ブラウザーに独自のプロキシが設定されていないか、古い接続を再利用していないか、現在のルーティングルールで確認対象が直接接続に指定されていないかを確認します。システムプロキシの設定が正常に書き込まれていない、またはアプリがその設定を読み込まない可能性もあります。明らかにシステムプロキシに従う別のアプリで比較すれば、アプリ側とクライアント側の問題を素早く切り分けられます。

ルーティングの振り分けも確認結果に影響します。v2rayN はドメイン、IP、プロトコル、ルールセットに応じて異なるアウトバウンドを選択できます。バイパスルールを有効にすると、一部の対象は直接接続し、別の対象は現在のノードを経由するため、確認ページによって経路の結果が異なることがあります。初回確認では現在のルーティングモードを把握し、プロキシ経由になるはずの対象を選んで確認してください。

初回接続に失敗した場合の段階的な確認手順

問題を調べるときは、設定元に最も近い場所から始め、段階ごとにアプリ側へ進みます。一度に変更する変数は一つだけにし、変更するたびに再テストしてください。原因と結果の関係を明確に保てるため、もともと有効だった項目が無関係な調整で上書きされることも防げます。

1. サブスクリプションにノードがない、または更新エラーになる

サブスクリプションアドレスが完全か再確認し、現在のネットワークからアクセスできることを確認して、更新ログの応答状態を確認します。サブスクリプショングループは存在するのに一覧が空の場合、更新をまだ実行していない、返された内容を認識できない、フィルター設定ですべてのノードが除外されている、といった可能性があります。単一リンクの取り込みに失敗した場合は、リンクの先頭、エンコードされた内容、コピー範囲を確認し、余分に見える文字を手動で削除しないでください。

2. ノードの遅延がすべてタイムアウトする

まず端末のネットワーク自体が正常か確認し、次にドメイン解決とシステム時刻を確認します。その後、コアのログにアドレス解決、接続拒否、接続タイムアウト、安全なハンドシェイクに関するエラーがないか確認します。同じサブスクリプションの全ノードが同時に失敗する場合は、サブスクリプション設定、現在のネットワーク、ローカル環境を優先して疑います。単一ノードだけが失敗する場合は、別のノードで比較してください。

3. システムプロキシを有効にすると、すべてのウェブページが開かない

これは通常、アプリがリクエストをローカルプロキシへ送ったものの、コアが正しく処理できていないことを意味します。コアが稼働し続けているか、ローカルポートを別のプログラムが使用していないか、システムプロキシのポートが v2rayN の現在の待ち受けポートと一致しているかを確認します。必要であれば、まずシステムプロキシを無効にして通常のアクセスを復旧し、その後でコアのエラーを処理します。無効なポートをシステムが指し続ける状態を避けられます。

4. 一部のウェブページは開くが、別のページは失敗する

ルーティングルール、DNS 解決、対象サイトへの接続エラーを確認します。失敗する対象が直接接続に設定されていて現在のネットワークから到達できない場合は、該当する振り分けを調整します。ドメイン解決で異常なアドレスが返る場合は、DNS の処理経路を確認してください。特定のブラウザー拡張、独自のプロキシ設定、キャッシュされた接続でのみ失敗していないかも確認します。

5. 速度測定は正常なのに、普段の利用が遅い

まずバックグラウンドで帯域を使用する処理を停止し、時間帯を変えて測定を繰り返します。測定対象と実際のアクセス対象では経路が異なるため、結果に差が出ても矛盾ではありません。同じ対象で二つのノードを比較し、ページの表示開始速度、継続的なダウンロード性能、切断の有無を確認してから現在のノードを決めます。すべてのノードで端末だけに異常が出る場合は、無線ネットワークの品質、DNS 応答、システムリソースの使用状況、セキュリティソフトのネットワーク検査機能をさらに確認してください。

初回接続の完了条件

初回接続が完了したら、次の質問に明確に答えられる状態にしてください。現在使っているサブスクリプショングループとノードはどれか。ノードのプロトコルと主要項目は揃っているか。コアは継続的に稼働しているか。システムプロキシは書き込まれているか。テストアプリはシステムプロキシを読み込んでいるか。実接続は利用可能か。プロキシの有効時と無効時で、対象へのアクセス経路は想定どおり変化するか。

基本的な結果が安定してから、自動更新、ルーティングの振り分け、DNS の調整、TUN モードを段階的に有効にします。機能を一つ追加するたびに、もともと使えていた設定を比較用に残してください。変更後に問題が起きても、確認済みの状態へすぐ戻せるため、設定全体を最初から作り直す必要がありません。

日常的に使う場合、サブスクリプション更新後は現在のアクティブノードが置き換わっていないかも確認します。ノード名が同じでも、内部のパラメータが変わっていないとは限りません。突然接続できなくなったら、まずサブスクリプションを更新して別のノードをテストし、その後でローカル設定を確認します。決められた確認順序を使えば、「クライアントは起動しているのにアクセスできない」という状態を、観察・検証可能な具体的な工程に分解できます。