この記事の概要

サブスクリプションを登録したものの、接続方法がわからないWindowsユーザー向けです。まずTcpingで接続可能なノードを絞り込み、実接続テストでプロキシ経路を確認します。続いて使用するサーバーを設定してシステムプロキシを有効にし、ブラウザーのリクエスト、出口IP、ログを照合します。この記事ではシステムプロキシのみを検証し、経路が混在しないようTUNは併用しません。

1. インポート後にノードと使用サーバーを確認

ノード一覧に項目が表示されても、クライアントがサーバー情報を読み込めたことを示すだけです。サブスクリプションが有効であることや、ブラウザーがプロキシを使っていることまでは確認できません。v2rayNはクライアントの操作画面で、実際の接続はコアが処理します。ノードのアドレス、ポート、認証情報、通信設定の組み合わせによって接続の成否が決まります。

以下では、デスクトップ版でよく使われる中国語メニュー名をもとに説明します。バージョンによっては、速度テストのメニューに「複数選択」などの語句が追加されている場合があります。判断時は「Tcping」「実接続遅延」「アクティブサーバーに設定」といった機能名を目印にしてください。アップデート後にメニューの場所が変わった場合は、まず「ヘルプ」でバージョン情報を確認し、トラブル調査では完全なバージョン番号を記録します。

  1. サブスクリプションを確認

    「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、対象グループが有効か、アドレスが正しいかを確認します。再取得する場合は「サブスクリプショングループ」メニューから「現在のサブスクリプションを更新(プロキシを使用しない)」を選択します。プロキシがすでに使える場合に限り、プロキシ経由での更新を試してください。

  2. 候補を選ぶ

    一覧から3~5個のノードを選び、できれば異なる経路や地域のものを含めます。備考欄の地域名だけで判断しないでください。備考はサービス提供者が付けたラベルであり、実際の出口の位置を証明するものではありません。

  3. 接続可否をテスト

    選択したノードを右クリックし、「サーバー遅延をテスト Tcping」を実行します。遅延が正常に表示されたノードを候補として残し、タイムアウトしたノードはひとまず保留します。すぐにプロトコル設定を変更する必要はありません。

  4. 実接続をテスト

    候補ノードを右クリックし、「サーバー実接続遅延をテスト」を実行します。繰り返し成功するノードを選び、右クリックして「アクティブサーバーに設定」を選択します。一覧のアクティブ表示が切り替わったことも確認してください。

2. Tcpingと実接続テストでわかること

Tcpingで主に確認できるのは、クライアントからサーバーの指定TCPポートへ接続を確立できるかどうかです。ICMP Pingとは異なり、プロキシ認証、TLS、通信経路、接続先サイトへのアクセスを一通り検証するものではありません。サーバーのポートに接続できるのは、最初の条件を満たしたにすぎません。

実接続テストでは、プロキシコアを介して設定されたテスト先へリクエストを送るため、実際のプロキシ通信に近い状態を確認できます。結果はテスト先、DNS、プロトコルのハンドシェイク、その時点の回線状況に左右されます。あるテスト先がタイムアウトしても、その回線から接続できないだけの場合があります。一度の結果だけでノードが使えないと判断しないでください。

速度テスト結果の組み合わせ例:数値は見方を説明するためのもので、実測値ではありません
結果の組み合わせ説明次の手順
Tcping 48 ms、実接続 260 msポートに接続でき、テストリクエストも成功しています。2つの測定で確認する範囲は異なります。アクティブサーバーに設定し、ブラウザーで実際の接続先サイトを確認します。
Tcping 35 ms、実接続はタイムアウトポートには接続できますが、認証、通信設定、名前解決、またはテスト先に問題がある可能性があります。システム時刻とログを確認し、別のテスト先でもう一度試します。
Tcpingはタイムアウト、実接続は成功一時的な通信変動のほか、接続方式がTCPプローブと完全には対応していない可能性があります。再テストし、実際のウェブアクセスとログをもとに判断します。
どちらもタイムアウト現在のネットワークからノードへの接続、ノード側のサービス、または設定に問題がある可能性が高い状態です。別の回線のノードを試し、単一ノードの問題かネットワーク全体の問題かを切り分けます。

メニューにあるダウンロード速度テストは、一定時間にどれだけのデータを転送できるかを測る別の機能です。遅延が60 msでもダウンロード速度が速いとは限らず、実接続が300 msでもすべてのウェブページで同じ時間待つわけではありません。初回接続では、まずリクエストを安定して完了できるかを確認し、その後、実際の用途に合わせて転送速度を比較します。複数ノードの一括テストは通信量を消費するため、候補を少数に絞ってから実施してください。

3. 最小遅延だけでなく、繰り返し成功するノードを選ぶ

同じノードを3回連続で測定すると、一度だけ出た最小値より判断材料になります。たとえば、実接続の結果が220、235、228 msなら、90 ms、タイムアウト、1800 msとばらつくノードより初回接続の候補に適しています。ここでの数値は結果の見方を示す例であり、回線品質を保証するものではありません。夜間の混雑、Wi-Fiの電波状況、サーバー負荷によって結果は変わります。

候補ノードの使い分け:メインと予備

メインノード
  • 実接続テストが3回連続で成功する。
  • 普段使うウェブサイトで本文と静的リソースを正常に読み込める。
  • 遅延の変動が小さく、長時間の接続が頻繁に切れない。
予備ノード
  • できるだけメインノードとは異なる経路を使う。
  • 実接続テストとブラウザーでの確認を済ませておく。
  • メインが使えないときは、手動でアクティブサーバーに設定して再テストする。

まずは安定して使えるメインを1つ、検証済みの予備を1つ確保しましょう。初回接続時にサブスクリプション内の全ノードを試す必要はありません。

VMessやVLESSなどのプロトコル名は、速度のランクを示すものではありません。遅延を下げるために、サブスクリプションに設定されたポート、TLSサーバー名、通信パス、Flowをむやみに変更しないでください。これらの値はサーバー側と一致させる必要があります。ノードが1つだけ失敗する場合は、設定を推測で変更するより、別のノードと比較するほうが原因を特定しやすくなります。

4. システムプロキシを有効にしてローカル待ち受けポートを確認

アクティブサーバーを設定したら、メインウィンドウ下部またはタスクトレイのメニューから「システムプロキシ」→「システムプロキシを自動設定」を選択します。次に、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、クライアントが設定したローカルプロキシのアドレスを確認します。ここでは設定結果の確認だけを行い、別のプロキシ値を手動で追加しないでください。

ローカルポートは「設定」→「パラメーター設定」の「ローカル混合待ち受けポート」で確認します。新しい設定では10808がよく使われます。旧バージョンではSOCKSとHTTPのポートが別々に設定され、HTTPポートには10809がよく使われます。アップグレード時に引き継がれた設定が異なる場合もあるため、説明にある数値だけを見て既存の値を上書きしないでください。

クライアントの待ち受け設定

設定場所
設定 → パラメーター設定
アドレス範囲
ループバックアドレス 127.0.0.1
混合ポートの例
10808(実際の画面表示を優先)
アクティブサーバー
実接続テスト済みの候補ノード

混合待ち受けはHTTPとSOCKSのリクエストを受け付けます。ポートを分けている場合は、それぞれ確認してください。

システムプロキシの確認

クライアントでの操作
システムプロキシ → システムプロキシを自動設定
Windowsでの確認場所
Windowsの設定 → ネットワークとインターネット → プロキシ
サーバーアドレス
127.0.0.1
ポートの条件
実際のHTTPまたは混合待ち受けポートと一致していること

システムプロキシはデバイス全体の通信をすべて中継する機能ではなく、この設定に従うアプリだけに適用されます。

5. ブラウザーで検証:ウェブアクセス・出口IP・ログを照合

ブラウザーで中国国内のサイトを開けても、プロキシ接続に成功した証明にはなりません。ルーティング設定によって、そのドメインへの接続が直接通信になる場合があります。プロキシ経由になる想定の接続先を選び、該当するリクエストがクライアントに届いているか、ログの出力先がどのように記録されているかを確認します。

  1. 新しいリクエストを発生させる。アクティブサーバーを確認したら、古いテスト用タブを閉じ、新しいブラウザーウィンドウで接続先サイトを開きます。必要に応じてブラウザーを完全に終了して再起動し、既存の接続が再利用される影響を減らしてください。シークレットウィンドウを使うとキャッシュの影響を抑えられますが、プロキシ設定が自動で変わるわけではありません。
  2. ブラウザーが使うプロキシ設定を確認する。初回検証では、Windowsのシステムプロキシに従うブラウザーを使います。プロキシ拡張機能を入れている場合は、いったん無効にしてください。ブラウザー側で手動プロキシを設定している場合は、システムプロキシを使う設定に変更し、クライアントが書き込んだ設定を上書きしないようにします。
  3. 出口IPを確認する。信頼できるパブリックIP確認サイトで出口IPを記録し、システムプロキシを解除したときの結果と比較します。対象ドメインのルーティング先も確認してください。確認サイトへの接続が直接通信になっている場合、ローカルのIPが表示されても、クライアント全体が機能していないとは限りません。
  4. ログと照合する。v2rayNのメインウィンドウにあるログまたは情報欄を開き、対象サイトを再読み込みして、同じ時刻のドメイン、接続記録、出力先を確認します。表示される項目はコアによって異なります。ウィンドウにアクティブ表示があるだけの場合より、プロキシ経由の出力記録があるほうが確かな証拠になります。
  5. 条件を変えて比較する。TUNが無効で、ほかのプロキシツールも通信を中継していないことを確認したうえで、「システムプロキシ」→「システムプロキシを解除」を選び、リクエストを新しく発生させます。その後、「システムプロキシを自動設定」に戻して再テストします。接続先が常に直接接続可能な場合は、ページが開くかどうかだけで判断せず、出口IPとログも確認してください。

ブラウザーの出口IP確認でわかるのは、そのリクエストが通った経路だけです。すべてのアプリがプロキシを使っていることを証明するものではありません。Windowsのシステムプロキシ設定を無視するアプリでは、アプリ内にHTTPまたはSOCKSのアドレスを設定する必要があります。また、独自に長時間接続を維持するアプリは、設定変更後に再起動が必要な場合があります。まずブラウザーでの検証を完了し、その後ほかのアプリを個別に確認してください。接続方式の異なるものを一緒に扱わないようにします。

6. 初回接続でよくある問題と対処の順番

調査では一度に変更する条件を1つに絞り、変更前後の結果を記録してください。おすすめの順番は、ノードの実接続、アクティブサーバー、ローカルポート、システムプロキシ、ブラウザー独自の設定、最後にルーティングとDNSです。この順序なら、ポートを直す際にルーティングまで変更して原因がわからなくなる事態を避けられます。

Tcpingで数値が出るのに、ウェブページが開けないのはなぜですか?

まず同じノードで「サーバー実接続遅延をテスト」を実行します。実接続に失敗する場合は、ログで認証、TLS、接続タイムアウトに関するエラーを確認してください。Windowsの「設定」→「時刻と言語」→「日付と時刻」でシステム時刻を同期してから、もう一度テストします。ポートに接続できることと、プロキシのハンドシェイクが成功することを混同しないでください。

実接続は成功するのに、ブラウザーに「プロキシサーバーが接続を拒否しました」と表示されるのはなぜですか?

まず、Windowsのプロキシポートと「設定」→「パラメーター設定」にあるローカル待ち受けポートが一致しているか確認します。たとえば、クライアントが10808で待ち受けているのに、システム側が10809を指定していると、サービスが存在しないポートに接続している可能性があります。「システムプロキシを自動設定」を再実行し、ログにポートの競合やコアの起動失敗が記録されていないか確認してください。

ノードを変更しても、確認したIPアドレスが変わらないのはなぜですか?

新しいノードが確実に「アクティブサーバーに設定」されていることを確認し、ブラウザーの接続を新しくします。IP確認サイトのドメインが直接接続に振り分けられている場合や、異なるノードが同じ出口を共有している場合もあります。そのため、IPが変わらないだけでは切り替え失敗と判断できません。アクティブ表示、確認サイトへの出力ログ、ほかの接続先へのリクエストも照合してください。

サブスクリプションを更新できれば、ノードも使えるということですか?

いいえ。サブスクリプションを更新できたことが示すのは、クライアントがノード情報を取得できたという点だけです。サブスクリプションのURLとノードサーバーは通常、別の接続先です。更新後も実接続テストを行い、アカウントの通信量、有効期限、サーバーの稼働状況を確認してください。更新に失敗しても、唯一使えるノードをすぐに削除しないでください。

初回接続の完了は、特定のステータス表示ではなく、複数の確認結果が一致しているかで判断します。アクティブサーバーが正しく設定され、実接続が繰り返し成功し、システムプロキシが実際の待ち受けポートを指定し、ブラウザーの対象リクエストが想定どおりプロキシを経由していることを確認してください。検証済みのノードとポートを記録しておけば、後から問題が起きたときに、動作確認済みの設定と比較して調査を始められます。詳しい操作は設定ガイドを、症状に応じた調査はトラブルシューティングをご覧ください。