How can you tell if your VPN is really working? Compare your public IP before and after connecting, check your DNS routing, and then test the apps you actually use. A “Connected” status only means a connection has been established; it doesn’t confirm that your browser, games, or work apps are using the intended route.
Here, “working” means your traffic follows the route you configured—not that all traffic must use the same path. With split tunneling, some sites connecting directly may be expected. Decide what you want to test first: otherwise, normal routing can look like a problem, or a working browser can give the false impression that your entire device is covered.
Understand connection status, exit IP, and split tunneling
A subscription link imports nodes and related settings into a client. It isn’t a switch that automatically routes every app through a VPN. After importing, select a working configuration, connect, and grant any required network permissions for your platform. A successful subscription update and access to a target website are separate things to check.
A system proxy usually affects only apps that honor the system proxy settings. A virtual network adapter or system VPN mode can route more traffic, but behavior still depends on routing, excluded apps, and how the client works. In some clients, “Global” sends all requests that have reached the proxy core through the proxy; it doesn’t necessarily cover every app.
| What you observe | What it tells you | What it doesn’t confirm |
|---|---|---|
| The client shows “Connected” | The client reports that a connection or tunnel is established | That every app is using the intended exit route |
| The IP shown by a lookup page has changed | The public exit IP used for that page request has changed | That other apps and DNS requests use the same route |
| A DNS test identifies a resolver | The test observed the corresponding DNS resolution path | That the resolver’s location must match the exit location |
| The target app can access a service | The request for that particular action completed | That media, uploads, and background connections all use the same route |
Check your exit IP: establish a baseline
Open the IP lookup page and note your public IP, network provider, and approximate location before connecting. Then connect to the node you want to test and reopen the lookup page on the same network. Avoid changing networks and nodes at the same time, or you won’t know what caused the result to change.
- Record the lookup result before connecting. Don’t mistake the local address assigned by your home router for your public exit IP.
- Connect to the target node and confirm the active configuration and node name—not just that the tray icon is lit up.
- Reload the lookup page. If you suspect a cached result, close and reopen it or check in a separate browser window.
- Compare the IP address and network provider, then check whether the location matches the node’s expected region. If needed, verify with another lookup service.
IP geolocation databases may lag behind, and city-level results are especially unreliable as a measure of route quality. A mismatch between the node name and the city shown doesn’t prove the route is broken. Consider the network provider, whether the destination is reachable, and the service’s documentation. Conversely, a matching location doesn’t confirm speed, privacy settings, or routing in other apps.
If your split-tunneling rules route the lookup page directly, seeing your local exit after connecting may be exactly what your configuration intends. You can temporarily route the lookup domain through the proxy or switch to a test mode after confirming what it will cover. Restore your usual rules afterward; don’t change routing for every app just to make the test result look right.
DNS test: check the route, not just the location
DNS translates domain names into addresses. A web request going through a proxy doesn’t necessarily mean the DNS lookup does too. DNS may be handled by the operating system, your browser’s Secure DNS, the client’s resolver, or a remote proxy, so test it separately.
DNS test pages usually use test domains to observe the resolver’s public exit. They don’t show every leg of the network path, and the resolver may not be the server your device connects to directly. Public DNS providers may use distributed servers, so a reported location that differs from your VPN exit isn’t, by itself, proof of a leak.
A more useful approach is to write down the expected behavior—for example, “resolve proxied domains remotely and keep direct domains on local DNS”—then compare it with your client’s DNS settings and the test results. If proxied requests are supposed to keep DNS lookups off your local network but you consistently see your local provider’s resolver, investigate possible routing around the proxy.
With encrypted DNS enabled, your browser’s results may differ from the system resolver’s. Encryption protects some of the DNS traffic, but doesn’t prove it uses your current proxy. Check your browser and client settings separately, changing one setting at a time. Don’t treat disabling encrypted DNS as a universal fix or use DNS addresses from untrusted sources.
The system command nslookup can show the default resolver and a domain’s response, but it usually won’t reproduce browser Secure DNS or a client’s remote DNS behavior. It’s normal for command-line results to differ from a web test: they may be checking different routes. Don’t use either result alone to make a judgment about your entire device.
Test each app: don’t assume the browser represents everything
Once your browser test passes, open the apps you actually need and test sign-in, content loading, and real tasks. An app may use several domains: a working login page doesn’t mean file uploads, voice calls, or media requests use the same route. Test the scenarios that matter to you instead of just checking whether the home page loads.
Desktop apps on Windows and macOS don’t always follow the system proxy; games and some command-line tools especially need separate checks. On Android, per-app proxy rules may exclude the app you want to test, and work-profile apps may have separate policies. On iOS, check which VPN configuration is active and whether another network feature is changing your browser’s route.
- ✅ Check that the app is included in the proxy scope, and review per-app exclusions and rules that send domains directly.
- ✅ Use the same node for a real task, then check the target domain and routing result in the client’s connection view.
- ✅ Restart the app after changing rules so existing connections don’t keep using the old route.
- ❌ Don’t treat a web page loading, visible node latency, or a finished speed-test animation as proof that your target app is routed correctly.
The connection view can show which rule matched a request, but may not include traffic that never reached the client. If you enable temporary diagnostic logging, remove account details, full subscription links, and browsing destinations before sharing it. Subscription links contain access credentials; don’t submit them to public test sites or post them in comments.
Connected but not routed: common troubleshooting checks
The exit IP hasn’t changed, but the client shows no error
First check that the system proxy or VPN permissions are enabled, then see whether the lookup site is set to connect directly. Browser proxy extensions and custom proxy settings can also override system settings. Temporarily disable overlapping configurations and test again to avoid multiple proxy tools changing your network settings at once.
Some requests use a different exit, while others still go direct
Along with split-tunneling rules, check which address families are covered. Your device may have more than one type of public address while the client routes only one of them. If your lookup tool supports it, test each separately and check whether the client can route all traffic or explicitly block uncovered paths. Don’t call the test complete based on just one result.
DNS looks normal, but the app still won’t load
A successful lookup only means an address was returned; it doesn’t mean the service is reachable. The issue could also involve the node connection, destination-side restrictions, certificate time settings, the app’s own proxy configuration, or network compatibility. First try another destination with the same configuration, then test a different node. Don’t keep changing DNS every time access fails and risk making your configuration harder to troubleshoot.
The connection icon stays on after switching networks, but access stops working
A network change can break an existing connection before the app updates its status. Reconnect, check your exit IP again, and open the target app instead of relying on the status icon. To test disconnect protection, deliberately interrupt the connection and see whether requests can still get through. Protection options and coverage vary by client; don’t assume they’re enabled.
Keep reusable test notes
State the limits of each test—for example: “On this network and node, the browser exit matched expectations, DNS for the test domains followed the configured route, and the work app was tested.” That’s more useful than a blanket “VPN is working.” Repeat the same checks after changing clients, updating rules, or switching networks.
When reporting a problem, include your platform, client name, network environment, node region, and steps to reproduce it. Say what you observed for the exit IP and DNS separately. Don’t share passwords or full subscription links. For supported platforms and setup steps, see the Guides. For details on routing coverage, see the route and protocol guide.
Bottom line: You can confirm the route is working for a specific scenario only when the exit IP matches expectations, DNS follows the configured route, and the target app passes a real-world test. No single check replaces the others, and test results don’t guarantee security beyond what was tested.