クライアントをインストールしたものの、接続が安定しない方に向けた内容です。まずサブスクリプションが正しくインポートされているか確認し、次にローカルでの待ち受け、システムプロキシ、ノードとのハンドシェイク、DNSを調べます。デスクトップの例にはv2rayNを使用します。Androidでv2rayNGまたはv2flyNGを使う場合は、システムプロキシの代わりにアプリのVPN接続機能を利用してください。一度に変更する項目は一つにし、同じテスト先で毎回確認しましょう。
1. サブスクリプションを更新できないとき、最初に確認することは？
まず「サブスクリプションの取得に失敗した」ケースと、「取得はできたがノードに接続できない」ケースを分けて考えます。サブスクリプションURLはノード設定を取得するためのもので、サーバーアドレス欄に直接入力するノード情報ではありません。更新がタイムアウトしたら、まずPCがインターネットに接続できているか、URLが欠けていないかを確認します。VMessやVLESSのプロトコル設定を先に変更する必要はありません。
v2rayNの「サブスクリプショングループ」→「サブスクリプショングループ設定」で、該当グループのURLを確認します。コピーするときは、前後の空白や引用符、改行を含めないでください。バージョンによってメニュー名が多少異なる場合があるため、実際の画面にある「サブスクリプショングループ」と「サブスクリプションを更新」の機能を使ってください。
-
URLを確認する
サービス提供元が案内した完全なサブスクリプションURLをコピーしているか確認します。アカウントページのURLではありません。URLに含まれるトークンは認証情報です。公開チャットやスクリーンショットに載せないでください。
-
プロキシなしで試す
「サブスクリプショングループ」から、プロキシを経由しない更新を実行し、ログにタイムアウト、HTTPステータスエラー、内容の解析失敗のどれが表示されるか確認します。
-
プロキシ経由で試す
プロキシ経由の更新を試すのは、利用可能なノードがすでにある場合に限ります。現在のノードが使えないなら、そのノード経由でサブスクリプションを更新しても失敗します。
-
アカウントを確認する
401または403が返る場合は、サブスクリプションの有効期限、トークンの再発行の有無、サービス側のアクセス制限を確認します。認証の問題を解決するためにローカルポートを何度も変更しないでください。
2. 更新完了と表示されるのに、ノード一覧が空なのはなぜ？
リクエストが成功しても、取得した内容が有効とは限りません。サブスクリプションのAPIがログインページやエラーメッセージを返したり、現在のクライアントが解析できないデータを返したりする場合があります。まずログでインポート件数を確認し、メイン画面で選択中のグループも確認してください。空のグループを表示していたり、検索条件が残っていたりすると、インポート済みのノードが一時的に見えないことがあります。
- まず絞り込みを解除：すべてのノードを含む表示に切り替え、検索欄を空にしてからグループ名を確認します。
- 次にインポート件数を確認：ログの追加件数が0なら、サブスクリプションの形式とクライアントの対応状況を確認します。「更新完了」という表示だけで判断しないでください。
- 入口の種類を確認：単体の
vmess://またはvless://リンクは、ノードのインポート機能から追加します。サブスクリプショングループには、設定を取得するためのURLを登録します。 - 既存の設定を残す：まずテスト用のグループを新規作成して再インポートします。まだ使える古いグループをすぐに削除しないでください。
v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。サブスクリプションを解析できるか、ノードを実行できるかは、クライアントとコアが各プロトコル設定に対応しているかどうかにも左右されます。デスクトップでインポートできた設定が、別のクライアントでも使えるとは限りません。ファイル名だけで判断しないでください。
3. 遅延テストの数値は何を示す？低いほどよい？
まずテストの種類を確認します。TCP遅延は主にサーバーのポートへ接続するまでの時間を示し、プロキシプロトコルの認証に成功したことまでは確認できません。実接続の遅延テストは通常、プロキシ経由で指定したテスト先にリクエストを送り、より多くの通信経路を測定しますが、継続的なダウンロード速度と同じではありません。テスト先が異なる結果は、そのまま比較できません。
上記の数値はトラブルシューティング用の設定例であり、ノードの実測値や、すべての環境に共通する既定値ではありません。たとえば同じ条件で、あるノードが80ミリ秒、別のノードが160ミリ秒なら、このテストでは前者の応答が速かったことだけがわかります。動画の再生状況は、帯域幅、混雑、パケットロス、接続先サイトにも左右されます。まず複数回のテスト結果が安定しているかを見てから、最小値を比べましょう。
判断のポイント：実接続を確認してから遅延を比較
同じテスト先を固定し、候補のノードをそれぞれ3回繰り返しテストします。まず継続してタイムアウトするノードを除外し、その後、実際のWebページ表示やダウンロードで使い勝手を比較します。TCP遅延の一度きりの結果だけで順位をつけ、ノードが使えると決めつけないでください。
4. TCPテストでは数値が出るのに接続がタイムアウトするとき、ログはどう読む？
サーバーのポートにTCP接続できても、UUID、トランスポート経路、TLS、REALITYの設定が正しいとは限りません。ノードを選択してアクティブサーバーに設定し、クライアントのログを開いてからWebページへ一度アクセスします。そのリクエストを実行した時刻を記録し、後から繰り返し表示されるタイムアウトではなく、最初に出た具体的なエラーを優先して確認しましょう。
エラー：connection refused
原因と対処：接続が拒否されています。まずログに表示された接続先を確認します。127.0.0.1ならローカルのコアが起動しているかを調べます。リモートノードのアドレスなら、サーバーのポートとサービスの稼働状況を確認してください。
エラー：i/o timeout
原因と対処：ネットワーク処理がタイムアウトしました。直前に表示された接続先を手がかりに、DNS、リモート接続、リクエスト応答のどの段階で発生したかを判断します。既知の正常な別ノードに切り替えて比較してください。
エラー：x509: certificate has expired or is not yet valid
原因と対処：証明書の有効期間の検証に失敗しています。まずシステムの日付、時刻、タイムゾーンを同期します。時刻が正しいのにエラーが続く場合は、証明書の検証を無効にせず、サーバーの管理者に証明書を確認してもらってください。
ログの表記はコアやバージョンによって異なります。VLESSの設定では、アドレス、ポート、UUID、トランスポート方式、安全性に関する設定を一つずつ確認してください。REALITYを使う場合は、サーバー提供のserverName、公鍵、shortId、必要なflowも確認します。通常のTLSノードの項目をREALITYの設定に流用しないでください。
5. ノードは使えるのに、システムプロキシを有効にしてもアプリが直接接続するのはなぜ？
システムプロキシの設定が反映されるのは、その設定を参照するアプリだけです。すべての通信が自動的にプロキシ経由になるわけではありません。v2rayNのシステムプロキシ設定は、アプリからローカルポートへ通信を渡すためのものです。ルール設定は、コアに渡された通信の出口を決めます。それぞれを別々に確認してください。ルーティングを「グローバル」にしても、アプリからの通信経路設定の代わりにはなりません。
| 確認する場所 | 操作内容 | 確認のポイント |
|---|---|---|
| v2rayNのシステムプロキシメニュー | 「システムプロキシを自動設定」を選択する | システムプロキシのアドレスがローカルの待ち受けアドレスとポートを指している |
| Windowsのプロキシ設定 | 「設定」→「ネットワークとインターネット」→「プロキシ」を開く | 手動プロキシのアドレス、ポート、例外リストを確認する |
| アプリ内の設定 | アプリ独自のプロキシ設定や、システムプロキシを無視する設定がないか確認する | アプリの接続方式とクライアントの待ち受けプロトコルが一致している |
| v2rayNのルーティングモード | 対象ドメインに適用されるルールと通信の出口を確認する | プロキシ経由にしたい接続先が、先に直接接続のルールに一致していない |
特定のアプリだけが失敗する場合は、すべてのノードをすぐに変更せず、まずそのアプリを確認してください。システムプロキシを参照しない通信もプロキシ経由にする必要がある場合は、TUNの利用を検討します。TUNは仮想ネットワークアダプター、ルーティング、DNSに関わるため、基本的な接続を確認してから有効にしてください。
6. ブラウザーでページを開けないとき、プロキシの問題とDNSの問題を見分けるには？
まずブラウザーの拡張機能や独自のプロキシ設定を介さず、コマンドでローカルプロキシを明示して接続します。以下はWindows向けです。クライアントが実際に127.0.0.1:10808でHTTPまたは混合プロキシを待ち受けていることが前提です。ポートが異なる場合は、クライアントに表示された値に置き換えてください。例のURLは接続確認用であり、すべてのネットワーク環境でアクセスできるとは限りません。
curl.exe -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:10808 https://example.com/- ローカル接続に失敗する場合：リクエストがまだプロキシに届いていません。待ち受けポートとコアの起動状態を確認してください。
- HTTPレスポンスヘッダーを受信した場合：今回のプロキシ指定リクエストに応答があったことを示しますが、すべてのサイトに接続できるとは限りません。引き続きブラウザー独自のプロキシ設定とセキュアDNSの設定を確認してください。
- プロキシ接続後にタイムアウトする場合：コアのログでノード、接続先アドレス、ルーティングルールを確認してください。ブラウザーのキャッシュが原因だと決めつけないでください。
- ログにドメイン名の解決エラーがある場合：クライアントのDNS設定と上流DNSサーバーへの接続を確認します。ノードのドメイン名と接続先サイトのドメイン名のどちらの解決に失敗しているかも確認してください。
SOCKS経由で調べる場合は、ローカルでの名前解決とプロキシ側での名前解決を区別します。curlのsocks5://は通常、接続先のドメイン名をローカルで解決します。socks5h://では、接続先のドメイン名の処理をプロキシ側に任せます。結果の違いは名前解決経路を特定する手がかりになりますが、DNSアドレスを適当に変更すればすべて解決するという意味ではありません。
7. ポートが使用中と表示されたら、どのプロセスを終了すればよい？
ポートが使用中だからといって、正体のわからないプロセスを終了しないでください。まずv2rayNの「設定」→「パラメータ設定」でローカルの待ち受けポートを確認してから、使用中のプロセスを調べます。この記事では10808を例にします。古い設定や別のインストール環境ではポートが異なる場合があるため、現在の画面と起動ログを基準にしてください。
netstat -ano | findstr :10808
tasklist /FI "PID eq 1234"最初のコマンドでは、LISTENINGを含む行を確認し、ローカルアドレスとポートを特定します。一番右の列がプロセスIDです。2つ目のコマンドにある1234は記述例にすぎません。実行前に、実際に確認したプロセスIDに置き換えてください。使用中のプロセスが別のクライアントの実行中インスタンスなら、重複している方を通常の方法で終了すれば問題ありません。
8～10. TUN、接続切れ、設定の共有への対処
サブスクリプション、待ち受け、ノードを確認してから、通信をプロキシに通す範囲と動作の安定性を調整します。次の3つの問題は、何度も再インストールして解決するものではありません。まず現在の状態を確認し、設定を変更する前に保存しておけば、必要な項目だけ元に戻せます。
8. TUNを有効にしないと使えない？
必ずしも必要ではありません。ブラウザーがシステムプロキシに従う場合は、まずシステムプロキシを使ってください。より多くのアプリの通信をプロキシ経由にする必要がある場合は、v2rayNのメイン画面でTUNを有効にし、システムの案内に従って必要な権限を許可します。有効にした後にネットワークへ接続できなくなった場合は、まずTUNを無効にして元の状態に戻し、仮想ネットワークアダプター、ルーティングの競合、DNSを確認してください。Android版のv2rayNGとv2flyNGはシステムVPNを通じて通信を処理します。初回接続時はVPNの許可を確認してください。デスクトップのシステムプロキシと同じ手順ではありません。
9. 最初は使えたのに、しばらくすると切断される場合は？
まず、スリープからの復帰後、Wi-Fiの切り替え後、またはネットワークの切り替え後に切断するかを記録します。ネットワークが復旧したら同じノードを再テストし、別のノードでも比較してください。Windowsでは電源とネットワークの状態を確認します。Androidでは画面消灯後だけ切断する場合、クライアントのバッテリー最適化とバックグラウンド実行制限を確認してください。すべてのノードが同時に使えなくなった場合は、まずローカルネットワークとコアのログを調べます。特定のノードだけが失敗する場合は、サーバーの状態、通信量の上限、接続数の制限を確認してください。
10. トラブルシューティングを頼むために、サブスクリプションURLを人に送ってもよい？
まず認証情報を隠したエラーログや設定画面のスクリーンショットを送ってください。サブスクリプションURL、ノードのQRコード、UUIDなどは、他人がノードを取得したり利用したりできる情報です。公開の場に送らないでください。スクリーンショットには、エラーの発生時刻、コアの種類、ポート、エラーの原文を残し、サブスクリプショントークン、パスワード、UUID、個人アカウント情報を隠します。サブスクリプションURL全体が漏えいした場合は、サービス提供元でURLを再発行し、クライアントに保存したアドレスも更新してください。
確認手順は次の順に進めます。基本ネットワークが使える → サブスクリプションに有効なノードがある → コアが起動し待ち受けている → アクティブノードに接続できる → アプリからローカルプロキシに接続できる → ルーティングとDNSが想定どおり。各段階で一度ずつ再テストしてください。ポート、プロトコル、ルーティング、DNSを同時に変更すると、原因を特定できなくなります。それでも解決しない場合は、「接続できない」とだけ伝えるより、OS、クライアントとコアのバージョン、発生時刻、機密情報を隠したログを管理者に共有するほうが問題を特定しやすくなります。