「安定した VPN のおすすめ」を検索しても、多くの記事が示すのは結論だけで、計測の定義ではありません。「この回線は安定している」「夜は切れる」も、数値化された基準がなければ比較も再現もできません。本記事では安定性を接続成功率・切断率・ピーク時の再接続時間という自分で計測できる3つの指標に分解し、回線タイプとプロトコルがそれぞれどんな役割を担うのかを整理したうえで、自宅でそのまま実行できる計測手順を紹介します。
安定性は運任せではない:計測できる3つの指標
接続成功率が示すのは「つながるかどうか」です。接続を開始してから使えるセッションが確立するまでの割合を指します。失敗は名前解決、ハンドシェイク、認証のどの段階でも起こり得るため、この数値が下がったからといってノードの問題だと断定はできません。切断率が示すのは「つないだ後どれだけ持つか」で、一定の観測時間あたりに意図せず切断された回数です。ピーク時の再接続時間が示すのは「切れてからどれだけで戻るか」で、切断後に使えるセッションを再確立するまでの秒数を指します。
3つの指標はそれぞれ別の問いに答えるもので、組み合わせて初めて回線の実際の体験を表せます。1つだけを見ると誤った結論を導きやすくなります。成功率が高くても再接続が遅い回線は長時間の接続に不向きで、逆に切断が多くても毎回すぐ復帰する回線は、Web 閲覧ではほとんど気になりません。
| 指標 | 答える問い | 計測方法 | 注目点 |
|---|---|---|---|
| 接続成功率 | つながるかどうか | 決まった時間帯に連続して複数回接続し、成功回数とハンドシェイク時間を記録する | ピーク時に他の時間帯より明らかに低くならないか |
| 切断率 | つないだ後どれだけ持つか | 長い接続を維持してハートビートログを記録し、切断ごとに時刻を記す | 切断が同じ時間帯や同じネットワークに集中していないか |
| ピーク時の再接続時間 | 切れてからどれだけで復帰するか | 切断後すぐに再接続し、開始から利用可能になるまでの秒数を記録する | 日中を基準に何倍の差があるか |
接続成功率の測り方:時間帯とサンプル数を固定する
接続成功率は最も測りやすく、最も間違えやすい指標です。サンプル数が少なすぎたり、時間帯がばらついたり、「アイコンが緑になった」を成功とみなしたりすると、数値の意味が失われます。以下はそのまま実行できる手順です。
- 期間を固定:7日間連続で、毎日3つの時間帯(午前、20:00–23:00、深夜)にそれぞれ1回ずつ計測します。
- サンプルを固定:各時間帯に同じ回線へ30回接続し、毎回同じ対象サイトにアクセスして利用可能かを確認してから切断します。
- 記録項目を固定:記録するのは4項目だけ——タイムスタンプ、成功したか、ハンドシェイク時間、失敗時のエラーメッセージです。
- 算出方法を固定:成功率 = 成功回数 ÷ 総回数。日中とピーク時は別々に計算し、1つの数字にまとめないでください。
「成功」の判定はクライアントのアイコンだけではできない
クライアントが「接続済み」と表示しても、それはローカルのトンネルが確立したことだけを意味し、通信が実際に出口から出ているかは分かりません。判定基準は事前に決めておく必要があります。接続を確立したら実際のリクエストを1回送り、応答が返ってきて初めて成功とみなします。たとえば1回のリクエストの所要時間を記録します:
curl -sS -o /dev/null -w '%{time_total}s\n' https://example.com/このリクエストがタイムアウトした場合、クライアントのアイコンが緑でも失敗として記録します。同様に、接続の可否を ping で判断しないでください。ICMP が通ってもプロキシトンネルが使えるとは限らず、そもそも ping を拒否するノードも少なくありません。
「クライアントが緑になった」や ping の応答を成功の基準にすると、失敗サンプルが体系的に成功として数えられ、計測された成功率は明らかに高くなり、以降の比較がすべて歪みます。
切断率とピーク時の再接続時間:長い接続をどう観察するか
切断率は長い接続を維持した状態で観察する必要があります。プロキシのセッションは本質的に1本の長い接続で、アイドル時には経路上の機器に回収されることがあり(NAT テーブルのエントリ切れ)、クライアントはハートビートで維持しています。したがって切断は2種類に分けられます。1つは自分でネットワークを切り替えたり、画面ロックやスリープで起きた能動的な切断。もう1つは経路側やサーバー側による回収です。切断率に数えるのは後者だけで、そうしないと自分の操作で数値が汚れます。
ピーク時の再接続時間は20:00–23:00の時間帯に測る必要があります。国際回線の混雑が最も集中する時間帯で、共有経路の待ち行列によって再接続が明らかに遅くなります。記録方法は簡単です。切断が起きたらすぐ再接続し、ログのタイムスタンプで開始から利用可能になるまでの秒数を記録し、日中の同じ回線の基準値と比較します。
- ✅ クライアントのログにある切断タイムスタンプを使い、「昨夜何回切れた」という記憶に頼らない。
- ✅ Wi-Fi の切り替えやモバイルネットワークの切り替えによる切断は別途印を付け、切断率には数えない。
- ✅ 少なくとも7日間連続で観察する。1晩のデータに代表性はない。
- ❌ 画面ロック後に OS がバックグラウンド接続を回収したのを回線の切断とみなす。
- ❌ 1台の端末だけで結論を出す——5つのプラットフォームでクライアントのキープアライブと再接続の方針は同じではない。
回線タイプが安定性をどう決めるか:IEPL 専用線、中継、直結
回線タイプは安定性の差が最も大きく出る要因で、プロトコルの選択よりも直接的に影響します。同じ「日本」と表示された2つのノードでも、データが通る経路はまったく異なることがあります。
| 回線タイプ | データ経路 | 安定性の特徴 | 向いている用途 |
|---|---|---|---|
| IEPL 専用線 | 両端を通信事業者の国際専用線で接続し、公共インターネットの国際出口を経由しない | ピーク時の変動が比較的小さく、長い接続が中間機器に回収されにくい | リアルタイム操作、長時間の常時接続 |
| 中継 | まず中継入口に接続し、最適化された経路で海外の出口ノードへ出る | 直結より1ホップ多く、性能は中継入口の品質に左右される | 日常のブラウジング、オンライン動画 |
| 直結 | クライアントが海外の出口ノードへ直接接続し、全区間を公共インターネット経由で通る | コストが低く範囲も広いが、ピーク時は国際出口の混雑の影響を受けやすい | 予備回線、ピーク外の時間帯 |
はっきりさせておきたいのは、直結=不安定ではなく、専用線=揺らぎゼロでもないという点です。混雑は共有区間で起きます。同じノードでも時間帯によって挙動が大きく変わるのは、ノード自体ではなく、この共有経路が変化しているためです。
同じノードが昼は速く夜は遅いのはなぜか
日中は国際出口が比較的空いているため、直結回線は経路が長くても待ち行列はありません。ピーク時には大量のトラフィックが同じ出口に集中し、パケットロスと再送が増えて、ハンドシェイクも再接続も遅くなります。だからこそ計測はピーク時を必ず含める必要があります。日中だけ測った結果は体系的に楽観的になり、夜に使うとまったく別物になります。
プロトコルとクライアント:どの選択が安定性を変えるか
プロトコルが決めるのは「同じ経路条件でデータをどう送り出すか」です。パケットロスがある環境では、伝送基盤による耐性の差がはっきり出ます。同じノードでもプロトコルを変えると挙動が変わるのはこのためです。
| プロトコル | 伝送基盤 | 安定性に関わる特徴 |
|---|---|---|
| Shadowsocks | TCP / UDP のどちらでも動作 | ハンドシェイクが軽量で設定項目が少なく、パラメータの不一致による失敗が起きにくい |
| VMess | 主に TCP | 機能が多く、パラメータの記述ミスはハンドシェイク段階の失敗として現れやすい |
| Trojan | 標準 TLS(TCP 上) | 通常の HTTPS と同じ経路を通り、TLS の切断や出口の混雑の影響を受ける |
| VLESS | XTLS / Reality と組み合わせて使われることが多い | 暗号化・復号とハンドシェイクの負荷を減らし、長い接続の維持コストが低い |
| Hysteria2 | QUIC(UDP)ベース | パケットロス環境では輻輳制御でスループットを保つため、UDP の品質に敏感 |
| TUIC | QUIC(UDP)ベース | 多重化が可能でハンドシェイクも速いが、UDP が通るかどうかに依存する |
選び方には簡単な原則があります。ネットワークが UDP に寛容なら、QUIC 系プロトコルは揺らぎのある環境でより滑らかに動作します。UDP の制限が強いネットワークでは、TCP 系プロトコルのほうがかえって信頼できます。これは優劣の問題ではなく、経路がどちらを通すかという問題です。まず自分のネットワークがどちらのトラフィックに寛容かを確認し、それからどちらのプロトコルで測るかを決めてください。
分流ルールとクライアントの違い
分流(ルールベースのルーティング)は、中国本土のドメインを直結させ、必要なリクエストだけをプロキシ経由にします。ルールが正しければ不要な迂回と同時接続数を減らせますが、間違っていると「通すべきものが通らない」状態になり、一部のサイトが開けないという形で現れます。回線障害に見えますが、実際はルールの問題です。
クライアント側では、Windows / macOS / iOS / Android / Linux の5プラットフォームでキープアライブと再接続の方針が一致していません。モバイルは OS のバックグラウンド制限を受け、画面ロック後に長い接続が停止されることがありますが、デスクトップはセッションを維持する傾向があります。安定性を評価するときは、各プラットフォームで個別に計測すべきで、1台の端末の結果から全体を推測してはいけません。
自宅で再現する:7日間の計測記録法
以下の手順に特別なツールは不要で、表と少しの根気があれば十分です。目標は、漠然とした印象ではなく、横並びで比較できる計測表を作ることです。
- 準備段階:候補回線を2〜3本選ぶ(IEPL 専用線、中継、直結を1本ずつ含めるのが望ましい)。端末1台とネットワーク環境1つを固定する。
- 毎日3回の計測:午前、20:00–23:00、深夜にそれぞれ1回、各回線へ30回接続し、前述の判定基準で成功回数を記録する。
- 長い接続の観察:少なくとも1つの時間帯で1時間以上接続を維持し、ログ上の意図しない切断の回数と発生時刻を記録する。
- 再接続の計測:切断のたびにすぐ再接続し、開始から利用可能になるまでの秒数を記録して、ピーク時かどうかを書き添える。
- 集計と比較:7日後に回線ごとに日中の成功率、ピーク時の成功率、切断回数、平均再接続秒数の4項目を算出し、長期で使う回線を決める。
記録表はシンプルでよく、1項目につき1行です:
日付,時間帯,回線,接続回数,成功回数,意図しない切断回数,平均再接続秒数
2026-09-08,20:30,日本-IEPL,30,29,0,1.4
2026-09-08,20:30,日本-直結,30,24,2,6.8表には実測データだけを書き、推定値は書かない。7日後には、どの回線がピーク時の利用に適しているかがはっきり分かります。
よくある誤判定:切断に見えるが、実は回線の問題ではない
問題を回線のせいにする前に、以下のチェックリストで確認してください。これらのケースに共通するのは、切断のように見えても回線を変えれば解決するわけではないという点です。
- ✅ まず購読リンクが最新かを確認する——購読が更新されていないとノード情報が古くなり、ハンドシェイクの失敗として現れます。
- ✅ システムの時刻が正確かを確認する。時刻のずれは TLS ベースのプロトコルのハンドシェイク失敗を招きます。
- ✅ ローカルネットワーク自体が安定しているかを確認する。ルーターの長時間稼働や Wi-Fi 電波の弱さは、偽の切断を生みます。
- ✅ 別の対象サイトで試し、対象サイト自体に到達できないのではないかと切り分ける。
- ❌ DNS の名前解決の失敗を回線障害とみなす——解決結果が異常な場合、接続は開始前に失敗します。
- ❌ 複数の端末で同時にダウンロードしながら安定性を測る。帯域の取り合いが結果を汚します。
- ❌ 1回の失敗だけで回線を変える。単発の失敗に統計的な意味はありません。
結論:宣伝ではなく用途で回線を選ぶ
安定性は測れます。接続成功率、切断率、ピーク時の再接続時間という3つの指標が「つながるか」「どれだけ持つか」「どれだけ速く戻るか」という3つの重要な問いをカバーし、7日間の定時計測と組み合わせれば、自分専用の比較表が得られます。
選定は用途で分けるとよいでしょう。リアルタイム操作や長時間の常時接続なら IEPL 専用線を優先し、日常のブラウジングやオンライン動画なら中継回線で通常は十分、直結回線は予備やピーク外の時間帯に向いています。プロトコルについては、まずネットワークが UDP をどれだけ通すかを確認し、そのうえで QUIC 系と TCP 系のどちらを取るかを決めてください。
VPNAW は100+ カ国 / 170+ 回線を提供し、IEPL 専用線・中継・直結の3タイプを網羅、同時接続台数は無制限、匿名・ログなし、60日間の理由不問返金保証、メールアドレスなしで始められます。回線と地域の分布は回線ページで、選び方の考え方は選定ガイドで確認できます。クライアントの入手とインポート手順は使い方ガイドをご覧ください。
計測期間中は元のログを残しておくことをおすすめします。いざというとき、記憶よりタイムスタンプのほうがはるかに信頼でき、時間帯ごとの違いも比較しやすくなります。
接続成功率はどのくらいなら正常?
統一された基準はありません。重要なのは同じ回線の時間帯ごとの比較です。日中とピーク時の差は絶対値よりも参考になります。差が小さければその回線は混雑に強いといえ、差が大きければピーク時に負荷がかかっていることが分かります。
安定性の計測に専門ツールは必要?
必要ありません。クライアントの接続ログ、リクエストの所要時間を記録するコマンド1つ、そして表があれば十分です。結果を左右するのは、計測の条件が固定されているか、サンプル数が足りているかであり、ツールが高度かどうかではありません。
プロトコルを変えると挙動が大きく変わるのはなぜ?
プロトコルによって伝送基盤が異なります。QUIC 系は UDP ベースで、パケットロス環境では輻輳制御によってスループットを維持します。TCP 系はハンドシェイクと再送の仕組みが異なります。経路がどちらのトラフィックに寛容かが、あなたのネットワークでどちらのプロトコルが安定するかを直接決めます。
ピーク時の再接続が遅いのはノードの問題?
一概にはいえません。再接続の遅さは通常、経路上の待ち行列と関係しており、共有区間が混雑すると同じノードでも再接続時間が長くなります。判断方法は、同じノードの日中の再接続時間を基準にし、ピーク時に何倍の差が出るかを比べることです。