設定をインポートして接続できるものの、ページの表示待ちやダウンロードの停止、バックグラウンドでの切断が起きる場合に役立つ内容です。まずテスト条件を固定し、ノードとネットワークを比較したうえで、プロキシの入口、ルーティング、DNSを確認します。変更は一度に1項目だけにし、ログと繰り返しのリクエストで原因を見極めましょう。ノード一覧の遅延値だけで実際の通信速度を判断しないことも大切です。
1. 接続の遅さ・転送の遅さ・バックグラウンド切断を見分ける
「速度が遅い」だけでは、原因を特定できません。ページを初めて開くときに時間がかかるなら、名前解決や接続確立の段階が原因かもしれません。ページは表示されてもファイル転送がたびたび止まる場合は、回線の混雑やサーバー側の出口を確認しましょう。画面ロック後に切断されるなら、まずバックグラウンド動作の制限を調べます。現象を分類してから対処すれば、すべてをノードの問題と決めつけずに済みます。
テスト前にほかのダウンロードやクラウド同期を停止し、同じ端末・接続ネットワーク・アクセス先で比較します。普段から安定していて、アクセスする権限のあるサイトを使い、単一サイトの一時的な不具合だけで回線全体を判断しないでください。クライアントのバージョン、コア、ノード名、発生時刻を記録します。クライアントやコアの更新も条件変更のひとつです。ルーティング設定の変更と同時に行わないようにしましょう。
| 確認できる症状 | 優先して確認する項目 | 比較方法 |
|---|---|---|
| 初回の表示は遅いが、2回目以降は正常 | DNS、ハンドシェイク、アクセス先の応答 | 初回と再リクエスト時の応答を比較 |
| ページは表示されるが、転送がたびたび止まる | ノードの出口、接続回線、端末の負荷 | 同じネットワークでノードを変更して再テスト |
| 特定のアプリだけ遅い | アプリのプロキシ設定、アプリ別ルール | ブラウザーと対象アプリのログを比較 |
| 画面ロック後に切断し、画面を点けると復帰 | 省電力設定、バックグラウンド通信の権限 | アプリを前面に表示したまま接続して比較 |
ノード一覧に表示されるTCP遅延は、通常、ポートへの接続にかかる時間を示すだけです。「実際の接続遅延」も、クライアントが選ぶテスト先に左右されます。どちらも継続的なデータ転送の速さを直接示すものではありません。1回のタイムアウトはテスト先が利用できない可能性があり、遅延が小さくてもノードの出口に余裕があるとは限りません。
2. ノードの切り分け：利用可否とサーバーの状態を比較
まず同じネットワークでノードAとノードBを比較します。可能なら、サーバーアドレスや出口が異なる設定を選びましょう。ノード名が違っても、実際の経路が異なるとは限りません。サブスクリプション内の複数ノードが同じ入口を共有している場合もあります。多数のノードを同時に速度測定してすぐ結論を出すのは避けてください。同時テストそのものが帯域や接続リソースを消費します。
- サブスクリプションが有効か確認します。v2rayNの「サブスクリプショングループ」で該当グループを更新し、更新失敗、期限切れ、通信量の上限到達などの表示がないか確認します。更新後はテストするノードを選び直し、置き換え済みの古い項目を使わないでください。
- ノードの設定を確認します。サービス提供元の案内に従い、アドレス、ポート、認証情報、TLS、サーバー名、通信設定を確認します。VMessとVLESSはプロトコルの種類であり、速度の段階ではありません。プロトコル名だけを変更して、別の設定を流用することはできません。
- サーバーの状態を確認します。サーバーを自分で管理している場合は、CPU、メモリ、送信帯域、接続数、サーバーログを確認します。サービス提供元が管理している場合は、発生時刻と個人情報などを伏せたエラー記録を添えて、利用制限や出口の障害がないか問い合わせましょう。
- 時間帯を変えて再テストします。同じ設定でも特定の時間帯だけ遅くなる場合、ノードの負荷や上位回線の混雑が考えられます。条件をそろえて再度確認し、すぐにクライアントを再インストールしないでください。
結論：まずノードの問題か切り分け、端末設定は急いで変更しない
同じ端末・同じネットワークでノードAだけが継続して不調で、ノードBが正常なら、まずAの設定とサーバーの状態を確認します。ただし、この結果だけではサーバー負荷とサーバーまでの回線の問題を区別できません。
v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。通信方式やセキュリティ設定への対応状況は、コアのバージョンによって異なります。インポート後に未対応の項目が表示されたり起動に失敗したりする場合は、まず互換性を確認してください。接続数を増やしても解決する問題ではありません。
3. 回線の切り分け：ノードを固定して接続ネットワークを変更
ノードの比較が済んだら、ノードAを固定して自宅のネットワークと別の利用可能なネットワークを比較します。スマートフォンでWi-Fiとモバイルデータ通信を切り替える場合は、クライアントが再接続したことを確認してから、同じサイトにアクセスしてください。パソコンではスマートフォンのテザリングも比較に使えますが、通信量に注意しましょう。
- 特定のWi-Fiだけで不調：アクセスポイントに近づくか、有線接続に切り替えます。まずWi-Fiの電波状態、ルーターの負荷、ほかの端末による帯域の使用を除外してから、上位回線を調べましょう。
- 同じノードでネットワークを変えると復旧：ノードのサーバー障害と決めつけず、接続ネットワークからノードまでの経路を優先して調べます。
- 複数のネットワークで特定のサイトだけ遅い：サイト自体の状態、地域による出口の違い、ルーティングルールの適用結果を確認します。
- UDPを使う通信だけ不調：アプリの接続入口、コアの設定、接続ネットワークが該当する通信に対応しているか確認します。ブラウザーでページを表示できても、すべての通信が正常とは限りません。
通信方式はサーバー側の設定と一致させる必要があります。たとえば、サーバーがWebSocketを使用する場合は、パスとHostを正しく設定します。TLSを有効にする場合は、サーバー名と証明書の検証も設定要件を満たさなければなりません。通信レイヤーの設定ミスはハンドシェイクの失敗や再試行につながり、利用者には長い待ち時間として現れることがあります。
通常のpingとプロキシ経由の接続では、使われる通信が異なります。サーバーがpingに応答しなくても、プロキシのポートが使えないとは限りません。pingが正常でも、アプリのリクエストが完了するとは限りません。回線を判断するときは、実際のリクエストとコアのログを照らし合わせ、遅延の数値だけに頼らないでください。
4. 端末側の切り分け：プロキシの入口とルーティングを確認
v2rayNの「システムプロキシ」と「ルーティング」は、それぞれ別の役割を担います。システムプロキシは、システム設定に従うアプリにローカルの接続先を知らせます。ルーティングは、コアが受け取ったリクエストをプロキシ経由、直接接続、またはブロックのどれにするかを決めます。システムプロキシを有効にしても、すべてのアプリが利用するとは限りません。また、すべてのアクセス先がプロキシ経由になるわけでもありません。
- 待ち受けポートを確認します。「設定」→「パラメーター設定」でローカル待ち受けに関する項目を確認するか、起動ログを参照します。以下ではHTTPプロキシを提供する
127.0.0.1:10808を例にします。実際のポートと入口の種類は、現在の設定に従ってください。 - システムプロキシを確認します。メイン画面の「システムプロキシ」で「システムプロキシを自動設定」を選択します。切り分け中は、ローカルの入口を明示したリクエストで比較し、ブラウザー拡張機能独自のプロキシ設定が影響しないようにします。
- ルーティング結果を確認します。現在のルーティングモードとカスタムルール、特に先に適用されるドメイン・IP・アプリのルールを確認します。テスト中は対象が確実にプロキシ経由になるルールを一時的に使い、終了後に元のモードへ戻してください。
- ほかの接続入口を確認します。TUNを有効にしている場合は、まず状態を記録し、通常のローカルプロキシ入口と個別に比較します。複数のプロキシソフトにシステムプロキシや仮想ネットワークの入口を同時に管理させないでください。
Windowsのターミナルで以下のリクエストを実行すると、「アプリがシステムプロキシを参照しているか」という不確定要素を避けて確認できます。コマンド内のexample.comは公開されている例示用ドメインです。このリクエストは通信経路の確認用であり、帯域の測定には使いません。現在の入口がSOCKSのみ対応している場合は、HTTP入口のコマンドをそのまま使わず、対応するSOCKSのパラメーターを指定してください。
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --head https://example.com
netstat -ano | findstr ":10808"1つ目のコマンドは、接続待ち時間を10秒、全体の待ち時間を30秒に制限します。タイムアウトは今回の観察結果にすぎず、サーバー負荷を直接示すものではありません。2つ目のコマンドでは、ポートに関連する接続を確認します。該当ポートの待ち受け記録とPIDがあるかを重点的に見てください。プロキシを明示したリクエストは正常なのにブラウザーだけ不調なら、プロキシ拡張機能、古い自動設定スクリプト、アプリ独自のネットワーク設定を優先して確認します。
5. DNSとAndroidのアプリ別設定：リクエストがコアに届くか確認
名前解決の問題では、初回アクセスに時間がかかったり、一部のドメインだけ失敗したりすることがあります。ノードへの接続前に行うサーバーアドレスの名前解決と、アクセス先サイトの名前解決を区別してください。前者に失敗するとノードに接続できず、後者の場合は一部のアクセス先だけに影響することがあります。どちらも同じDNS経路を使うとは限りません。
- どのドメインでエラーが起きたか確認します。失敗したのがノードのアドレスか、アクセス先のドメインかを確認します。ログを共有する際は、個人用ドメイン、サブスクリプションURL、認証情報を伏せてください。
- DNSとルーティングの組み合わせを確認します。v2rayNの「設定」にあるDNS関連の画面で現在の設定を確認します。項目名や場所はバージョンによって異なる場合があります。DNSサーバーに接続できるか、DNS自体の通信を直接接続とプロキシ経由のどちらにする必要があるかを調べましょう。
- アプリ独自の名前解決にも注意します。ブラウザーのセキュアDNS、アプリ内蔵の名前解決、システムDNSでは、異なる経路が使われることがあります。一度に変更するのは1項目にし、該当アプリを再起動してから再テストしてください。
- 出所不明の設定をそのまま使わないでください。リモートDNSがプロキシに依存し、ノードのアドレス解決もそのDNSに依存する場合、設定によっては起動時に依存関係の問題が起きます。まずノードのアドレスを初期段階で解決できることを確認しましょう。
Androidでは、テスト対象のアプリがVPN経由になっているかも確認します。v2rayNGの「設定」→「アプリ別プロキシ」で、機能の有効・無効、対象アプリ、「バイパスモード」の状態を確認してください。アプリ別プロキシを有効にし、バイパスモードを無効にすると、選択したアプリはプロキシを使用します。バイパスモードを有効にすると、選択したアプリはプロキシを経由しません。変更後は接続を停止して再接続し、同じアプリでテストします。
画面ロック後だけ問題が起きる場合は、システムの「設定」→「アプリ」→「v2rayNG」にあるバッテリーまたはバックグラウンド管理の画面で、バックグラウンド動作を許可します。項目名は端末によって異なります。VPNの許可が有効なままか、別のVPN接続に置き換わっていないかも確認してください。v2flyNGでもシステムのVPNとバックグラウンド権限を確認しますが、v2rayNGと同じアプリ内メニューがあるとは限りません。
結論：アプリのリクエストがコアに届かない場合は、まず接続入口を確認
必要なレベルの接続ログが有効なのに、テストリクエストに対応する記録がない場合は、まずシステムプロキシ、VPN、アプリ別設定を調べます。この場合、接続先のノードを変更しても、アプリがプロキシを迂回する問題は解決しません。
6. ログのエラーから、待ち時間が発生した段階を特定
クライアントのログで、リクエスト直前から直後までの記録を残し、最も内側のエラーと宛先を確認します。同じエラー表記でも、発生した段階によって対処方法は異なります。ローカルプロキシへの接続拒否と、リモートサーバーへの接続拒否では、確認すべき場所がまったく違います。以下はよくあるエラーの一部です。完全なログには時刻、プロトコルスタック、アドレスなども含まれます。
エラー：connection refused
原因と対処：接続先のポートが接続を拒否しているか、サービスが待ち受けていません。まずアドレスがローカルかリモートかを確認します。ローカルならコアの起動状態とポートを、リモートならノードのポートとサービスの状態を調べましょう。
エラー：i/o timeout
原因と対処：ネットワークの読み取りまたは書き込みが、待ち時間を超過しています。前後のログから、名前解決・接続・応答のどの段階で起きたかを特定し、ノードを固定してネットワークを切り替え比較します。このエラー表記だけでノードの停止と判断しないでください。
エラー：address already in use
原因と対処：待ち受けに使うアドレスとポートがすでに使用されています。ポートを調べて該当プロセスを特定し、重複して起動したプロセスを終了するか、待ち受けポートを変更します。システムプロキシとアプリの接続先も合わせて変更してください。
エラー：x509: certificate has expired or is not yet valid
原因と対処：証明書の有効期間の検証に失敗しています。端末の時刻が誤っている可能性もあります。まずシステムの日付とタイムゾーンを同期し、それでも解決しなければサーバー証明書を確認してください。通常の対処として検証を無効にするのは避けましょう。
必要な場合は一時的にログの詳細度を上げ、問題を再現したら通常のレベルに戻します。アクセス情報を長期間記録しすぎないようにしてください。サービス提供元に問い合わせる際は、「速度が遅い」とだけ伝えるのではなく、クライアントとコアのバージョン、発生時刻、接続ネットワークの種類、ノードの比較結果、個人情報などを伏せたエラー記録を添えると、原因を特定しやすくなります。
7. よくある質問と最終チェックの手順
ノードの遅延は小さいのに、ページの読み込みが終わらないのはなぜ？
遅延テストだけでは、ページ全体のリクエストが正常かどうかは分かりません。まずローカルプロキシを明示したリクエストで経路を確認し、ブラウザーが同じ入口を使っているか、対象ドメインが想定した出口へルーティングされているかを調べます。最後に別のサイトでも比較してください。
グローバルプロキシに切り替えたら直りました。このまま使い続けるべきですか？
まずはルーティングの比較結果として捉えましょう。元のモードに戻し、そのドメインに適用される直接接続ルール、IPルール、ルールの順序を確認して、該当する項目だけを調整します。グローバルプロキシは、DNSや回線のあらゆる問題を解決する設定ではありません。
パソコンは正常なのにスマートフォンだけ遅い場合、スマートフォンのノードが非対応なのでしょうか？
まず両方の端末を同じWi-Fiと同じノード設定で接続し、スマートフォンのVPN許可、アプリ別プロキシ、省電力制限を確認します。未対応項目やハンドシェイクエラーがある場合に限り、コアのバージョンと設定の互換性を詳しく調べましょう。
DNS、ポート、ルーティングを変更したら接続できなくなりました。どうすればよいですか？
変更履歴を見ながら、項目ごとに元へ戻し、まず起動できる設定を復元します。待ち受けポートとプロキシの入口が一致していることを確認し、ルーティングとDNSも元に戻します。各変更後に再接続してテストし、調整を重ねないようにしてください。
- 症状とテスト条件を記録し、クライアントのコアが正常に起動していることを確認します。
- 同じネットワークでノードを2つ比較し、次にノードを固定してネットワークを2つ比較します。
- システムプロキシまたはVPNの入口を確認し、テスト対象のアプリが実際にコアへ接続していることを確かめます。
- ルーティング、DNS、通信設定を確認し、ログから具体的な失敗箇所を特定します。
- 有効だった変更だけを残し、効果のなかった試行は元に戻します。サーバーまたは回線に原因があると判断できる場合に限り、該当する調査記録を添えて問い合わせます。