How can you tell if your VPN is really working? Check your public IP first, then DNS, and finally the routing rules in the app you want to use. A connection icon only shows that the system or client has established some kind of connection; it doesn’t prove that every app or domain is using the route you expect. The right test is whether requests that should use the VPN do so, while requests set to connect directly still take that route.
Compare results before and after connecting
Pause background tasks such as downloads and syncing, then note your current network, client mode, and the apps you plan to test. If you’re accessing the device remotely, don’t disconnect the connection keeping that session alive; make sure you have a way to recover access first. Keep the same network during testing so a network change doesn’t look like a VPN-induced IP change.
Temporarily disconnect the VPN and visit a reputable public IP lookup site. Note the address, ISP, and approximate location. Reconnect the client, then refresh the same page. Your IP address is personal network information, so keep the full result private rather than posting it publicly.
With split tunneling, a lookup site may be set to connect directly under your rules. Choose a test destination that should use the VPN, or temporarily set that destination to use the proxy before comparing results. “Global” mode in a client usually applies a selected policy to requests the client has already captured; it doesn’t necessarily route all traffic from the device.
- Note your public IP while disconnected and the test page’s domain.
- Make sure your subscription is imported, a node is selected, and the proxy or tunnel is enabled.
- After connecting, reload the page and check the IP change against the rule for that destination.
- If you switch modes to test, note the original setting and restore it afterward.
Keep these three questions separate. A successful subscription update only means the configuration was retrieved. A node probe getting a response only means the probe received a reply. For this use case, the key test is whether the target app’s request uses the expected exit route.
Check the public IP, not just the location label
A public IP lookup shows the source address of the request to that site. If the address changes after connecting and the client logs show the domain matched a proxy rule, that supports the conclusion that this browser request used the proxy. It doesn’t prove that other apps do the same.
Location labels come from IP databases, which may be out of date. A node name may refer to an entry point or route group, not the location of the exit IP. If the location doesn’t match, compare results from other reputable lookup sites and check the route details. Don’t assume the connection has failed based on a city label alone.
| What you see | What it tells you | What to check next |
|---|---|---|
| Browser exit IP changed | The exit IP changed for this test request | Is the target app also routed through the client? |
| Exit IP unchanged; rule is direct | Split tunneling may be working as intended | Test a destination that should use the proxy |
| Exit IP unchanged; rule is proxy | The request isn’t taking the expected route | Cache, system proxy, tunnel settings, and bypass rules |
| Exit IP changed, but the platform still shows the same region | The exit IP isn’t the platform’s only signal | Account region, location permissions, and existing sessions |
| Results differ between IP address families | Traffic capture may differ by address family | Check client routing support for each address family |
On dual-stack networks, check both IPv4 and IPv6. A browser may prefer one, while the client captures only the other. Use a tool that reports each separately and check the client documentation for supported routing. Don’t disable system networking features just to make a test page show all green results.
Check DNS routing and distinguish leaks from split tunneling
DNS translates domain names into IP addresses. A DNS test usually has your browser visit a test domain, then reports which recursive resolver handled the test query. This gives you a clue about the resolver, not the full DNS path for every app on your device, and it doesn’t show how all your traffic is transmitted.
Start by deciding what you expect. If a domain should resolve through the tunnel but the query goes to a resolver on your local network, investigate further. If a domain set to connect directly is using local DNS, that isn’t necessarily a leak. What matters is whether the actual route differs from your stated configuration.
Your browser’s secure DNS, the system’s encrypted DNS, and the client’s DNS module may all affect resolution. Using encrypted DNS in a browser doesn’t automatically route the request through the proxy; encrypted DNS can connect directly too. If a test shows the name of a public resolver, check the route taken by the DNS request rather than judging by the name alone.
- ✅ Check whether the client captures DNS and which resolution policy it uses for proxied and direct domains.
- ✅ Check the browser’s secure DNS and system DNS settings. Note any differences, then test each setting separately.
- ✅ After making a change, clear the relevant DNS cache or restart the test app to trigger a fresh lookup.
- ❌ Don’t assume that a resolver outside your region means the request went through the proxy.
- ❌ A clean test page doesn’t prove that no traffic on your device is bypassing the VPN.
When troubleshooting a conflict, change one setting at a time and retest. If you change the node, browser, and DNS settings together, you won’t know which change made a difference. Once the expected behavior returns, restore any protection you temporarily disabled and run one final test.
Test each app individually—not just your browser
If the browser works but other apps don’t, the client may be capturing different traffic for each. On Windows and macOS, the system proxy generally affects apps that follow system proxy settings. Apps that ignore those settings, use their own proxy, or open network connections directly may take a different route.
Virtual network interface modes such as TUN can capture more traffic, but routing, exclusions, permissions, and client implementation still matter. “Global rules” and “TUN capture” aren’t the same setting. The first determines how the client handles requests it has captured; the second affects which traffic can reach the client.
Android clients may let you include or exclude apps from proxy routing. Check what the selected list means: are checked apps routed through the proxy or excluded from it? iOS Personal VPN configurations differ from per-app VPN on managed devices, so don’t assume every client lets you choose any app. Available features depend on the client and operating system.
Test a real action in the target app
Fully quit the target app, reopen it, and perform an action that needs a network connection, such as refreshing content, searching, or loading media. Seeing an old page isn’t a successful test; it may have come from cache. Then check the client for a matching connection, the rule it matched, and the policy group it used.
Some apps connect to multiple domains, so a successful login doesn’t mean media requests are working too. Test sign-in, content listings, and actual playback separately. Platforms may also consider your account region, payment region, device location, and session history when deciding what content is available. Test against the platform you want to use rather than assuming access is guaranteed.
Local client connection logs can help you check routing rules, but may include the domains you visit. Turn off detailed logging when you no longer need it. Before sending information to support, hide subscription links, credentials, and unrelated browsing records.
Common reasons a VPN can look connected when it isn’t working as expected
The subscription was imported, but the configuration isn’t enabled
A subscription link gives you access to nodes and configuration; it isn’t a connection by itself. Make sure it’s imported into a compatible client, the configuration is enabled, and a working policy is selected. Subscription links often contain access credentials, so don’t share them with public testing sites. With VPNPO, get your subscription from the account panel after signing in; download access is determined by the panel.
The protocol is supported, but the traffic capture mode doesn’t fit
Support for protocols such as Shadowsocks, VMess, Trojan, and VLESS depends on the client core and the specific configuration. A protocol name alone doesn’t mean system traffic is being captured. If importing fails, check the subscription format and core compatibility first. If the browser works but other apps don’t, check the proxy mode and per-app rules.
Treating a route label as proof that the VPN is working
Labels such as IEPL, relay, and direct describe how a route is organized; they don’t replace testing on your device. A relay typically forwards traffic through an additional entry point, while a direct route typically doesn’t use that kind of relay entry. An IEPL label alone doesn’t prove how all your traffic is actually carried. Whichever route you choose, check the exit IP, DNS, and app requests.
A browser extension or another network tool is routing the request
Browser proxy extensions, other VPN clients, and enterprise network tools may override your settings. Keep any essential connections active and check for conflicts one tool at a time, following its instructions. If the browser’s exit IP changes but the client shows no matching connection, the browser may be using another proxy rather than the current client.
Choose test services carefully. Checking your public IP and DNS doesn’t require a subscription link, password, or payment details. Stop if a site asks you to upload a complete configuration or install an unfamiliar certificate to continue.
Check connection protection and browser traffic separately
If your setup should block internet access when the VPN disconnects, check whether the client offers a kill switch and read how it interacts with system settings such as “Always-on VPN.” Save your work, then deliberately disconnect in a controlled environment. Check whether the target app can make new external requests, reconnect, and test again.
A browser WebRTC test may show local network addresses, masked hostnames, or public candidate addresses. A local address appearing doesn’t mean your public exit IP has been exposed. If a public address appears that shouldn’t be visible, check your browser policy, UDP routing, and the scope of the client’s traffic capture.
A changed public exit IP doesn’t erase your account identity. The service you’re using may still access your sign-in state, cookies, and device permissions. VPNPO’s privacy policy is not to keep logs, but that service policy doesn’t replace checking your device settings or prove that a website won’t record the visits it receives.
Bottom line: test requests, not icons. Check the target request’s exit IP, verify its DNS route, then review the rules for each app. If the results match, the VPN behaved as expected for the tests you ran. Retest the relevant use cases after changing networks, client settings, or rules.
If you still can’t find the cause, note your operating system and client, the mode in use, the affected app, the matched rule, and any differences in redacted test results. Continue with the troubleshooting guide or report the issue via the support page. Describing which request didn’t take the expected route is usually more helpful than saying only that the VPN connects but doesn’t work.