Which metrics matter for a stable VPN?
Choosing a stable VPN requires more than checking a single speed test. To compare connection success and disconnection rates, first keep the network, client, and target service consistent. Then check whether a connection can be established, maintained, and restored after an issue. This article offers testing methods and selection criteria, not unmeasured brand rankings.
“Connected” in a client and “the target website works” are different states. When some proxy clients start up, they may only have activated the local proxy or virtual network interface; that does not necessarily mean a remote node is reachable. A successful test should include a real request: the target page opens, the sign-in process completes, and the usual task can continue. A status icon alone is not enough.
Connection success rate helps measure reliability when first connecting. Record the total number of valid attempts and how many meet a predefined success criterion, then divide successful attempts by valid attempts. Note operational errors separately, such as a network that was not connected or a test that was never run. Do not silently remove unfavorable results or count every such case as a route failure.
A disconnection rate needs a clearly stated denominator. For session-based comparisons, record the share of sessions with an unexpected interruption. For time-based comparisons, record unexpected disconnections against actual usage time. Session lengths vary, so comparing raw interruption counts can be misleading. Log deliberate node changes, device sleep, and network changes as separate environmental events so they are not confused with route failures.
What to look for: Prioritize routes that connect consistently on your network and at your usual times, have fewer unexpected interruptions, and recover in an explainable way. Peak speed can be a useful reference, but it cannot replace records of continuous use.
Comparing dedicated, relayed, and direct routes
Route labels describe how a path is organized; they do not determine how stable it will be. IEPL usually refers to an international Ethernet private line and may cover one segment of a service’s cross-border transmission path. Local access from the user to the entry point, entry-point load, and public-network access from the exit to the target service can all affect the overall experience. A dedicated-line label is not a guarantee of end-to-end access.
A relayed route passes through a forwarding entry point before reaching the exit. This may improve reachability to the entry point, but can also add queuing or maintenance steps. A direct route usually means the client connects straight to an overseas node, though different services may define the term differently. Check the route description and confirm the actual entry and exit points before comparing options; do not rely on plan labels alone.
| Route type | Path characteristics | What to observe | What this cannot establish |
|---|---|---|---|
| IEPL dedicated line | May include a dedicated segment for cross-border transmission | Service continuity at busy times, entry-point congestion, and exit response | That local access and the target service will always work |
| Relayed route | Forwarded through an entry point to an exit | Entry-point reachability, forwarding load, and recovery after an issue | That more relay steps mean greater stability |
| Direct route | The client connects directly to an overseas node | Local carrier path, busy-period variation, and connection establishment | That fewer path steps prevent disconnections |
Check whether backup routes fail independently. Nodes with different names may share an entry point, upstream path, or exit, leaving them exposed to the same failure. Redundancy is valuable when it offers a different failure domain, not simply a longer list. When asking about route differences, focus on the path and exit rather than requesting sensitive infrastructure details.
Repeatable testing steps
Define the intended use before testing. For web browsing, check whether requests complete; for video, observe continuous playback and buffering; for remote meetings, check whether audio remains uninterrupted; for file transfers, verify task completion. Do not use download performance as a substitute for meeting quality, or rely on the easiest website to open as your only test target.
- Keep test conditions consistent. Record the device, operating system, client version, access network, node, and rule mode. Pause large transfers on other devices and confirm that the local network itself is working. Keep these conditions the same when comparing candidate routes.
- Record connection setup. Select a node manually and make the same request to the target. Record the client status, whether the target is reachable, any error message, and whether a retry is needed. Automatic route selection changes the test subject, so do not mix it into baseline tests.
- Check sustained use. Run the same type of task and observe whether the session continues. Distinguish application errors and playback buffering from an actual network interruption. Note whether the device went to sleep, the network changed, or rules were updated.
- Test at your usual times. Repeat tests during the times you typically use the service, including both busy and quieter periods. Alternate between candidate routes so one route is not tested only when network conditions are better.
- Test recovery. When an issue occurs, record what happened first, then check the local network before reconnecting or switching to a backup route. Note whether the task resumes and whether you need to sign in again or restart it.
- Summarize consistently. Report connection success rate, the share of sessions with unexpected interruptions, actual usage time, and recovery method separately. Keep failure records; do not substitute a single best result for the full test period.
You do not need complex tools to start keeping records. These fields can go in a local text file or spreadsheet. For “Cause of interruption,” you can write “To be confirmed”; do not blame every failure on the route without evidence.
Test period:
Device and client version:
Access network:
Node and route type:
Target service and test task:
Rule mode and DNS settings:
Valid connection attempts / successful attempts:
Actual usage time:
Unexpected interruptions and observed symptoms:
Environmental events, such as manual switches or sleep:
Recovery action and whether the task resumed:This article does not publish measurements from live tests, so it cannot establish a brand’s connection success or disconnection rate. Keep your own raw records to judge whether a recommendation fits your current network.
How clients and protocols affect stability
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols or protocol options; their names alone do not establish a stability ranking. The actual results depend on implementation, transport settings, server support, and network conditions. A protocol name also does not substantiate any particular security claim.
Hysteria2 and TUIC are based on QUIC and depend on UDP availability. They may have connection issues on networks that restrict or handle UDP poorly, but that does not mean they are unstable on every network. Trojan is commonly used with TLS, while VLESS security and transport characteristics depend on the actual configuration. A particular transport appearance is not a guarantee of continuous availability.
On Windows and macOS, the system proxy usually affects only applications that follow proxy settings. TUN mode can handle more traffic, but needs appropriate permissions and routing configuration. Mobile clients often handle traffic through system-provided network extensions or virtual network interfaces; background restrictions, sleep, and changes in network access can all affect connections. On Linux, pay close attention to how the service starts, routing, and name-resolution settings.
So even the same node does not mean the test conditions are the same. Record any change of client, core, or mode, such as switching from a system proxy to TUN. Start with a baseline using the client’s supported defaults, then change one setting at a time to identify what caused a difference.
A subscription link imports nodes and related settings provided by the service. Whether it includes rules depends on the subscription format and client support. Updating a subscription does not necessarily restore an active connection immediately or switch the current node. After importing, check that the nodes are present, the protocol is supported, and the rules are working. Avoid importing the same link repeatedly, which can clutter configuration groups.
Troubleshooting “connected but not working”
When a target website fails, first identify the scope of the problem. If only one service is affected, the cause may involve the exit region, the target service’s policies, or account status. If proxy traffic fails broadly, check the node and entry point. If direct-connection apps are also affected, start with local access. This order helps avoid mistaking a service’s access denial for a VPN disconnection.
DNS resolves domain names to addresses. If resolution takes an unsuitable path, access may fail or domain queries that were meant to go through the proxy may be exposed. DNS leak tests should account for system resolution settings, the client’s DNS mode, and observed traffic. Seeing the name of a resolver alone does not prove the path taken by every query or establish that web traffic is going direct.
Routing rules decide which requests go direct and which use the proxy. Missing rules, apps that bypass the system proxy, and IPv6 paths that are not handled can all result in some apps working while others fail. Temporarily switching rule modes can help with diagnosis, but understand what each mode does and restore the configuration suited to everyday use afterward.
- ✅ Check the local network and client error messages before changing nodes or rules.
- ✅ Test other destinations to distinguish a single-service issue from a route-wide problem.
- ✅ Check the routing rule for the target request, along with DNS and IPv6 handling.
- ✅ Change one setting at a time and keep before-and-after records to make the cause clear.
- ❌ Do not treat a green status icon after automatic reconnection as proof that the task has resumed.
- ❌ Do not show full subscription links or account credentials in public screenshots or support requests.
Automatic node switching can limit the impact of some failures, but existing sessions may not continue seamlessly. A change in exit IP may trigger reauthentication, and long-lived connections may need to be re-established. For long-running sign-ins or tasks, a tested primary route with a clearly defined backup is usually easier to manage than constantly chasing the lowest latency.
Recommendations by use case
For everyday browsing, check whether connections establish smoothly and page requests complete. For continuous playback, observe buffering and picture-quality changes during busy periods. For meetings and interactive tasks, pay attention to interruptions, response variation, and whether the task recovers. If you need to stay signed in for a long time, consider how often the exit changes, but do not assume a fixed exit means a target platform will always allow access.
When comparing services, keep test records separate from verifiable service details. VPNLD offers 110+ countries / 160+ routes and unlimited simultaneous devices. These figures help assess coverage and device use, but are not measurements of stability. The security description uses “quantum encryption,” which also does not replace tests of actual connectivity and service continuity.
VPNLD requires no email address; an account can be created with a username and password. After signing in, get a subscription and import the configuration according to client support. The service offers a 7-day no-questions-asked refund. Base testing on real use cases rather than drawing conclusions from a single speed test during a quiet period.
Making a final choice: Compare connection success under the same conditions, use a clearly defined denominator for disconnections, and check task recovery and backup paths. A route with explainable failures and repeatable results is more useful than a “most stable” label with no testing criteria.
For configuration steps, see the Setup Guide. For connection or subscription issues, see Troubleshooting. Check the Nodes page and client details for route availability and types; see the plans page for prices and billing terms.