サブスクリプションをインポートしたものの、初回接続の手順がわからない方に向けて解説します。「候補ノードを選ぶ → 実接続をテストする → アクティブサーバーに設定する → システムプロキシを設定する → 実際の通信を確認する」の順に進めましょう。この記事ではWindows版v2rayNを例に、ノードの接続可否、コアの動作、アプリのプロキシ利用をそれぞれ確認します。ポート番号の例は、使用中の画面に表示された値に読み替えてください。
1. ノード一覧から候補を絞る
メイン画面で現在のサブスクリプショングループを開き、サーバーアドレス、ポート、プロトコルなどが一覧に表示されていることを確認します。サブスクリプションは接続情報を配布する仕組みであり、接続状態を示すものではありません。ノード名が表示されても、クライアントが情報を読み込めたことしかわからず、サーバーに接続できることや、ブラウザーがプロキシを使っていることの証明にはなりません。
初回は候補を2〜3個に絞り、サブスクリプション全体を何度もテストする必要はありません。ノード名に含まれる地域、倍率、回線の説明は提供元が設定したもので、あくまで選択時の参考情報です。実際の通信品質は、利用中のネットワーク、サーバーの負荷、接続先にも左右されます。名前が似ているノードでも、出口が異なる場合があります。
接続情報がそろった候補
おすすめサブスクリプション更新後に接続情報がそろっており、実接続テストに成功するノードを優先しましょう。まず一度アクセスを確認してから、長期利用する回線を検討します。プロトコル、ルーティング、DNSを同時に変更するのは避けてください。
おすすめの用途：初回接続、再現可能なテスト環境の作成
ポートテストのみ成功
TCPポートに到達できても、正常なのは接続の最初の段階だけかもしれません。認証、伝送経路、TLS、その後のHTTPリクエストで失敗する可能性があります。候補として残し、すぐに利用可能と判断しないでください。
おすすめの用途：ネットワーク到達性とプロトコル接続の問題を切り分ける
タイムアウト、または接続情報が不足
まずサブスクリプションの更新が成功したか、サービスの有効期限が切れていないか、端末の時刻が正しいかを確認します。UUID、SNI、伝送パス、REALITYの設定を推測で変更しないでください。これらの値はサーバー側の設定と一致している必要があります。
おすすめの対応：使用をいったん中止し、提供元に設定を確認する
VMessやVLESSは接続プロトコル、WebSocketなどは伝送方式で、TLSやREALITYは接続のセキュリティ設定に関わります。初めて使う場合、「新しいプロトコルほど高速」と考えて選ぶ必要はありません。まずはサブスクリプションからインポートした組み合わせを維持し、使用するコアが対応しているか確認しましょう。サブスクリプションの設定に誤りがある場合、システムプロキシを切り替えてもプロトコルのハンドシェイクは解決しません。
2. 実接続テストでノードの通信を確認
ノード一覧で候補を選び、右クリックメニューから「サーバーへの実接続遅延をテスト」を選択します。バージョンによっては「実接続遅延をテスト」と表示されます。実際のメニューに従ってください。候補ノード経由でテスト先にアクセスする時間を測る機能で、単純なPingやダウンロード速度の測定ではありません。
-
テスト先を確認する
「設定」→「パラメーター設定」を開き、実接続テスト先に関する項目を探します。まずはクライアントの初期設定を維持し、現在のネットワークで利用できるか確認してください。テスト先を変更した場合、変更前後の結果をそのまま比較することはできません。
-
候補を選択する
ノード一覧に戻り、Ctrlキーを押しながら2〜3個選択します。端末の帯域使用量がノード間の差に影響しないよう、大容量ファイルのダウンロードは一時停止してください。
-
実接続テストを実行する
右クリックして「サーバーへの実接続遅延をテスト」を選び、結果が表示されるまで待ちます。遅延が明確に表示されてから次のテストに進みましょう。テストを連続でクリックしてタスクを重ねないでください。
-
再テストして候補を残す
テスト先とネットワークを変えずに、もう一度テストします。2回とも成功したノードを優先して残しましょう。一度だけタイムアウトしたノードはアクセス確認まで保留し、単発の結果だけで長期的な評価を決めないでください。
実接続テストでは通常、候補ノードを使った一時的なテスト接続を確立します。ブラウザーのシステムプロキシ設定は必要ありません。プロトコル接続やテスト先へのリクエストは確認できますが、すべてのWebサイトにアクセスできると保証するものではありません。計測範囲はクライアントの実装によって異なるため、同じテスト環境での比較に使ってください。
3. アクティブサーバーとローカルポートを設定
ノード一覧で候補を右クリックし、「アクティブサーバーに設定」を選択してから、メイン画面の状態とログを確認します。行のハイライトだけで判断しないでください。選択行が強調表示されているだけの場合もあります。アクティブサーバーの表示やステータスが切り替わり、コアがすぐに終了していないことを確認しましょう。バージョンによって操作方法が多少異なりますが、右クリックメニューならショートカットを覚えなくても確認しやすくなります。
続けて「設定」→「パラメーター設定」を開き、ローカルの待ち受けアドレスとポートを確認します。下の2つのカードでは、リモート接続情報とローカルの接続口を分けて記載しています。サーバー側の443をブラウザーのプロキシポートに設定しないよう注意してください。以下は項目の説明用の例であり、端末の初期値でも、そのまま使えるノード情報でもありません。
ローカルプロキシの接続口（例）
- 確認場所
- 設定 → パラメーター設定
- 待ち受けアドレス
- 127.0.0.1
- ポートの例
- 10808
- 利用条件
- このポートがHTTPまたは混合プロキシに対応
端末上のアプリはここに接続します。コマンドラインの例でも、実際に待ち受けているポートを指定してください。
リモートノードの接続情報
- 確認場所
- ノード一覧 → サーバーを編集
- サーバーアドレス
- サブスクリプションからインポートした値を使用
- ポートの例
- 443
- 認証と伝送方式
- 提供元から指定された接続情報をすべて維持
コアはここに接続します。リモート側のポートをローカルプロキシの待ち受けポートとして使うことはできません。
以前の設定ではSOCKSとHTTPに10808、10809を個別に割り当てる場合があり、新しい設定では1つの混合ポートを使う場合もあります。番号だけでプロトコルを判断しないでください。ログにaddress already in useやバインド失敗が表示された場合は、クライアントが重複して起動していないか確認して終了し、ポートの使用状況を確認します。コアが待ち受けを開始する前にWebページの問題を調べても解決にはつながりません。
4. システムプロキシでブラウザーをローカル接続口に接続
v2rayNのメイン画面下部、または通知領域の右クリックメニューから「システムプロキシ」→「システムプロキシを自動設定」を選択します。コアが正常に動作してから有効にし、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」でアドレスとポートを確認してください。「システムプロキシを自動設定」はクライアントの操作名であり、自動構成スクリプトのアドレスを手入力するという意味ではありません。
システムプロキシは、設定を参照するアプリにローカルの接続口を知らせるもので、端末上のすべての通信を強制的に引き受けるわけではありません。ブラウザーはシステム設定を使う場合もあれば、独自の設定、拡張機能、組織のポリシーで上書きされる場合もあります。初回の確認時は、プロキシ設定を変更する可能性のある拡張機能を無効にし、新しいウィンドウを開いて古い接続の影響を避けましょう。
| 確認項目 | 確認場所 | 正しい理解 |
|---|---|---|
| システムプロキシの設定 | v2rayNの「システムプロキシ」メニュー | 自動設定後も、アプリがシステムプロキシを参照しなければ利用されません。 |
| ローカルアドレスとポート | Windowsの「ネットワークとインターネット」→「プロキシ」 | クライアントが実際に使用しているHTTPまたは混合プロキシの待ち受け設定と一致させます。 |
| ルーティングモード | v2rayNのメイン画面にあるルーティング設定 | コアに渡されたリクエストを直接接続、プロキシ経由、またはブロックのどれにするかを決めます。システムプロキシの切り替えとは別の設定です。 |
| ブラウザー独自の設定 | ブラウザーの設定と拡張機能の管理 | 独自のプロキシルールがシステム設定を上書きする場合があるため、個別に確認してください。 |
まずは現在のルーティング設定で接続を確認し、最初からTunを有効にする必要はありません。特定のアプリがシステムプロキシを参照しない場合は、アプリ独自のプロキシ設定を確認するか、必要に応じてTunの権限や通信の取り込み範囲を調べてください。複数の通信取り込み方式を同時に有効にすると、初回の問題切り分けでリクエストの経路を特定しにくくなります。
5. 接続確認：リクエストとログを照合
ブラウザーで、これまで開いたことのないHTTPSページにアクセスしながら、v2rayNのログを確認します。ページが表示されただけでは不十分です。キャッシュから表示された可能性や、ルーティングルールによって直接接続された可能性があります。アクセス時刻、接続先ドメイン、ログのアウトバウンド情報を照合し、今回のリクエストがプロキシノードを経由したか確認しましょう。
- コアの稼働を確認：起動失敗、ポートのバインド失敗、プロセス終了がログに繰り返し記録されていないことを確認します。
- アプリの接続を確認：新しいリクエストを送信し、対応する接続先がログに表示されるか確認します。アクセスログを有効にしていない場合は、「設定」→「パラメーター設定」でログ関連の項目を確認してください。記録がないだけで、アプリが接続していないと判断しないでください。
- ルーティング先を確認：プロキシ、直接接続、ブロックを区別します。アウトバウンドのラベルは設定によって異なるため、現在のルーティングルールと照らし合わせてください。ドメインが表示されたかどうかだけでは判断できません。
- 接続先の応答を確認：Webページから正常な応答が返ることを確認します。認証失敗、TLSエラー、接続タイムアウトが発生した場合は、引き続き原因を調べてください。ローカルポートに接続できただけで成功とは判断できません。
ブラウザー設定の影響を切り分けるには、Windowsターミナルでcurl.exeを使い、プロキシを明示してリクエストを送信できます。以下のコマンドではHTTPまたは混合ポートが10808であると仮定しています。実際のポートが異なる場合は、先に変更してください。通常のGETリクエストを1回送り、レスポンス本文を破棄しながら接続の進行状況を表示します。ダウンロード速度の測定には使えません。
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -v -o NUL https://example.com/このコマンドで確認できるのは、リクエストが指定したローカルの接続口に渡されたことまでです。コアが最終的にプロキシ経由で接続したとは限りません。接続先が直接接続のルールに該当する場合もあります。コマンドの実行時刻とログを照合し、必要に応じて対象への接続が明確にプロキシ経由となるルーティングを一時的に選んで再試行してください。確認後は元の振り分け設定に戻します。環境変数にプロキシの除外リストを設定している場合は、テストへの影響も確認してください。
6. 初回接続でよくある問題と確認事項
実接続テストに成功したのに、ブラウザーがタイムアウトするのはなぜ？
まず「システムプロキシ」→「システムプロキシを自動設定」が実行済みか確認し、Windowsのプロキシポートが現在の待ち受け設定と一致しているか確認してください。上記のプロキシを明示するコマンドでブラウザーの影響を切り分けます。コマンドでも失敗する場合は、アクティブノードがテストしたノードと同じか確認しましょう。
すべてのノードがタイムアウトします。サブスクリプションの期限切れですか？
すぐにそうとは判断できません。まずプロキシを使わない基本のネットワーク接続を確認し、システム時刻とタイムゾーンを確認してから、テスト先を確認します。その後、コアが起動しているか、サブスクリプションの有効期限が切れていないかを調べてください。同じテスト先だけで失敗する場合は、到達可能と確認できている別のテスト先で再試行します。
特定のWebサイトだけ開けません。ノードを変更すべきですか？
まず別の接続先もテストし、失敗したリクエストのログを確認します。特定のWebサイトだけ開けない原因として、DNS、ルーティング、アカウントの地域設定、サイト側の制限などが考えられます。現在使えているノードは維持し、一度に変更する設定は1つに絞りましょう。接続先側の問題を回線全体の障害と誤認しにくくなります。
クライアントを終了すると、Webページも開けなくなるのはなぜ？
通知領域のメニューから「システムプロキシ」→「システムプロキシを解除」を実行してから、クライアントを終了します。プログラムが異常終了した場合は、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、ローカル端末を参照する手動プロキシが残っていないか確認してください。組織によって管理されている設定は、管理者に確認してください。
確認が終わったら、現在のアクティブノード、ローカルの待ち受けポート、使用中のルーティングモードの3点を記録しておきましょう。次回問題が起きたときは、再インストールやサブスクリプション設定の一括変更をする前に、この3点を確認してください。さらに調べる場合はトラブルシューティングを参照し、待ち受け、プロトコル接続、ルーティング、アプリ設定のどこで問題が起きているか切り分けましょう。
ログを共有する前に、サブスクリプションのリンク、認証情報、サーバーアドレスなどの機密情報を削除してください。エラーの種類、発生時刻、実施済みのテストを残しておくと、「接続できない」という説明だけより原因を特定しやすくなります。初回接続で目指すのは遅延の数値を表示させることではなく、新しいリクエストがアプリからどのローカルポートに入り、どのアウトバウンドを経由したか説明できる状態にすることです。