Protocols and Routes
Technical Guide
Connection types, network routes, resource use, and choosing a setup for your needs. Understand what affects performance before deciding what to change.
Setting up VPNWB for the first time? Start with the getting started guide to set up your account and plan, import your subscription, and verify the connection. This page isn’t another installation walkthrough. It’s a reference for understanding why protocols behave differently, why connections can slow down at peak times, and how to narrow a problem down to your device, access network, route, or destination platform.
This guide covers general protocol design and does not imply that every protocol is currently available on VPNWB. Check the user dashboard and client subscription for the protocols, transport methods, and route types available to you. Different implementations of the same protocol may also behave differently by default.
- A guide to how things work, not a speed ranking
- Test for your use case instead of judging by name
- Service policy: no logs
Connection layers and performance
From an app request to the destination
Opening a webpage may look like a single click, but it involves DNS resolution, rule matching, local proxy handling, a remote connection, and a response from the destination. The page may then request images, scripts, and APIs, so seeing the homepage doesn’t mean every connection has completed. When a client says it’s connected, that usually means one part of the connection is working—not that every app is using the same route. When troubleshooting, record “client connected” separately from “the service works” so a success message isn’t mistaken for the final result.
A protocol defines how the client and server identify each other, encapsulate data, and pass along the destination address. A route determines where that data actually travels. They’re related, but they aren’t the same setting. Changing the protocol on the same route may affect handshakes and congestion handling; changing the route while keeping the protocol may change the entry point, carrier network, and exit location. Before comparing results, identify which layer you’re testing. Don’t change the region, protocol, and client mode all at once: even if things improve, you won’t know which change helped.
Connection setup time vs. sustained transfer speed
Connection setup time is how long it takes from making a request to exchanging useful data. Sustained transfer speed is how much data a connection can carry once it’s running. Slow DNS, multiple handshake round trips, or a delayed server response can leave a webpage blank for a while, even if a file downloads quickly once the connection is established. Conversely, a fast-loading first screen doesn’t mean a long video won’t buffer. Setup time affects responsiveness; sustained throughput is affected by capacity and congestion. Download speed alone can’t tell you how responsive a webpage will feel.
A client’s latency check also depends on what it tests and how it does so. Some checks only test the connection to a node; others also request a specific webpage. The results aren’t directly comparable when the targets differ. This guide doesn’t rank protocols by those numbers. For a more useful comparison, keep the device, access network, and task the same. Then check how easily the connection starts, whether the page loads fully, whether playback stays smooth, and whether you need to take action after switching networks.
Don’t confuse the transport layer with the proxy protocol
TCP provides an ordered, reliable byte stream: missing data must be retransmitted before the application can continue reading in sequence. UDP sends datagrams but doesn’t provide reliable delivery on its own. Protocols built on UDP can implement acknowledgments, retransmissions, and congestion control themselves. So “runs over UDP” doesn’t mean data can be dropped at will, and it doesn’t automatically mean faster than TCP. Look at how the protocol handles reliable streams and congestion, and whether the access network allows that traffic through.
TLS establishes an authenticated, encrypted channel. QUIC combines transport with an encrypted handshake. Proxy protocols can use these underlying capabilities or provide their own data protection. Protocol, transport, and security options shown in a subscription often refer to different layers. Judging a connection by a single name can overlook certificate validation, hostnames, and transport encapsulation. A successful client import only means the configuration was recognized; it doesn’t confirm that all these conditions are met.
What you need to know before comparing performance
Any claim that something is “faster” needs context. For workloads with many short requests, handshakes and connection reuse may matter most. For long downloads, congestion control, server resources, and route capacity matter more. Mobile use also depends on wireless signal quality and background activity. Different results for the same protocol in different situations aren’t contradictory. A comparison without a defined device, destination, network, and client implementation is only a starting point for choosing—it can’t be taken as a promise about VPNWB routes or device battery life.
Describe what you observe in specific terms, such as “text appears first, but images keep loading” or “the current session drops after I switch networks.” These details can point to connection reuse, resource domains, rule scope, or session recovery. A vague report like “it’s slow” often leads only to vague advice to switch routes. After reading the sections below, you should be able to connect symptoms to the right layer and test one variable at a time, instead of repeatedly importing subscriptions or reinstalling the client without a clear reason.
Stream protocol design trade-offs
Shadowsocks: focus on the implementation and encryption method
Shadowsocks is built around proxy forwarding. Common setups carry TCP traffic and can also forward UDP when the implementation supports it. To understand how a setup will behave, look at its encryption method, client implementation, and server configuration—not just the protocol name. The design doesn’t require every service to use the same additional transport encapsulation, so configurations can be relatively straightforward. Adding another transport layer can still change connection overhead and compatibility. Fewer settings don’t guarantee the same performance on every network.
On resource-constrained devices, whether the encryption implementation can use hardware acceleration and how efficiently the client handles connections may matter more than the protocol label. A mismatch between the password or key and the encryption method will usually prevent the connection from exchanging data properly; don’t assume congestion is to blame. If the subscription supplies these parameters, keep the imported values rather than changing the encryption settings. To compare performance, try another known-working configuration instead of changing authentication parameters in search of a speed boost.
VMess: consider the protocol and transport together
VMess has its own authentication and data-protection design, and the connection may use different transport encapsulations. Some combinations carry a data stream directly; others add an application-layer handshake or an upstream service. As a result, nodes labeled VMess may differ in initial connection time and the steps involved. Record the protocol, transport method, and security settings as a single set of conditions when comparing results. Don’t generalize the results of one combination to every VMess configuration.
Authentication may also be sensitive to the device’s system clock. If the time is clearly wrong, restore automatic time synchronization before checking authentication and route status. A mismatch in the outer encapsulation can let the connection reach the entry point but prevent subsequent data exchange. These issues often look like repeated connection attempts or an immediate disconnect—not a gradual slowdown at peak times. Checking whether the client supports the configuration is a better first step than repeatedly switching regions.
Trojan and VLESS: security works at different layers
Trojan typically carries proxy traffic over TLS, so the client must correctly validate the certificate and server identity. Setup time includes proxy authentication as well as the underlying connection and TLS handshake. Connection reuse and session resumption can also affect how quickly pages open when you revisit them. Don’t treat disabling certificate validation as a general fix. For certificate errors, check the system clock, server name, subscription status, and configuration completeness rather than weakening validation.
VLESS doesn’t encrypt payloads at the protocol layer, so it needs to be paired with an appropriate secure transport. A lightweight protocol header doesn’t mean the overall connection requires no encryption, or that its total resource use must be lower. TLS, other security mechanisms, and transport encapsulation still do work. When reviewing a configuration, confirm that the subscription provides the outer security method correctly. Don’t interpret “lightweight” as permission to skip security settings, or assume different security combinations have identical performance.
How to compare protocols without creating a ranking
All of these protocols can carry everyday browsing, work, and streaming traffic. Actual differences depend on both protocol design and deployment. If they all run over TCP streams, packet loss at the transport layer still affects ordered delivery. Additional handshake steps, connection reuse, upstream services, and exit capacity may also matter more than the size of authentication fields. So you can’t claim from the name alone that a protocol will always have lower latency, use less battery, or work better with every streaming platform.
First rule out combinations the client can’t fully support, then compare how they work for your tasks. Keep the imported settings, confirm authentication and certificates are working, and test with the same webpage and playback task. If different protocols use different regions or entry points, the results describe the experience of each full configuration—not the protocol alone. To learn how direct, relayed, or dedicated routes affect performance, see the route list and the topology section of this guide.
| Protocol | What to check | What you can’t conclude |
|---|---|---|
| Shadowsocks | Encryption method, implementation, UDP support | A short configuration is always more energy-efficient |
| VMess | System clock, transport encapsulation, security settings | Configurations with the same name have the same overhead |
| Trojan | TLS validation, server name, connection reuse | Using TLS always means a faster connection |
| VLESS | Outer security method, transport implementation | A lightweight protocol header means the lowest overall overhead |
QUIC protocols and performance on unstable networks
What QUIC changes
QUIC implements reliable transport, stream management, and congestion control over UDP, and combines these with TLS for a secure handshake. It doesn’t just put TCP data in a different container; it organizes transport state differently. When multiple streams share a connection, a gap in one stream doesn’t necessarily block ordered delivery on the others. However, they may still share congestion capacity and the underlying link. Independent streams can reduce some kinds of waiting, but they can’t add capacity to a limited link or eliminate congestion on the access network.
Combining handshake steps and resuming sessions may reduce the wait when reconnecting, but the benefit depends on the implementation, cached state, and server policy. A first visit, network switch, and app restart may not have the same conditions. In practice, it’s more useful to check whether things recover smoothly than to infer the experience from theoretical round trips. QUIC also uses UDP, so if network equipment restricts or drops that traffic, connection setup may fail even while traditional TCP connections continue to work.
Hysteria2: congestion handling depends on the route
Hysteria2 is based on QUIC and provides authentication, forwarding, and bandwidth management for proxy traffic. Its transport may recover differently from common TCP-based setups when latency fluctuates or packets are lost. That doesn’t mean it can ignore all packet loss. If loss comes from wireless interference, a saturated exit, or access-network restrictions, the transport layer can only work with the conditions available. It can’t repair a physical link or guarantee that the destination platform will keep serving content.
Bandwidth settings shouldn’t be copied from someone else’s configuration. Setting an expected capacity too high can increase queuing or compete with other traffic on the same network; setting it too low can limit otherwise available throughput. Follow the client documentation and subscription parameters to determine whether adaptive behavior is enabled and which side controls transport policy. If VPNWB provides the configuration, don’t rewrite it to chase a better-looking speed. Test the original settings first, then determine whether there’s a real bottleneck to address.
TUIC: connection reuse and datagram behavior
TUIC is also based on QUIC. It uses QUIC connections to carry proxy traffic and handles reliable streams and datagram forwarding separately. Connection reuse can reduce the work of repeatedly establishing an outer connection, but its effectiveness depends on the client implementation, idle timeouts, and server state. It can help when an app creates many short-lived connections. If a connection sits idle and the client or network equipment clears its state, the next request still needs a new connection. Reuse doesn’t mean a connection stays available forever.
Some services rely on UDP. Whether they work also depends on the client’s UDP forwarding method, rule matching, and support at the destination. A webpage loading doesn’t guarantee that voice, interactive, or other datagram-based services will work. If only those services are affected, first check whether their traffic follows the expected proxy route, then confirm the relevant forwarding support. Don’t try to mask the issue by repeatedly increasing concurrency or changing timeouts: that may create more apparent connections and increase device load without fixing the underlying traffic-path difference.
When to try QUIC—and when to use a compatible alternative
A QUIC-based setup is worth trying when the access network supports UDP, the device and client fully support the configuration, and real-world tasks repeatedly suffer from transport recovery with common stream-based connections. Keep a known-working TCP route as a comparison. If the QUIC-based setup never completes a handshake but the alternative works, first check UDP reachability, authentication, and implementation compatibility. Don’t immediately conclude that all routes are unavailable.
QUIC is designed to let some connections keep working when a mobile device changes networks, but whether a proxy session survives also depends on the implementation, NAT state, and the app itself. Sleep, background restrictions, or a client restart can all lose connection state. Distinguish “supports migration” from “the task will never be interrupted when switching networks.” For meetings and long-running sessions, judge by how your device behaves during an actual network switch, not by a protocol feature list.
Direct, relayed, and dedicated routes
Identify the entry, transit, and exit points first
A proxy route can be broken into sections: device to entry point, entry point to exit, and exit to destination. The region shown by the client usually relates to the exit location, not necessarily the entire route; the entry address may not be the final exit either. This distinction helps explain why two routes in the same region can perform very differently. They may use different entry points, transit networks, or exit resources—differences that a shared protocol name can’t cancel out.
A route name is a search clue, not proof of the full topology. Check the route details and connection results for the city, carrier network, transit, and platform availability. VPNWB covers 90+ countries / 240+ routes, but coverage doesn’t mean every destination platform works on every route. This guide doesn’t add cities or data centers that haven’t been specified. Start by choosing a region for your task, then check which route types are currently available. Don’t mistake broad regional coverage for a guarantee of access to a particular service.
Direct routes: fewer steps don’t mean fewer fluctuations
A direct route usually means the device reaches the remote proxy entry point through its access network, without an additional upstream relay arranged by the service provider. The structure is easy to understand and may reduce extra processing, but the carrier network determines the actual path between networks. A nearby destination isn’t necessarily reached by a short network path; peering congestion or routing detours can still cause delays and reduce throughput. The number of steps is just one factor, not a stand-alone measure of performance.
If a direct route works outside busy periods but slows down noticeably at peak times, shared peering capacity could be a factor. First rule out local wireless congestion and destination-side rate limits. Trying another route type in the same region can help show whether the transit path is the main variable. Switching to another region also changes where the destination platform connects, making the result harder to interpret. The closer the test conditions are to the original task, the more useful the comparison will be.
Relayed routes: different path planning, different connection conditions
A relayed route sends the connection to an entry point first, which then forwards it to a remote exit. The extra step adds processing and propagation time, but it may replace a difficult or unstable path from the device with a more suitable combination of networks. So “one extra hop must be slower” isn’t always true. Rather than counting hops, check whether the entry point is reachable, whether the relay segment is congested, and whether the destination service stays responsive. The relay entry point itself can also become a bottleneck.
Troubleshoot relayed routes by separating their segments. If the handshake to the entry point often fails, check the path from the device to the entry. If the entry connects but requests to multiple destinations fail, consider the forwarding segment or exit. Users usually can’t see the status of every server-side segment, so when reporting an issue, include the route name, time of day, access method, and destination type. This is more useful than simply saying “I tried lots of nodes,” and helps avoid mistaking an account issue for a relay failure.
IEPL dedicated routes: dedicated transit doesn’t mean end-to-end
An IEPL dedicated route describes a dedicated transit segment. It doesn’t mean every link from the device to the destination is part of the same dedicated connection. The user’s access network, entry resources, exit peering, and destination server still affect performance. A dedicated route type can be one factor to compare for peak-time consistency, but it doesn’t imply zero packet loss, fixed latency, or any availability guarantee. Even with a dedicated-route label, test your own streaming, work, and browsing tasks instead of skipping the checks.
When choosing a route, keep a working configuration in a region you often use, then compare direct, relayed, and dedicated routes for your task. If several route types fail on the same device, trying another access network can tell you more than changing protocols again. If only one route has issues, report that route while keeping the other conditions unchanged. For streaming, separate network stability from the platform’s regional availability. See Japanese routes and streaming platforms in Japan for more, and don’t attribute account-region restrictions to the route type.
| Type | What to check first | What still needs testing |
|---|---|---|
| Direct | Path from the access network to the remote entry point | Peering congestion, route changes |
| Relayed | The combination of the entry point and forwarding segment | Entry resources, exit, and destination response |
| IEPL dedicated route | How the dedicated transit segment is arranged | Local access and end-to-end performance |
Device resources and mobile battery life
Encryption isn’t the only source of processing overhead
A proxy client receives app traffic, matches rules, handles DNS, encrypts and decrypts data, maintains connections, and passes traffic to the system network stack. At high throughput, encryption and memory copying can add processing load. With many connections, connection-state tracking, buffering, and rule matching also use resources. A small protocol header only means some encapsulation is more compact; it doesn’t tell you the client’s total overhead. Implementation quality, system interfaces, and hardware acceleration can all affect the result.
A virtual network interface mode may send more app traffic through the client, while system proxy mode covers only apps that follow the relevant settings. Differences in resource use between these modes may come from how much traffic each one handles, not from the protocol itself. Before comparing, keep the rules, traffic-capture mode, and task consistent. Otherwise, comparing a full-device setup with one that proxies only a browser mistakes the difference in traffic scope for protocol efficiency—and any battery-life conclusion won’t carry over.
Wireless wake-ups and reconnects
Mobile power use is also affected by wireless activity. Continuous transfers, frequent short requests, keepalives, and reconnects can all prevent a device from reaching a lower-power state. With a weak signal, even light traffic may use more power because connections need to be re-established and transfers recovered. Long playback also adds screen and decoding load on top of networking. So you can’t tell whether a protocol uses more battery just from the device’s overall battery level. Try to account for changes in screen brightness, video content, and background activity.
Keepalives maintain state on intermediate network equipment, but sending them too often can wake the wireless radio more frequently. Sending them too rarely can let an idle connection get cleared, requiring a new handshake. The right behavior depends on the access network and implementation. Start with the client default or subscription settings, and check whether you actually see “the first request after idle fails.” Without that symptom, don’t shorten keepalive intervals or enable constant probing just to chase a theoretical long-lived connection.
Background limits and platform differences
VPNWB supports Windows / macOS / iOS / Android / Linux, but each system handles proxy connections differently. Mobile operating systems tend to restrict background activity more strictly, and power-saving policies can affect whether the client stays connected. Desktop devices may be affected by system proxy settings, virtual interface permissions, or other networking software. A proxy configuration shown in system settings doesn’t mean apps are still routing traffic through it. Check the client status and test an actual request to the destination.
On iOS, check that the system configuration is authorized and the expected client is managing the current connection; access to the iOS client also requires an active plan. On Android, if issues occur after the screen turns off, check the system’s background restrictions for the client, but don’t disable all device protections. On desktop, look for other proxies, network filtering tools, or old configurations that may still be active. Make changes to address a specific symptom, keep a way to restore the original settings, and don’t mistake a system difference for a route difference.
How to assess resource use and battery life
For a comparison, keep the device’s power source, temperature, and network conditions similar, use comparable tasks, and observe both foreground use and recovery after idle. System resource monitors can reveal sustained processor use by the client, an unexpected rise in connection count, or frequent background activity, but one peak reading isn’t enough to establish a problem. If the device is hot and throttling, any protocol may perform worse. Stop other high-load tasks and let the device return to normal before testing again.
VPNWB allows an unlimited number of devices to be online at the same time, but that doesn’t mean every device has the same network conditions or that plan data limits don’t apply. When multiple devices share an access network, background syncing competes for local bandwidth. To troubleshoot one device, temporarily pause large transfers on the others and see if the issue persists. If only one device is affected, check its client, permissions, and system network settings before considering a different service route.
Packet loss, queuing, and peak-time congestion
Packet loss doesn’t only happen at the remote end
Packet loss can come from wireless interference, a busy access point, overflowing network queues, route failures, or server resource pressure. To the user, the result may look like waiting, retransmissions, or a dropped connection, but the right response depends on the cause. If the issue improves after leaving the current Wi-Fi access point, check local access first. If only one route has problems on the same network, consider its transit path. The fact that a proxy connection is involved doesn’t mean every lost packet came from the remote route.
Basic connectivity checks also have limitations. Some devices give probe requests lower priority, making the results look poor even while real tasks work. Conversely, a probe target may respond quickly while video delivery or an API remains sluggish. Consider probe results alongside real tasks. Without enough evidence, don’t declare a route faulty based on a single check, and don’t rank results from different targets side by side.
Queuing delays and bandwidth contention
When data is sent faster than a link can handle, it gets queued. A longer queue doesn’t necessarily cause packet loss, but it does increase waiting time. That explains why downloads may continue while webpages and meetings become sluggish. Background uploads, cloud sync, and system updates can also fill queues on the access network. Switching protocols may temporarily change how traffic competes, but it won’t necessarily fix a capacity bottleneck. Pausing large background transfers is often more informative than increasing connection concurrency.
Shared-resource contention may increase at peak times, but congestion doesn’t always occur in the same place. It could be on the local access network, carrier peering, route entry, relay segment, or connection between the exit and destination platform. If multiple regions and protocols slow down at once, check the segments they share first. If only one route slows down, the issue is more likely route-specific. Turn “slow in the evening” into a useful troubleshooting lead by recording the task, access method, and scope of the problem.
Retransmissions, congestion control, and usable throughput
When reliable transport detects a gap in the data, it has to wait or retransmit. Congestion control may also reduce the sending rate. These mechanisms help shared networks keep working; they aren’t arbitrary slowdowns. QUIC and TCP implementations use different recovery strategies, but both are constrained by capacity and packet loss. An implementation that sends more aggressively might achieve higher throughput for a particular task, but it could also crowd out other traffic on the same network. More aggressive settings aren’t universally better.
The size of datagrams a route can carry also matters. Encapsulation takes up space, and if some part of a route can’t handle larger datagrams correctly, a handshake may succeed while larger transfers stall. That’s only one possible cause; a destination service or rule issue can look similar. Start with the client defaults and a known-working comparison configuration. Adjust related parameters only when you have clear guidance for your setup. Don’t copy fixed values circulating online and hope for the best.
Troubleshoot by symptom
If every app is slow, pause background transfers and try a different access method. If webpages work but video keeps buffering, check whether the issue affects only that platform or content. If new connections are hard to establish but existing tasks continue, check DNS, handshakes, and recovery after idle. If one route stays faulty while others work, include its name in your report. Change one condition at a time in each test, rather than layering on changes before observing the result.
Shared networks in hotels and offices may require a sign-in page, have expiring sessions, or restrict certain traffic types. First complete the network’s normal access confirmation without the proxy enabled, then use the client. For travel scenarios, see network access and software for working across borders. If you need support, describe when the issue occurred and what you were doing. Don’t upload a full subscription URL, authentication fields, or business pages containing private information.
Choosing for streaming, work, and AI tools
Web and office apps: prioritize reliable connections
Webpages and collaborative documents often use multiple domains and short requests, so check whether DNS works smoothly, connections are reused, and all resources load. If document text appears but attachments won’t open, a resource domain may not be following the same route; that doesn’t necessarily mean the protocol is too slow. For work, start with a configuration that connects reliably, then check the app’s required domains and rules. Frequently switching exits just to get a lower probe result may disrupt active logins and collaboration sessions.
Meetings combine continuous media with interactive requests, so they depend not only on throughput but also on latency variation and the app’s ability to adapt. Before a meeting, check your microphone, camera, network permissions, and connection to avoid mistaking a device-permission issue for a route failure. For mobile work, check recovery after switching access networks too. Choose a combination the client fully supports and the network can reach. If UDP-based features fail, check the forwarding path instead of switching every work app to the same mode.
Netflix and other streaming services: separate network and region requirements
Streaming needs a stable data transfer, but platforms also determine which content is visible based on exit region, account region, licensing, and their own policies. Being able to open the homepage doesn’t mean every title will play; a title not appearing doesn’t prove the route is slow. To test Netflix streaming, check each stage: opening the platform, accessing the title you want, and maintaining playback. Record where the error occurs. Before choosing a route region, decide which platform region you need and check the account and content requirements.
If playback starts but repeatedly buffers, first check local background transfers, wireless quality, and how other content performs. Then compare different route types in the same region. If the platform explicitly reports a region or proxy-related error, changing congestion settings usually won’t help; check the exit and platform requirements instead. Automatic route selection that frequently changes regions can also affect a session. For streaming, keep a configuration you’ve verified works rather than treating every brief fluctuation as a reason to switch routes.
AI tools: check pages, sign-in, and generation separately
AI tools often use separate service paths for static pages, authentication, generation APIs, and file uploads. If the homepage works but generation fails, the cause may be the API connection, account permissions, platform region policies, or server load—not necessarily a disconnected proxy. First identify whether the error is a network timeout, an expired login, or a message from the platform. Keeping the session and checking the relevant request path is usually more helpful than clearing the cache, switching routes, and changing clients all at once.
Long responses streamed over time can also disconnect because of app timeouts, background sleep, or connection recovery. Keep the device active in the foreground and test the same task before trying another stable route. For uploads, check the access network’s upstream connection separately. Platform requirements for regions, accounts, and paid features are separate from a VPNWB plan. A network subscription doesn’t include third-party platform benefits, and a successful connection doesn’t guarantee access to every AI feature.
Plans determine data allowance; protocols determine how you connect
Choose a plan based on your data needs, not on the assumption that a larger allowance changes protocol performance. VPNWB monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated by the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They remain available until used and never expire. See the full comparison on the plans page. Don’t convert data allowances into a fixed number of hours of streaming.
Data use varies with video quality, compression, content, and app behavior. Using multiple devices at once also changes total usage. VPNWB allows an unlimited number of devices to be online at the same time, but choose a plan based on your actual usage. Payment is accepted via Alipay / WeChat / USDT, and the service offers a 7-day no-questions-asked refund. Keep the selection process simple: test the client and route, confirm the service’s access requirements, then choose a plan based on usage. A higher price isn’t a substitute for diagnosing connection issues.
| Use case | Check first | Then check |
|---|---|---|
| Web and office apps | First screen, resource loading, session continuity | Domain rules, app permissions |
| Streaming | Continuous playback and buffering | Region detection, account, and content requirements |
| AI tools | Test sign-in, generation, and uploads separately | Platform policies, API routes, and account benefits |
| Mobile use | Background behavior and recovery after switching networks | System power saving, UDP reachability |
Connection testing and routine maintenance
Establish a baseline you can restore
Before testing, keep the client’s current working configuration and note the device operating system, client name, access method, route name, and symptoms. If the configuration came from a subscription, confirm it updated successfully and that the plan and data status are normal before checking rules and traffic-capture mode. You don’t need to copy every setting or share authentication fields. A baseline lets you restore the original state if a change doesn’t help; troubleshooting shouldn’t turn into a pile of settings you can’t undo or remember.
If you’re new to the service, start with the full walkthrough in the getting started guide. Client downloads for Windows / macOS / iOS / Android / Linux are available from the user dashboard. Get your subscription after signing in; access to the iOS client also requires an active plan. You can create an account with just a username and password—no email address needed. This guide doesn’t include direct installer links or real subscription examples, so account-managed configurations stay out of public technical documentation.
Test changes with a consistent task
Choose a destination you actually need and check the page, sign-in, main features, and sustained use. First observe the original configuration. Then change only one condition—such as the route in the same region or the access network—and switch back to the original to confirm. If results vary, the environment may still be changing, so don’t rush to a conclusion. Qualitative observations are useful too: “recovery fails after the screen turns off, but foreground use is fine” is more meaningful than a speed figure without test conditions.
Pause other proxy tools during testing to prevent system proxy settings, virtual interfaces, and browser extensions from overriding one another. If you need to disable an existing tool, note how to restore it first; don’t delete system network settings casually. If only one browser has a problem, check its extensions, cache, and DNS settings. If only one app is affected, check whether it follows the system proxy. An app that isn’t routed through the proxy doesn’t mean every protocol in the subscription has failed.
Exit routes, DNS, and privacy boundaries
Use the site’s IP lookup to help check the exit used by the current request. The result only reflects that request’s route; it doesn’t prove that every app on the device uses the same exit. With split routing, different destinations may be expected to use different paths. DNS has its own rules too: encrypted DNS settings in the browser, the client’s DNS policy, and the system cache may all play a part. Check against the traffic scope you expect rather than treating identical routing for everything as the only correct setup.
VPNWB’s service policy is not to keep logs, but apps, operating systems, access networks, and destination platforms may each generate their own data. Browser login states, platform account records, and local caches serve separate purposes. Before submitting diagnostic material, check screenshots for subscription URLs, account credentials, payment details, or private page content. Keep the error type, route name, and relevant status information; remove anything unrelated to troubleshooting. This limits exposure and makes your report easier to review.
When to update—and when to contact support
Subscription updates provide the current configuration; they aren’t a universal fix for every issue. If the client says it doesn’t support a protocol or parameter, first check whether you’re using a suitable client and configuration from the dashboard. Avoid manually deleting or changing settings, which can cause new compatibility problems. Update the system or client when you can restore your working environment if needed. Don’t make last-minute changes during an important meeting or ongoing task. After an update, retest your usual tasks rather than checking only that the client launches.
If you’ve confirmed that your plan and data are in good standing, the issue persists on another access network, and other routes behave differently, describe it in a support ticket from the user dashboard. Include the expected result, what actually happened, the comparisons you’ve tried, and whether the issue is ongoing. Don’t attach your full subscription details. Keep a commonly used route that you’ve verified works, and recheck service requirements when your tasks change. For a broader view of long-term service choices, see long-term subscriptions and how to assess service reliability, and consider connection experience alongside billing, maintenance, and refund policies.