この記事の概要

サブスクリプションは追加したものの、プロキシがつながるか判断できない方に向けた手順です。まず v2rayN でノードを選び、実接続テストを行います。続いてローカルの待ち受けポートを確認し、コマンドラインとブラウザーでそれぞれ通信を検証します。最後にログをもとに、ノードの障害、システムプロキシの未適用、ルーティングによる直接接続を切り分けます。Android でも同じ手順で v2rayNG を確認できます。

1. サブスクリプション・ノード・接続状態を区別する

サブスクリプションの更新成功は、クライアントが設定を取得して解析できたことを示すだけで、すべてのノードに接続できるとは限りません。ノード一覧の名前・地域・プロトコルは設定内容に基づくもので、名前だけでは実際の接続先の所在地はわかりません。また、VMess や VLESS と表示されていても、サーバーが正常に稼働している証拠にはなりません。

v2rayN はデスクトップクライアントで、サブスクリプションの管理、コアの起動、通信の入口の設定を行います。実際にリモート接続を確立するのは、選択したコアです。Android 版の v2rayNG は Xray コア、v2flyNG は v2fly コアを使用します。トラブルシューティングではクライアントとコアの両方を記録し、「V2Rayにつながらない」だけで済ませないようにしましょう。

2. 実接続テストでノードを絞り込む

v2rayN の TCP遅延テストで確認できるのは、主にリモートアドレスとポートへの TCP 接続です。実接続テストでは通常、そのノード経由で指定されたテスト先にアクセスするため、より多くのプロトコルや通信経路を確認できます。どちらも回線速度の測定ではありません。また、テストに成功しても、現在のテスト先に接続できたことを示すだけです。実際に使うWebサイトの確認も必要です。

  1. 候補を選ぶ

    ノード一覧で Ctrl キーを押しながら候補を3つ選択します。まずは異なる経路のノードを選び、サブスクリプション内の全ノードを一度にテストして大量の同時接続が発生するのを避けましょう。

  2. 実接続テストを実行

    右クリックしてテストメニューを開き、「サーバー実接続遅延をテスト」または現在のバージョンで「実接続」を含む項目を選択します。メニュー名はバージョンによって多少異なります。TCP遅延テストやダウンロード速度テストと混同しないようにしてください。

  3. テスト先を確認

    すべて失敗する場合は、「設定」→「パラメーター設定」を開き、実接続テストのアドレスとタイムアウト設定を確認します。実際に使われているアドレスを記録してください。テスト先自体に接続できない場合は、利用可能と確認できている別のHTTPSテスト先に変更して比較します。

  4. 繰り返し比較

    候補ノードごとにさらに2回テストし、ネットワークとテスト先は同じ条件にそろえます。1回の結果で最小値を選ぶのではなく、連続して成功するノードを優先し、そのうえで遅延を比較しましょう。

  5. アクティブサーバーに設定

    安定してテストに成功したノードをアクティブサーバーに設定します。コアの切り替えが完了してから、実際にアクセスしたいWebサイトを開いてください。テストを実行しただけでは、そのノードが現在の接続先に設定されない場合があります。

表示される遅延（ミリ秒）は、テスト先、ハンドシェイク、測定時のネットワーク状況によって変わります。クライアントやテスト先が異なる結果を直接比較するのは適切ではありません。初回のトラブルシューティングでは、特定の遅延値を基準にするより、「安定して成功するか」「失敗時にどのようなログが出るか」を確認しましょう。

実接続テスト

おすすめ

ノード経由でテスト先にアクセスするため、初回接続時のノード選びに適しています。成功した後も、ブラウザーと実際に利用するサービスへの接続を確認してください。

用途：初回利用時のアクティブノード選び

TCP遅延テスト

リモートの TCP ポートに接続できるかを確認します。ポートに接続できても、UUID、TLS、通信経路などのプロトコル設定が正しいとは限りません。

用途：サーバーのポートに接続できるか素早く確認

実際のWebサイトへのアクセス

アプリのプロキシ設定、DNS、ルーティングルール、接続先サービスの影響を受けます。最終的な使用感を確認できますが、1回の失敗だけでノード障害とは判断できません。

用途：普段の利用環境で動作を確認

3. ローカルポートと通信の入口を確認する

次に、「ノードが使えること」と「アプリがそのノードを使っていること」を分けて確認します。v2rayN の「設定」→「パラメーター設定」でローカルの待ち受けポートとアドレスを確認してください。バージョンによって関連項目が独立したインバウンド設定ページにある場合は、実際の画面に従ってください。以下で使う 10808 はコマンドの例であり、すべての環境で同じポートが使われるわけではありません。

ローカル接続の例

待ち受けアドレス
127.0.0.1
例示用ポート
10808
入口のプロトコル
SOCKS5；混合インバウンドでは HTTP も使用可能
確認する場所
パラメーター設定とコアの起動ログ

クライアントが実際にそのポートで待ち受けている場合に限り、後述のコマンドを使用してください。独立した HTTP インバウンドを使う場合は、その専用ポートを指定します。

初回の確認範囲

確認対象
このデバイス上のブラウザーと curl
システムプロキシ
システム設定に従うアプリに適用
TUN モード
初回テストでは、まず無効にする
LAN 共有
このデバイスだけの確認なら不要

一度に確認する入口は1種類に絞りましょう。システムプロキシ、TUN、ブラウザー拡張を同時に有効にすると、通信経路を特定しにくくなります。

Linux では、以下のコマンドで例示したポートを確認できます。何も表示されない場合は、実際のポート番号とコアの状態を先に確認してください。別のプログラムが使用中と表示された場合は、競合するプログラムを終了するかローカルポートを変更し、アプリの設定も合わせて更新します。プロキシ接続に失敗したからといって、ファイアウォールの全ポートを開放しないでください。

ss -ltnp 'sport = :10808'

127.0.0.1 で待ち受けている場合は、このデバイスからの接続だけを受け付けます。本記事の手順に適した設定です。0.0.0.0 はすべての IPv4 インターフェースで待ち受けることを意味し、ほかのデバイスから接続できる可能性があります。初回のローカル接続では、「LAN 接続を許可」を有効にする必要はありません。

4. curl でプロキシ経路を確認する

コマンドラインでプロキシを明示的に指定すると、端末がシステムプロキシを読み取っているかどうかに左右されずに確認できます。以下は、ローカルの SOCKS5 ポート 10808 を使ってHTTPSのIPアドレス確認サービスに接続する例です。サービス側の障害でテストに失敗することもあるため、別の接続可能なテスト先でも確認してください。この結果だけでノード障害と判断しないようにしましょう。

# 直接接続の基準：プロキシ環境変数を無視する。失敗しても診断に役立つ
curl --noproxy '*' --connect-timeout 10 --max-time 20 https://api.ipify.org
printf '\n'

# ローカルの SOCKS5 を明示して使用し、接続先ドメイン名はプロキシ側で解決する
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://api.ipify.org
printf '\n'

socks5h の h は、接続先のドメイン名の処理をプロキシ側に任せる指定です。今回の診断でローカルDNSが結果に影響するのを抑えられます。ただし、デバイス全体のDNS通信がプロキシ経由になったという意味ではありません。--noproxy "" は今回のリクエストでバイパスリストを空にし、環境変数 NO_PROXY によって意図せず直接接続されるのを防ぎます。

HTTP 入口をテストする場合は、そのポートが HTTP プロキシを受け付けることを確認してから、以下のコマンドを実行してください。混合インバウンドでは通常 SOCKS と HTTP の両方を利用できますが、独立した SOCKS インバウンドを HTTP ポートとして使うことはできません。TLSエラーを隠すために証明書検証を無効にしないでください。

curl --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://example.com/

5. ブラウザーとルーティングの動作を確認する

curl でプロキシ接続に成功したら、次にブラウザーを確認します。v2rayN で「システムプロキシ」→「システムプロキシを自動設定」を選択してください。Linux デスクトップで設定が反映されない場合は、GNOME の「設定」→「ネットワーク」→「ネットワークプロキシ」→「手動」で、ローカルの HTTP または SOCKS のホストと対応するポートを入力します。設定画面の場所はデスクトップ環境によって異なるため、実際のシステム画面を確認してください。

ブラウザーに独自のプロキシ設定がある場合もあります。Firefox では「設定」→「一般」→「ネットワーク設定」→「設定」を開き、「システムのプロキシ設定を使用する」を選ぶか、SOCKS ホスト 127.0.0.1 と実際のポートを手動で入力します。システム設定を上書きしないよう、プロキシ設定を変更する拡張機能は一時的に無効にしてください。

  1. 新しいブラウザーウィンドウを開き、コマンドラインのテストで使用した出口IP確認サービスにアクセスして、結果を記録します。
  2. 同時に v2rayN のアクセスログを確認し、該当ドメインのリクエストと選択されたアウトバウンドを照合します。アクセスログが無効の場合は、一時的に有効にして検証し、完了後に元の設定へ戻してください。
  3. 直接接続ルールが適用されている場合は、現在のルーティングモードを記録します。必要に応じて、一時的に現在のバージョンで利用できるグローバルプロキシモードに切り替えて比較し、テスト後に元のルールへ戻してください。
  4. 最後に、実際に利用するWebサイトへアクセスします。入口、ルーティング、接続先へのアクセスがすべて想定どおりになって初めて、初回接続の確認が完了です。

Android では v2rayNG でノードを選択後、メイン画面の接続ボタンをタップし、システムの VPN 接続を許可してから接続テストを行います。VPNのステータスアイコンが表示されても、ローカルのトンネルが確立したことしかわかりません。接続先にアクセスできることも確認してください。アプリごとのプロキシ設定を有効にしている場合は、ブラウザーが対象に含まれているか確認します。v2flyNG でも接続状態と対象アプリの範囲をそれぞれ確認してください。

6. 初回接続でよくある質問

実接続テストは成功するのに、ブラウザーでWebサイトを開けないのはなぜですか？

まず SOCKS5 を明示した curl コマンドを実行します。成功する場合は、ブラウザー独自のプロキシ設定、システムプロキシ、ルーティングルールを重点的に確認してください。ブラウザーからのアクセスログが見つからない場合、そのリクエストはコアに届いていない可能性があります。サブスクリプションのプロトコル設定をすぐに変更しないでください。

TCP遅延の結果は出るのに、実接続テストがずっとタイムアウトするのはなぜですか？

リモートの TCP ポートには接続できても、その後の通信が完了していない状態です。テスト先が利用可能か確認し、システム時刻と、ログに記録された TLS・認証・通信エラーを確認してください。特定のノードだけ失敗する場合は、サブスクリプションを更新して別のノードと比較します。VLESS を VMess に変更するなど、設定を独自に書き換えないでください。

コマンドで 127.0.0.1:10808 に接続できないと表示されるのはなぜですか？

「設定」→「パラメーター設定」に戻って実際のポートを確認し、ポート確認コマンドを実行してください。コアのログにアドレスが使用中と表示される場合は、競合を解消してからコアを再起動します。リモートノードがどれほど安定していても、ローカルの入口が待ち受けていなければ接続できません。

Webページが開けば、プロキシが動作していると判断できますか？

必ずしもそうではありません。接続先がもともと直接接続できる可能性があります。出口IPの確認結果、コアに記録された接続先へのリクエスト、適用されたプロキシのアウトバウンドをあわせて判断してください。プロキシのアイコン、ノード名、1回の速度テストの結果だけでは、ブラウザーの実際の通信経路を証明できません。

それでも接続できない場合、トラブルシューティング情報には、OS、クライアントのバージョン、コアの名称とバージョン、入口の種類とポート、テスト先、失敗した時刻、関連するエラー行を記載してください。バージョンはクライアントの「ヘルプ」→「バージョン情報」またはコアの起動ログで確認できるため、「最新版」とだけ書かないようにしましょう。これらの情報があれば、具体的に失敗した箇所から調査を始められ、ローカル設定とサーバー側の設定の問題も切り分けやすくなります。