Search for the most stable VPN and most results hand you a verdict, not a method. "This route is rock solid" or "it drops at night" — without a measurement standard you can neither compare those claims nor reproduce them. This article splits stability into three metrics you can collect yourself — connection success rate, drop rate and peak-hour reconnect time — explains what route type and protocol each contribute, and lays out a sampling routine you can run at home.
Stability Isn't Guesswork: Three Measurable Metrics
Connection success rate measures whether you can get connected: the share of attempts that end in a usable session. A failure can happen at DNS resolution, the handshake or authentication, so a dip in this number doesn't automatically mean the node is at fault. Drop rate measures how long a connection holds once it's up: the number of non-deliberate disconnects per unit of observation time. Peak-hour reconnect time measures how fast you get back: the seconds needed to re-establish a usable session after a drop.
Each metric answers one question; only together do they describe what a route actually feels like. Judging by a single one leads you astray: a route with a high success rate but slow reconnects is miserable for long sessions, while a route that drops often but recovers instantly is barely noticeable for web browsing.
| Metric | Question it answers | How to collect it | What to watch |
|---|---|---|---|
| Connection success rate | Can you connect at all | Fire a series of connections in a fixed time window; log successes and handshake time | Whether peak hours fall clearly below other windows |
| Drop rate | How long a connection holds | Hold a long-lived connection, keep the heartbeat log, and timestamp every disconnect | Whether drops cluster in one time window or on one network |
| Peak-hour reconnect time | How fast you recover after a drop | Reconnect immediately after each drop and log the seconds from attempt to usable | How many times worse than the daytime baseline |
How to Test Connection Success Rate: Fixed Windows, Fixed Sample Size
Connection success rate is the easiest metric to measure and the easiest to get wrong. Too few samples, drifting time windows, or treating a green icon as success all make the number meaningless. The routine below can be followed as written.
- Fixed window: 7 days straight, one round in each of three daily windows — morning, 20:00–23:00 and late night.
- Fixed sample: 30 connection attempts on the same route in each window; after each one, load the same target site to confirm it works, then disconnect.
- Fixed record: log only four fields — timestamp, success or failure, handshake time, and the error text on failure.
- Fixed formula: success rate = successes ÷ attempts. Work out daytime and peak hours separately; don't merge them into one number.
Don't Judge "Success" by the Client Icon Alone
When the client shows "Connected", it only means the local tunnel came up — not that traffic actually left through the exit. Write the pass/fail rule down in advance: after the connection is up, make one real request, and only a response counts as success. For example, time a single request:
curl -sS -o /dev/null -w '%{time_total}s\n' https://example.com/If that request times out, log the attempt as a failure even if the client icon is green. Likewise, don't use ping to judge whether a connection works: ICMP reachability doesn't mean the proxy tunnel is usable, and plenty of nodes block ping outright.
Treating a green client icon or a successful ping as your success criterion systematically counts failed samples as successes, inflates the measured rate, and skews every comparison that follows.
Drop Rate and Peak-Hour Reconnect Time: Watching a Long-Lived Connection
Drop rate has to be observed on a long-lived connection. A proxy session is essentially one long connection; when idle it can be reclaimed by devices along the path (NAT table entries timing out), which is why clients rely on heartbeats. So split disconnects into two kinds: the ones you cause by switching networks, locking the screen or sleeping the machine, and the ones reclaimed by the link or the server. Only the second kind counts toward drop rate — otherwise your own actions contaminate the number.
Measure peak-hour reconnect time inside the 20:00–23:00 window. That's when international gateway congestion peaks, and queuing on shared paths slows reconnects noticeably. Logging it is simple: reconnect the moment a drop happens, use log timestamps to record the seconds from attempt to usable, then compare against the same route's daytime baseline.
- ✅ Use the disconnect timestamps in the client log instead of guessing how many times it dropped last night.
- ✅ Flag disconnects caused by switching Wi-Fi or mobile networks separately; they don't count toward drop rate.
- ✅ Observe for at least 7 days in a row; a single night's data proves nothing.
- ❌ Counting a background connection reclaimed after screen lock as a route drop.
- ❌ Drawing conclusions from one device — keep-alive and reconnect behaviour differ across the five platforms.
How Route Type Decides Stability: IEPL Dedicated Lines, Relay and Direct
Route type is the single biggest source of stability differences — it matters more directly than protocol choice. Two nodes both labelled "Japan" can send your data along completely different paths.
| Route type | Data path | Stability profile | Best for |
|---|---|---|---|
| IEPL dedicated line | Both ends are linked by a carrier's international private line, avoiding public internet international gateways | Smaller swings at peak hours; long connections are reclaimed less often by intermediate devices | Real-time interaction, long unattended sessions |
| Relay | Traffic enters a relay entry point first, then crosses via an optimised link to the exit node | One extra hop versus direct; performance depends on the quality of the relay entry | Everyday browsing, online video |
| Direct | The client connects straight to an overseas exit node, all the way over the public internet | Low cost and wide coverage, but peak hours are easily hit by international gateway congestion | Backup routes, off-peak hours |
To be clear: direct doesn't mean unstable, and a dedicated line doesn't mean zero jitter. Congestion happens on shared segments — when the same node performs very differently at different hours, it's usually that shared path changing, not the node itself.
Why the Same Node Is Fast by Day and Slow at Night
By day the international gateways are relatively idle, so even a long direct path sees no queuing. At peak hours a flood of traffic squeezes through the same gateway, packet loss and retransmits climb, and handshakes and reconnects slow down with them. That's why testing has to cover peak hours — daytime-only results are systematically too optimistic, and evening use is a different story.
Protocols and Clients: Which Choices Change Stability
Protocol decides how data is sent under the same path conditions. On a lossy path the difference between transport foundations is obvious — which is why the same node behaves differently after you switch protocols.
| Protocol | Transport | Stability-relevant traits |
|---|---|---|
| Shadowsocks | Runs over both TCP and UDP | Lightweight handshake, few options; mismatched parameters rarely cause failures |
| VMess | Mostly TCP | Many features; a wrong parameter usually shows up as a handshake failure |
| Trojan | Standard TLS (over TCP) | Shares the path with ordinary HTTPS; affected by TLS interruptions and gateway congestion |
| VLESS | Often paired with XTLS / Reality | Cuts encryption and handshake overhead, so long connections cost less to maintain |
| Hysteria2 | Built on QUIC (UDP) | Relies on congestion control to hold throughput on lossy paths; sensitive to UDP quality |
| TUIC | Built on QUIC (UDP) | Multiplexing and fast handshakes, but still depends on UDP being allowed through |
There's a simple rule of thumb: when your network treats UDP well, QUIC-based protocols ride out jitter more smoothly; when UDP is heavily restricted, TCP-based protocols are the more reliable pick. It isn't a question of better or worse but of what the path lets through — first find out which traffic type your network tolerates, then decide which protocol family to test.
Routing Rules and Client Differences
Rule-based routing sends mainland China domains direct and proxies only the requests that need it. Correct rules cut unnecessary detours and concurrent connections; wrong rules leave traffic that should be proxied going direct, which shows up as sites that won't open — it looks like a route failure but is really a rules problem.
At the client level, keep-alive and reconnect behaviour differs across Windows / macOS / iOS / Android / Linux: mobile platforms are constrained by background limits and may suspend a long connection after the screen locks, while desktop clients tend to hold the session. When you assess stability, sample on each platform separately instead of extrapolating from one device.
Reproduce It at Home: A 7-Day Sampling Routine
The routine below needs no extra tools — just a spreadsheet and a little patience. The goal is a sampling table you can compare across routes, not a vague impression.
- Setup: pick 2–3 candidate routes (ideally one each of IEPL dedicated, relay and direct), then fix one device and one network environment.
- Three rounds a day: morning, 20:00–23:00 and late night; in each round fire 30 connections per route and record successes using the pass/fail rule above.
- Long-connection watch: hold a connection for at least 1 hour in one window, and log the non-deliberate disconnects and when they happened.
- Reconnect timing: reconnect immediately after every drop, note the seconds from attempt to usable, and mark whether it was during peak hours.
- Compare: after 7 days, work out four figures per route — daytime success rate, peak-hour success rate, disconnect count and average reconnect seconds — then decide which one to keep.
The record sheet can be very simple — one line per entry:
Date,Window,Route,Attempts,Successes,Non-deliberate disconnects,Avg reconnect seconds
2026-09-08,20:30,Japan-IEPL,30,29,0,1.4
2026-09-08,20:30,Japan-Direct,30,24,2,6.8Put only measured data in the table, never estimates. After 7 days it will be obvious which route is fit for peak-hour use.
Common Misreads: It Looks Like a Drop, but the Route Isn't the Problem
Before blaming the route, run through the checklist below. What these cases share: they look like drops, but switching routes won't fix them.
- ✅ Check the subscription link is current first — a stale subscription leaves node details out of date, which shows up as handshake failures.
- ✅ Check the system clock is accurate; a time offset breaks the handshake on TLS-based protocols.
- ✅ Confirm your local network is stable: a router that's been up for weeks or a weak Wi-Fi signal both manufacture fake drops.
- ✅ Try a different target site to rule out the site itself being unreachable.
- ❌ Treating a DNS resolution failure as a route fault — when resolution goes wrong, the connection fails before it even starts.
- ❌ Testing stability while several devices are downloading; bandwidth contention contaminates the result.
- ❌ Switching routes after a single failure; one failure has no statistical meaning.
The Takeaway: Pick Routes by Use Case, Not by Marketing
Stability can be measured. Connection success rate, drop rate and peak-hour reconnect time cover the three key questions — can you connect, how long does it hold, how fast do you recover — and with 7 days of fixed-window sampling you get a comparison table of your own.
Match the route to the job: favour IEPL dedicated lines for real-time interaction and long unattended sessions, relay routes are usually enough for everyday browsing and online video, and direct routes work well as a backup or off-peak. On protocols, first check how your network treats UDP, then choose between the QUIC and TCP families.
VPNAW offers 100+ countries / 170+ routes across three types — IEPL dedicated, relay and direct — with unlimited simultaneous devices, anonymous no-logs operation, a 60-day no-questions-asked refund, and no email address required to start. Coverage by region is on the Routes page, choosing between them is covered in the Selection Guide, and client downloads and import steps are in Guides.
Keep the raw logs during testing. If a dispute comes up, timestamps are far more reliable than memory, and they make it easy to compare windows against each other.
What Counts as a Normal Connection Success Rate?
There's no universal benchmark; what matters is comparing the same route across windows. The daytime-versus-peak gap tells you more than the absolute number: a small gap means the route shrugs off congestion, a large one means it's clearly under pressure at peak.
Do I Need Professional Tools to Test Stability?
No. The client's connection log, one command that times a request, and a spreadsheet are enough. What actually shapes the result is whether your sampling method is fixed and your sample size is adequate — not how fancy the tooling is.
Why Does Performance Change So Much After Switching Protocols?
Protocols rest on different transports: QUIC-based ones run on UDP and lean on congestion control to hold throughput on lossy paths, while TCP-based ones use different handshake and retransmission mechanics. Which traffic type your path tolerates decides which family is steadier on your network.
Slow Reconnects at Peak Hours — Is It the Node?
Not necessarily. Slow reconnects usually come down to queuing along the path; when shared segments congest, the same node's reconnect time stretches too. To tell, use that node's daytime reconnect time as a baseline and compare the peak-hour multiple.