How can you tell if your VPN is really working? Don’t rely on the connection icon alone. Compare your public IP before and after connecting, check your DNS resolution path, then test the apps you need one by one. The goal isn’t to change all your traffic, but to make sure requests that should use the VPN actually take the expected route.
These checks work for both your operating system’s built-in VPN and proxy clients that import nodes from a subscription link. They may handle traffic differently: connecting to a node only confirms that the connection is up. You still need to test how your browser, desktop apps, and background services behave.
First, distinguish a successful connection from traffic routing
A typical request involves resolving a domain, choosing a route, and connecting to a service. A client’s connected status may mean a tunnel is established or simply that its proxy core is running. Whether an app uses that connection also depends on system proxy settings, a virtual network adapter, routing rules, and the app’s own network settings.
A system proxy setting tells apps that honor it to send relevant requests through a proxy. It doesn’t route all traffic on the device. TUN mode uses a virtual network adapter and routing to handle IP traffic, often covering more, but exclusions, permissions, protocol support, and configuration still matter. Global proxy mode may route only requests that have already reached the client; it doesn’t automatically send every app through it.
| Check | What it shows | What it can’t prove on its own |
|---|---|---|
| Client connection status | Whether the core, tunnel, or node has connected | Whether requests from the target app go through the node |
| Browser public IP | The public IP used by that browser to reach the test site | Whether other apps and address families use the same route |
| DNS test | The recursive resolvers handling the test domain and related clues | The route used by all traffic and the full privacy boundary |
| Client connection logs | The rules, policies, and outbound route used by a request | Whether the remote service will allow access or an action to succeed |
| The target app in use | Whether the required task works on the current route | Whether every app on the device is routed through the client |
Public IP: compare before and after under the same conditions
While disconnected, open a trusted public IP checker in your browser. Note your public address, address family, and network provider. Then connect to your chosen route and reload the same page in the same browser. Use a checker that reports details about the current request, rather than one that only shows cached information.
If the test request matches a proxy rule, the public IP will usually change to the route’s remote egress IP. A location that matches your selected region can provide supporting evidence, but geolocation databases may be outdated or inconsistent. Don’t assume a route is faulty just because the city name differs, and don’t mistake a private LAN address for your public IP.
- Record your public IP before connecting, and make sure no other proxy extensions are running in the browser.
- After connecting, check the current mode and make sure the test domain isn’t set to connect directly by a rule.
- Run the test again and compare the addresses. If needed, close the old tab to avoid reusing an existing connection.
- Check the client logs and compare the route used for the test domain with the result shown on the page.
- Disconnect and test again to confirm the change came from this connection, not another proxy or a network switch.
Devices that support both IPv4 and IPv6 need to be checked on both. Some configurations handle only one address family, so the browser may use the other route. If you need relevant public traffic to use the VPN, confirm that both are covered or follow the client’s documentation for an appropriate blocking policy. Don’t stop after seeing one address change.
DNS: check the resolution path, not just the country
DNS translates domain names into addresses. A DNS leak usually means requests that should be protected are taking an unexpected route—for example, being handled by your local network’s resolver. DNS and your traffic’s public egress are separate: a web request can go through a node while its domain lookup still happens locally.
Common DNS test sites generate test domains and observe which recursive resolvers look them up. The addresses shown usually belong to DNS services, not your traffic’s public egress. Public resolvers may use anycast, caching, and forwarding, so their listed locations may not match where requests are actually handled. A resolver being in a different country from your node isn’t, by itself, proof of a leak.
The more useful questions are: Which resolver should your current setup use? Does the client handle system DNS? Has the browser enabled its own encrypted DNS? If you expect remote resolution but keep seeing your local ISP’s resolver, investigate further. Conversely, not seeing your ISP’s name doesn’t prove that DNS is protected for every app.
- ✅ Check the client’s DNS mode, remote resolution settings, and DNS policy for domains set to connect directly.
- ✅ Review the browser’s Secure DNS settings and check whether they operate independently of the client.
- ✅ Run a fresh test after changing settings so cached results or old connections don’t skew the outcome.
- ✅ Compare the domain, destination address, and outbound route in the client logs to see whether DNS and the connection behave as expected.
- ❌ Don’t treat a resolver’s name or location—whether it matches or differs—as proof of security or a leak.
Some clients use Fake-IP, returning a synthetic address to the app and mapping it internally to a domain and an outbound route. These addresses differ from regular public DNS results and don’t necessarily mean DNS is broken. If LAN devices, corporate intranet domains, or specific apps stop working, check the relevant exclusion rules rather than replacing the entire DNS setup.
Test apps individually: a working browser doesn’t mean other apps are working
Browsers, command-line tools, games, and desktop apps may use different network stacks. Browsers often honor the system proxy, while command-line programs may rely on environment variables or their own proxy options; some apps ignore system proxy settings altogether. Mobile clients may also have app allowlists or exclusion lists, so test the apps you actually need.
Windows and macOS
Disable browser proxy extensions first so they don’t override system settings. When testing a desktop app, check whether the client logs show connections from its process or to its target domain. If browser requests appear in the logs but the app’s don’t, check the app’s proxy settings, the client’s routing mode, and virtual network adapter permissions. Managed work devices may also have organization-enforced network policies; don’t override them without authorization.
Android and iOS
Make sure the operating system has allowed the client to establish a VPN connection, then check whether the client offers and has enabled per-app routing rules. On Android, also check background activity and battery restrictions: losing the connection after switching apps or locking the screen is different from failing to connect in the first place. On iOS, routing depends on the client’s implementation and system configuration, so desktop instructions may not apply.
Command-line tools and background tasks
A terminal request doesn’t automatically use the same route just because a browser can connect. Check whether the tool reads proxy environment variables and whether it resolves domains locally or sends them to the proxy for resolution. A successful terminal response doesn’t prove the request went through the node; compare the public IP and client logs. Scheduled tasks may also run in a different environment from your interactive terminal.
Test with real, low-risk actions, such as refreshing app content or requesting a public resource. Simply opening an app’s home screen may show cached content and won’t prove where a new request goes. Don’t repeatedly submit payments, publish content, or perform other irreversible actions just to test the connection.
Connected but not working? Diagnose by symptom
A successful node latency test only shows that the test request received a response. Access to a particular service can still depend on DNS, routing rules, transport, and remote restrictions. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC refer to different protocol options; their presence doesn’t prove that traffic is being routed through the client. The client must support the protocols and configuration used by the subscription.
| Symptom | Possible cause | Next step |
|---|---|---|
| Connected, but the public IP hasn’t changed | The test domain connects directly, the system proxy isn’t working, or the app isn’t routed through the client | Check which rule and outbound route matched the request |
| Browser works, but other apps don’t | The app ignores the system proxy, is excluded, or uses a different transport | Check the app’s settings, routing coverage, and protocol support |
| Public IP changed, but the target site still denies access | Service region policies, account restrictions, or reputation checks on the egress IP | Check the service’s message; a denial doesn’t automatically mean the proxy has failed |
| After switching routes, the old public IP still appears | An existing long-lived connection wasn’t reopened, or the page is showing an old result | Quit the relevant app, try again, and check the connection logs |
| Connection fails after locking the screen or switching networks | Background restrictions, a failed tunnel reconnect, or routes that weren’t restored | Restart the client and reconnect, then test the target app again |
IEPL, relay, and direct connection describe a route or transport method; none of them handles traffic routing on your device. Even with a dedicated route, incorrect split-tunneling rules can send requests directly. Conversely, a relay can forward traffic as configured. Route type is no substitute for cross-checking your public IP, DNS, and app behavior.
Record your findings before changing settings
Change one relevant setting at a time and keep a copy of the original configuration so you can restore it. First, confirm the subscription imported successfully and the node is available. Then check whether the target request reaches the client, verify the outbound route and DNS, and finally review any message from the target service. If you change the node, resolver, and rules all at once, you won’t know what fixed the problem—even if it goes away temporarily.
If you need help, use the support page to share your device operating system, client name, mode, the circumstances in which the issue occurs, and the checks you’ve already tried. Blur subscription links, usernames, passwords, tokens, and other private information in screenshots. A subscription link is a configuration credential: don’t paste it into public testing sites or post the full link in a discussion forum.
VPNGQ’s Guides cover installation and importing subscriptions, while the complete guide can help you review your configuration. Marketing claims such as “anonymous, no logs” describe the service’s privacy policy; they don’t erase browser sign-ins, website tracking, or app account information. Confirming that a route works and managing account privacy are separate tasks.