How can you tell whether a VPN is working? You cannot rely only on the client showing “Connected.” That status usually means the client has established a session with a remote node; it does not prove that all traffic from your browser, command-line tools, and target apps is using the expected exit. A reliable check starts by recording your network baseline while disconnected, then checking your public IP, DNS resolution path, system and app routing rules, and finally the service you actually intend to use.
During testing, distinguish between “the tunnel is established,” “traffic is entering the tunnel,” and “the target service is reachable.” A tunnel may be active while an app keeps an old connection; your web exit may change while DNS still follows local network policy; and even when both the exit and DNS look right, account region, content licensing, risk controls, or service terms may affect access. Layered troubleshooting is more useful than repeatedly switching nodes.
Establish a network baseline while disconnected
Do not judge the result while already connected. Disconnect the client, close the browser tabs and target app you are testing, and record your current public network details. You can use the IP lookup on this site to check your public IP, network organization, and detected region. Then connect to the node you plan to test and check again in a new browser window.
When comparing before and after, focus less on whether a test page shows a prominent “protected” message and more on whether your public exit changed as expected. The organization associated with an IP may appear as a data center, cloud provider, or upstream network rather than the subscription brand. Regional databases can also differ or lag behind. Treat the organization name as supporting evidence, not proof that the connection failed.
- ✅ Record your current public IP and detected region after disconnecting.
- ✅ Fully quit the app under test to avoid reusing an existing network session.
- ✅ Reopen the app or a private window after connecting to the selected node.
- ✅ Check the exit again and confirm that the change matches the selected region.
- ❌ Do not judge the connection only by the client animation, status-bar icon, or connection timer.
The region shown by a test site comes from an IP database, not your device’s physical location. Database labels can occasionally lag, so assess the result together with the exit change, routing behavior, and target app response.
Check the public IP and actual traffic path
Your public IP is the most obvious check, but different programs on the same device may use different paths. A browser showing the node’s exit does not mean that games, download tools, terminal commands, or system updates use the same route. Many clients support rule-based routing and proxy only matching domains or addresses; unmatched connections go directly through the local network. That may be intended split tunneling—or it may indicate that the rules do not match your expectations.
Test from the app you actually need to use by making a new request. Open a private browser window, fully quit and restart a desktop app, or run the command again. If only the browser’s exit changes, check browser extensions, its independent proxy settings, and whether the client is in browser-only proxy mode. If the browser does not change while other programs do, prioritize checking the browser’s own configuration.
| Observed symptom | Possible cause | Suggested check |
|---|---|---|
| Client is connected, but the public IP is unchanged | The target traffic does not match a proxy rule, or the app is not reading the system proxy | Change the rule scope, restart the app under test, and check the public IP again |
| The browser exit changes, but other apps do not | The browser uses an independent proxy, or the client handles only some apps | Check the app proxy, system proxy, and tunnel mode |
| The exit matches expectations, but the target service still fails | The account region, cached session, service policy, or app network settings differ | Check the service requirements before signing in again, then create a completely new connection |
| The old exit is still shown after switching nodes | An old connection is still open, or the test page is using cached data | Close the app session, use a new window, and make the request again |
WebRTC information in the browser also needs careful interpretation. Modern browsers may use localized candidate addresses or privacy mechanisms to hide some interface details, so seeing a local-network candidate does not necessarily mean that your public address has leaked. Focus on whether the page can obtain a public exit that should not be exposed and whether that exit bypasses the expected route.
Check whether DNS matches your routing intent
DNS translates domain names into network addresses. A DNS leak generally means that queries expected to use a controlled resolution path are instead sent to the local network or another unintended resolver. But do not conclude that there is a leak just because a test page shows a local resolver: some routing modes intentionally send local domains to local DNS and proxied domains to a remote resolver. Browsers may also use their own encrypted DNS, making their resolution path different from the system settings.
The right test is whether DNS behavior matches the configuration’s intent. If the client uses a full tunnel and specifies remote resolution, queries consistently reaching the local network deserve investigation. With domain-based routing, seeing both local and remote resolvers may be by design. Check the client’s DNS mode, system network settings, browser secure DNS option, and the rule matched by the target domain.
- ✅ Confirm whether the client uses global, rule-based, or direct mode.
- ✅ Check whether the browser has encrypted DNS enabled independently of the system.
- ✅ Compare resolution results from system apps and the browser.
- ✅ See which proxy or direct-connection rule the target domain ultimately matches.
- ❌ Do not equate the presence of multiple resolvers with a leak.
DNS caching can also complicate the diagnosis. After switching nodes, the operating system and apps may continue using addresses resolved earlier. Start with low-risk steps such as closing the app, reconnecting the network session, and refreshing the client configuration. Before clearing the system cache, confirm the correct procedure for your platform so a network configuration issue is not mistaken for a cache problem.
Troubleshoot stale connections, caches, and app proxies
Many “connected but not working” problems come from old sessions. Browsers, messaging tools, and desktop apps that use persistent connections may have established TCP or QUIC sessions before you switched nodes. After the client connects, those existing sessions may not move to the new path immediately, so test results can appear contradictory for a while.
The solution is not to keep clicking the connect button; it is to make the app under test create a genuinely new session. Quit the program completely, confirm that its background process has ended, then connect to the node and reopen it. In a browser, use a new private window to rule out existing tabs, extension caches, and site sessions. For developer tools, download tools, or chat apps with built-in proxy support, also check whether their settings override the system proxy.
Common overrides include an app specifying a fixed proxy address, a browser extension forcing another route, command-line environment variables retaining an old proxy, and containers or virtual machines using separate network stacks. Even when the system-level client works correctly, it may not automatically rewrite these independent settings. During troubleshooting, temporarily remove extra layers and keep one clearly defined network entry point.
- Disconnect from the current node and fully quit the target app.
- Check whether the app’s own proxy, browser extensions, and system proxy are overriding one another.
- Reconnect to the node and wait until the client clearly reports that it is ready.
- Open a completely new app session, then check the exit and target access again.
- If the issue affects only one app, focus on that app’s network permissions and proxy settings.
Do not run multiple clients that modify the system proxy or virtual network adapter at the same time. When configurations compete, every interface may show a successful connection, while the final route depends on the interface and rules the system actually uses.
Understand protocols, subscriptions, and route names
A subscription link is usually a distribution entry point for a set of node configurations. After import, the client parses node addresses, ports, authentication material, transport methods, and routing information. A successful import only means that the client recognized the configuration; it does not mean every node can connect. When subscription content changes, refresh it in the client instead of repeatedly pasting an old link. A subscription link may contain access credentials, so do not share it publicly or include it in screenshots.
Shadowsocks is common in the proxy-tool ecosystem; VMess, VLESS, and Trojan are supported by different client cores and server implementations; Hysteria2 and TUIC place greater emphasis on UDP-based transport designs. Protocol names describe communication and encapsulation methods; they do not prove an exit region, route quality, or compatibility with a target service. At import time, first check whether the client supports the protocol, transport parameters, and subscription format.
“Direct,” “transit,” and “IEPL dedicated line” describe different aspects of network organization. Direct usually means reaching a remote entry point from the user side; transit means entering an intermediary first and then forwarding traffic to the exit. IEPL is often used for international carrier circuits or related enterprise network products, but naming conventions vary across market pages. A node name alone cannot verify the real topology or turn a label into a guarantee of stability.
Traceroute can provide clues about the path, but it does not always show the complete chain. Some network devices do not respond to probes, while intermediate addresses may be hidden or shown as internal carrier addresses. Use traceroute to compare whether the path has changed noticeably, not to prove a route’s commercial category by itself. Whether the connection works still comes down to the exit, DNS, matched rules, and target app result.
Verification priorities on each platform
Windows
Windows clients may take over traffic through the system proxy, a virtual network adapter, or both. The system proxy depends more on whether an app follows proxy settings; virtual-adapter mode usually covers more programs but remains subject to the routing table and exclusion rules. Check that the system proxy is restored correctly and that no other network tool is modifying it at the same time. Whether a command-line program reads the system proxy depends on the program’s own implementation.
macOS and iOS
Clients on Apple platforms generally establish a tunnel or proxy configuration through a system network extension. The status-bar icon indicates that the configuration is enabled, but you still need a new request to verify the exit. Per-app rules, domain rules, and the system’s privacy networking features can change the path for some traffic. If only one app behaves abnormally, first check whether it is reusing an old session instead of immediately deleting every configuration.
Android
Android shows system VPN permissions and connection status, but battery-saving policies, background restrictions, and settings such as “allow selected apps only” can affect actual coverage. After switching between mobile and Wi-Fi networks, the old tunnel may need to be established again. Test by reopening the target app after the network switch is complete and confirming that the client remains connected.
Linux
On Linux, desktop proxies, environment variables, routing policies, and container networking may operate independently. A successful browser test does not mean terminal requests automatically use the same proxy, and a container may have different DNS and default routes. Make clear whether the test is running on the host or in an isolated environment, then check the default route, resolver configuration, and app environment variables separately.
How to assess an unavailable target service
When the public IP, DNS, and routing rules all match expectations but the target service remains unavailable, the question is no longer simply whether the VPN is working. The service may consider the account’s registration region, payment details, previous sessions, device location permissions, content licensing, and its own risk controls. Network reachability does not mean every account feature is available, and one successful visit does not guarantee continued access.
At this point, read the target service’s published regional requirements and terms, then test with a fresh session. Avoid switching repeatedly between regions and retrying continuously, as this can make the diagnostic picture less clear. If the page opens but sign-in or playback fails, record whether the failure occurs during DNS resolution, connection establishment, account verification, or the content request. Separating these stages helps determine whether to keep investigating the network or review the target service account settings.
- ✅ The public IP points to the selected region as expected.
- ✅ The DNS path matches the client’s current routing design.
- ✅ The target app has closed its old session and restarted.
- ✅ The app has no second proxy overriding the system settings.
- ✅ The target service’s account region and published usage requirements have been checked.
- ❌ Do not equate a page opening with every feature being available.
Troubleshooting sequence for connection problems
When something goes wrong, keep the number of variables as small as possible. Start with one node, one device, and one target app, then expand to other environments. First confirm that the subscription is refreshed and that the client supports the node protocol; then check the system time, network permissions, proxy conflicts, and routing mode. If switching networks fixes the issue, the current access network may be involved. If every network shows a problem in only one app, the app configuration is more likely responsible.
VPNLZ provides access to 100+ countries and 150+ routes. After selecting a node, still verify the actual exit and target requirements using the steps in this guide. Accounts use a username and password, with no email address required; if you need to change clients or import the subscription again, get the current entry point from the user panel. When reporting an issue, include only the failure stage, platform, client connection status, and selected region. Do not share the subscription link, password, or complete authentication details.
Only then decide whether to rebuild the configuration. Deleting it also removes routing rules and local adjustments, so it should not be the first step. Refreshing the subscription, restarting the app, and removing conflicts preserves more diagnostic clues. If you still cannot establish a session, describe the symptoms in a panel ticket. Separating “cannot connect,” “the exit did not change,” and “only one app is affected” is usually more useful than saying vaguely that the network is unavailable.