安定したVPNを選ぶとき、1回の速度テストで出た最高値だけを見るのは十分ではありません。長時間の利用を左右するのは、接続をスムーズに確立できるか、セッション途中で切断されないか、切断後に復旧できるか、そして混雑する時間帯に回線の状態が大きく変わらないかです。速度は速くても再接続を繰り返す回線は、会議やリモート文書作業、コードリポジトリ、長時間のストリーミングには向きません。速度が中程度でも接続が途切れにくい回線のほうが、実際の使い勝手は安定します。
本記事では、再現可能な実測方法を用い、特定の遅延値や固定の成功率を作りません。通信結果は、接続拠点の地域、国内通信事業者、接続先のWebサイト、時間帯、クライアントの実装によって変わります。回線タイプ、プロトコル、利用環境を分けて検証し、記録から問題の区間を判断する方法がより確実です。
安定性を判断する指標
「接続できる」ことは最低条件にすぎません。安定性テストでは、接続の確立、継続的な通信、異常からの復旧まで確認する必要があります。接続後に1回だけダウンロードテストを行うと、初回接続の失敗、スリープ復帰の失敗、ネットワーク切り替え後の停止といった、より起こりやすい問題を見落とします。
| 確認項目 | 記録方法 | 主な意味 |
|---|---|---|
| 接続成功率 | 切断と再接続を繰り返し、成功回数と失敗回数を記録する | 接続拠点への到達性、ハンドシェイクの互換性、サーバーの応答状況を示す |
| 切断率 | セッションを継続し、予期しない中断や手動再接続が必要になった回数を記録する | 経路の揺らぎ、セッション維持、クライアントのバックグラウンド動作能力を示す |
| 復旧能力 | 国内ネットワークの切り替え、端末の復帰、一時的な接続断の後に復旧の過程を確認する | 自動再接続が機能した状態、見かけだけの接続、クライアントの再起動が必要な状態を区別する |
| 変動幅 | 継続アクセス中の遅延変化、停止、スループットの揺れを比較する | 短時間の速度テストだけで良好に見える回線かどうかを判断する |
| 名前解決の一貫性 | 接続前後でDNSの解決元と対象ドメインの結果を確認する | 迂回した名前解決、地域判定の不一致、DNS漏洩の可能性を見つける |
接続成功率は、接続を確立できた回数を試行総数で割って求められます。切断率は有効なセッションの記録をもとに算出し、意図的な回線切り替えを異常切断に含めないようにします。テストでは「トンネルが確立した状態」と「接続先にアクセスできる状態」も区別が必要です。クライアントに接続済みと表示されても、DNS、ルーティング、デフォルトルートが正しく機能しているとは限りません。
低遅延でも切断が少ないとは限らない
遅延は主にデータの往復にかかる時間を示します。一方、切断はパケットロス、NATセッションの失効、接続拠点での遮断、プロトコルのハンドシェイク失敗、クライアントの動作停止などが原因で起こります。低遅延でも継続通信中に接続を頻繁にリセットする回線がある一方、遅延はやや高くても経路が安定し、揺らぎの少ない回線は長時間のセッションに向いています。回線を選ぶ際は、到達性、継続性、復旧能力を同時に確認しましょう。
再現可能な安定性テストの進め方
公平に比較するには、変数を管理することが重要です。端末、クライアント、プロトコル、接続拠点、国内ネットワークを同時に変えると、結果が変わっても本当の原因を特定できません。まず端末とクライアントを固定して回線だけを変え、次に回線を固定してプロトコルと通信方式を順番に比較するのがおすすめです。
- 同じ端末、同じクライアントのバージョン、同じシステムネットワーク設定を使う。
- 経路を変える他のプロキシ、アクセラレーター、重複するトンネルを先に停止する。
- 同じ接続先を選び、対象Webサイト側の障害を回線断と誤認しないようにする。
- 通常の利用時間帯と混雑しやすい時間帯を含め、1回の短時間テストだけで結論を出さない。
- 切り替えるたびに、出口アドレス、DNSの名前解決、ルーティングルールが想定どおり変化したことを確認する。
- クライアントログにあるハンドシェイク失敗、タイムアウト、再接続、ルーティングエラーの情報を保存する。
接続成功率を測るときは、古いセッションを完全に切断してから新しい接続を開始します。既存のトンネル内で設定だけを切り替えるクライアントでは、古い接続のキャッシュが接続拠点の問題を隠すことがあります。切断率を測るときは、Webページの継続読み込み、文書の同期、ストリーミング再生など、実際の通信を維持してください。トンネルをアイドル状態にするだけでは不十分です。
比較が終わったら、「速い」「遅い」という主観的な印象だけを残さないようにします。各回線について、接続の成否、停止の有無、自動復旧の有無、プロトコル切り替えの必要性、障害発生時に国内ネットワークも同時に異常だったかを記録できます。具体的な数値を公開しなくても、こうした生の記録は1枚の速度画面より長期的な状態をよく示します。
実測結果は、テスト時点の国内ネットワークと接続経路を示すものにすぎません。回線の評価には再テストの余地を残し、特定の地域や時間帯の結果をすべての利用者にそのまま当てはめないようにしましょう。
直結・中継・IEPL専用線の違い
回線構成によって障害が発生しやすい箇所は変わります。直結、中継、IEPL専用線は単純な速度の等級ではなく、接続拠点の制御、国際経路、迂回のしやすさに明確な違いがあります。これらを理解してこそ、同じ出口地域でも回線タイプによって結果が異なる理由を説明できます。
| 回線タイプ | 経路の特徴 | 安定性の見方 | 適した用途 |
|---|---|---|---|
| 直結 | 国内ネットワークから海外の接続拠点または出口へ直接アクセスし、経路はパブリックインターネットの制御に依存する | 経路はシンプルだが、混雑する時間帯、ネットワーク間接続、国際出口の変化が接続状態に直接反映される | 一時的なアクセス、経路の変動を比較的許容できる作業 |
| 中継 | 近隣または制御しやすい接続拠点に入った後、中継区間を経由して海外の出口へ送る | 接続拠点を管理しやすく、公共ネットワークの変動に応じて後続経路を調整できる場合がある | 日常的なWeb閲覧、リモート協業、継続的な接続 |
| IEPL専用線 | 国境をまたぐ主要区間に専用の伝送路を使い、一般的な国際パブリックネットワークへの依存を減らす | 経路は比較的固定され、混雑や迂回の影響を抑えやすいが、最終的な状態は国内の接続環境と出口側にも左右される | 長時間のセッション、継続的な通信、変動の影響を受けやすい業務 |
IEPL専用線だからといって、アクセス全体がパブリックインターネットから切り離されるわけではありません。端末から接続拠点まで、また海外の出口から対象サービスまでには通常のネットワークが使われる場合があります。そのため、国内のパケットロス、接続拠点の混雑、対象Webサイトの障害によって停止することもあります。より正確には、IEPLは国際区間の主要部分に、より制御しやすい経路を提供するものであり、ネットワークの変数をすべてなくすものではありません。
中継回線の品質は、接続拠点の位置、中継区間の伝送品質、出口の振り分けによって決まります。接続拠点が国内ネットワークに近くても中継区間が混雑すれば、接続は不安定になる可能性があります。反対に、接続拠点がやや遠くても国際区間が安定していれば、全体の継続性が高くなることがあります。直結は通信事業者の国際ルーティングに左右されやすいため、比較用の基準や、中継拠点に一時的に接続できない場合の予備として使えます。
プロトコルが接続成功率に与える影響
プロトコルはハンドシェイクの方法、通信特性、輻輳制御、パケットロスへの耐性に影響しますが、プロトコル名だけで回線品質を判断することはできません。品質の低い国際経路は、プロトコルを変えただけで安定するわけではありません。同様に、良好な専用線でもクライアント設定を誤れば接続を確立できないことがあります。
Shadowsocks、VMess、Trojan、VLESS
Shadowsocksは構成が比較的シンプルで、対応クライアントも多く、一般的なプロキシ利用やルーティングに適しています。実際の安定性は、暗号方式の互換性、サーバー実装、基盤となるTCPなどの通信経路に大きく左右されます。VMessは以前から使われてきた設定体系で、認証や時刻検証の仕組みを備えています。端末の時刻ずれ、通信層の設定不一致、古いクライアントの互換性問題は、ハンドシェイク失敗の原因になります。
Trojanは通常TLS上で通信するため、証明書、ドメイン、システム時刻、サーバー名の設定を一致させる必要があります。証明書の検証に失敗している場合、再接続を繰り返しても設定ミスは解決しません。VLESSは認証をシンプルにする設計で、さまざまな通信方式と組み合わせられます。柔軟性が高い一方、クライアントとサーバーで通信層、暗号化層、関連パラメータを完全に一致させる必要があります。
Hysteria2とTUIC
Hysteria2とTUICはQUICやUDPに関連する仕組みを利用するため、遅延が大きい経路や一定のパケットロスがある環境では、従来のTCP over TCPより柔軟に動作する場合があります。ただし、すべてのネットワークで安定するわけではありません。国内ネットワークによってはUDPが制限され、ルーターの長時間UDPセッションの維持能力にも差があります。ハンドシェイクが常に失敗する、接続直後に切れる、TCP系プロトコルだけ使えるといった場合は、出口地域を何度も変える前にUDPの到達性を確認しましょう。
プロトコルの比較は、同じ接続拠点と同じ出口で行います。プロトコルを変えると同時にノードも変えた場合、結果には回線の違いも混ざります。実測では、まず互換性の高い設定で基準を作り、その後で別のプロトコルが復旧速度、変動、継続通信を改善するか確認できます。
DNS、ルーティング、見かけだけの接続
「接続済みなのに開けない」問題の多くは、回線の切断ではなく、DNSやルーティングがトンネルに追従していないことが原因です。クライアントがプロキシ接続を確立しても、システムがローカルのリゾルバーへ直接問い合わせ続けると、出口に適さない結果が返されたり、DNS漏洩が起きたりすることがあります。この場合、出口アドレスは変わっていても、ドメインの名前解決はトンネルの外で行われています。
DNSを確認するときは、接続前後の解決元を比較し、プロキシのドメイン、対象ドメイン、システムが頻繁に使うドメインが想定どおり処理されているか確認します。Webページに表示された出口アドレスだけでは、DNSがトンネル内に入っているか判断できません。クライアントがリモートDNSをサポートしている場合は、問い合わせが実際にプロキシ側で処理されているか確認してください。システムDNSを使う場合は、OSが異なるネットワークインターフェースへ並行して問い合わせる可能性も把握しておく必要があります。
ルーティングルールには通常、直結、プロキシ、拒否などの動作が含まれます。ルールの順序を誤ると、対象ドメインが先に直結ルールへ一致することがあります。範囲が広すぎると、国内サービスまで海外の出口へ送られ、遅延や接続不能を招く場合があります。ルールを変更した後はDNSキャッシュを消去し、接続を再確立してください。古い解決結果がテストに影響し続ける可能性があります。
対象ドメイン → ルール照合 → DNS名前解決 → 接続拠点の選択 → トンネル確立 → 出口への到達 → 対象へのアクセス見かけだけの接続を切り分けるときは、この経路を区間ごとに確認します。接続拠点との接続を確立できない場合は、国内ネットワーク、プロトコル、サーバーパラメータを重点的に確認します。接続拠点にはつながるのにすべてのドメインで失敗する場合は、DNSとデフォルトルートを確認します。一部のWebサイトだけ失敗する場合は、ルーティングの一致、対象地域の制限、対象サービス自体の状態を確認します。
プラットフォームごとにクライアントの動作が異なる理由
同じサブスクリプションURLを別のクライアントへ読み込んでも、回線の結果が完全に一致するとは限りません。サブスクリプションURLには通常、ノードアドレス、ポート、プロトコル、通信パラメータが含まれますが、システムトンネルの構築、DNSの処理、ルールの適用、バックグラウンド接続の維持方法はクライアントの実装に依存します。
Windowsのクライアントでは、システムプロキシ、仮想NIC、既存のネットワークフィルターの関係を処理する必要があります。システムプロキシだけを有効にすると、プロキシ設定に対応しないアプリは直結を続けることがあります。仮想NICモードではルーティングをより広く適用できますが、セキュリティソフト、仮想マシン、他のトンネルと併用する場合はルートの競合を確認してください。
macOSでは、ネットワーク拡張とシステムプロキシに明確な権限が必要です。権限が十分に付与されていないと、クライアント画面でサブスクリプションを読み込めても、実際には通信を制御できないことがあります。システムのスリープ復帰後は、ネットワーク拡張が復旧しているか、古いDNS設定が残っていないかも確認します。
iOSとAndroidのクライアントは通常、OSが提供するVPNインターフェースを通じてトンネルを作成します。バックグラウンド制限、省電力設定、ネットワーク切り替えはセッション維持に影響します。テストでは、Wi-Fiからモバイルネットワークへ切り替えた後に自動復旧するか、復旧後も出口とDNSが想定どおりかを確認してください。
Linux環境の違いは主に、ディストリビューションのネットワーク管理方式、ファイアウォール、ルーティングテーブル、DNSサービスに起因します。コマンドラインクライアントはログを読みやすい一方、システムプロキシ、透過転送、仮想インターフェースを明確に管理する必要があります。端末の環境変数だけを設定しても、GUIアプリが同じプロキシ経路を自動的に継承するとは限りません。
サブスクリプション読み込み後の確認
- サブスクリプションを更新したら、古いキャッシュではなくノードパラメータが更新されていることを確認する。
- クライアントがサブスクリプションで使われているプロトコルと通信方式に対応しているか確認する。
- 更新時にルーティングモードが不適切なデフォルト値へ戻っていないことを確認する。
- 再接続後に出口、DNS、ログを確認し、ノード名だけで成功と判断しない。
- サブスクリプションURLが漏洩した場合は、サービスパネルでURLを更新し、クライアントから古いアドレスを削除する。
サブスクリプションURLは設定を取得するための入口であり、アクセス認証情報を含む場合があります。公開共有したり、公開コードリポジトリに置いたりしないでください。クライアントへの読み込みに失敗した場合は、まずURLを正常に更新できるかを確認し、その後でサブスクリプション形式とクライアントの互換性を確認します。ノード一覧に表示されても、すべての設定で実際のハンドシェイクが成功したとは限りません。
切断時の切り分け手順
安定性のトラブルシューティングは、端末に最も近い場所から始めます。いきなり出口を変えると一時的に問題を回避できても、障害が国内のWi-Fi環境、接続拠点、国際区間、対象Webサイトのどこにあるか判断できません。
- まず国内ネットワークを確認：切断時に通常のWebページやLANも同時に異常になっていないか確認します。国内接続そのものが切れている場合、プロトコルを変えても解決しません。
- 次に接続拠点を確認：出口地域を固定したまま、別の接続拠点または回線タイプへ切り替えます。特定の接続拠点だけ失敗するなら、問題はアクセス区間にある可能性が高くなります。
- 国際区間を確認：直結、中継、IEPLの経路を継続的に比較し、混雑が特定の経路に集中していないか確認します。
- プロトコルを確認：同じ回線でTCP系とUDP系の方式をテストし、ログからハンドシェイク、タイムアウト、セッション維持の問題を判断します。
- DNSとルールを確認：トンネルがオンラインなのに対象へ接続できない場合は、名前解決の結果とルーティングの動作を確認します。
- 最後に対象サービスを確認：1つのWebサイトだけが異常な場合、VPN接続全体の障害だとすぐに判断しないでください。
切断後もクライアントがオンラインと表示され、すべてのリクエストが停止している場合は、手動で再接続し、ログでハンドシェイクが再完了するか確認します。アプリを再起動しないと復旧しない場合は、クライアントの状態、仮想インターフェース、OSのネットワーク拡張が関係している可能性があります。国内ネットワークを切り替えると復旧する場合は、元のネットワークが特定のプロトコルやUDPをどのように扱っているか、さらに確認が必要です。
リモート会議や文書同期など長時間のセッションでは、クライアントにネットワークロックや切断保護があれば有効にできます。トンネルが無効になった後、通信が自動的に通常のネットワークへ戻るのを防ぐ機能です。ただし、ルーティングの要件と合わせてテストしてください。ルールが厳しすぎると、国内サービスへのアクセスまで妨げることがあります。
実測結果と回線選びのポイント
接続成功率と切断率を比較すると、安定しやすい選択肢には、到達可能な接続拠点、制御しやすい国際経路、現在のネットワークに合うプロトコル、DNSと再接続を正しく処理できるクライアントという共通点があります。IEPL専用線は継続性を重視する作業、中継回線は日常的な海外アクセス、直結は軽量な用途や障害比較に向いています。ただし、最終的な順序は国内ネットワークでの再テストを基準にしてください。
選ぶときは、1本の回線だけに頼らないようにしましょう。異なる接続拠点、回線タイプ、互換性のあるプロトコルを用意しておけば、国内ネットワークの状態が変わったときにもすばやく切り替えられます。主回線は長時間の連続利用で決め、予備回線はノード名が存在するかではなく、接続成功率と復旧能力を確認してください。