How can you tell if your VPN is working? Check your exit IP first, then DNS, and finally the apps you actually use. A connected status only confirms that one part of the connection is established; it says nothing about whether your browser, messaging app, or other traffic is using the route you expect.
Separate connection status, exit IP, and app results
A subscription link provides server configuration, the client imports it and establishes a connection, and routing rules determine which requests use that connection. These steps are related, but they are not the same. Importing a subscription successfully doesn’t mean a server is reachable, and a reachable server doesn’t mean every app is using it.
System proxy settings route traffic through a local proxy for apps that respect those settings. TUN mode uses a virtual network interface to capture traffic, often covering more apps, but routing rules, excluded apps, and client implementation still matter. A mode labeled “Global” doesn’t necessarily capture all device traffic, so check what it actually does.
| Check | What you can observe | What it cannot prove on its own |
|---|---|---|
| Client status | The client reports a connection, or the proxy service is running | The target app’s requests have passed through a remote exit |
| Exit IP | The source address shown by an IP lookup page | Other apps and domains use the same route |
| DNS test | The resolvers involved in the test and their network details | All DNS requests on the device follow the same settings |
| App-specific test | Whether the request matched a rule, connected, and worked as expected | The same behavior will hold on every network in the future |
Check your exit IP: record a baseline, then compare
Your exit IP is the source address a website sees when it receives your request, not your device’s address on a local network. Start with the What’s my IP? page and compare the results before and after connecting. Don’t rely on the country label alone; the address and network provider details are more useful for checking whether your traffic took a different route.
- Record the result while disconnected. On your current network, pause the client connection and open the lookup page. Note the exit address and network provider. If another proxy or work tunnel is running on the device, check whether it could affect the result.
- Connect to the server you want to test. Confirm that it’s selected and note the client’s mode. If the subscription was just updated, check that the selected server hasn’t changed.
- Run a fresh lookup. Refresh the page, or close and reopen the tab if needed. If the lookup tool has a button to run the test again, use it to avoid treating an old result as current.
- Check where the request went. If your client shows a connection list, check which rule matched the lookup domain and which exit it used. If the result hasn’t changed, first check whether that domain is set to connect directly rather than assuming the server is at fault.
- Check with another server. Switch to a different exit and run the lookup again. If both servers share an exit, the address may be the same; use the client’s connection details and server information to assess the result.
With split tunneling, the lookup page may connect directly while international sites use the proxy. An unchanged exit IP doesn’t prove that the VPN isn’t working at all. To troubleshoot, temporarily switch to an explicit proxy rule and compare results on the same page. Restore your original split-tunneling settings when you’re done.
IP geolocation databases may not be up to date. A city that doesn’t match the server name doesn’t prove the server is misrepresented. Likewise, seeing the expected region doesn’t prove that every app is using the VPN.
Check DNS: follow the resolution path, not just the location
DNS translates domain names into IP addresses. A website connection can go through a proxy while the domain is resolved on your local network. Whether that’s a DNS leak depends on what you expect: if DNS lookups should also use a particular route, local resolution needs investigating. If your rules allow local domains to connect directly, local resolution isn’t automatically a problem.
DNS test pages usually use dedicated test domains to identify recursive resolvers and show their addresses or network details. They don’t reveal every DNS request from your device, and may not show the upstream resolver configured in your client. Public DNS services may use distributed networks, so a difference between the resolver’s region and your exit region isn’t enough to prove a leak.
How to run a useful DNS comparison
- Run the full test while disconnected and connected. Save the resolver addresses and network details instead of noting only a region label.
- Check the client’s DNS settings for remote resolution, DNS interception, or rule-based upstream selection. Options may have different names in different clients.
- Check your browser’s Secure DNS settings. A browser may use encrypted DNS independently rather than the system resolver. Whether those connections use the proxy depends on the actual routing.
- Run the test again after changing settings. System and browser caches, as well as existing connections, can affect the result. Restart the app you’re testing if needed.
Encrypted DNS protects DNS traffic in transit; it doesn’t automatically route requests through the VPN. Conversely, seeing a public resolver in the test doesn’t mean traffic bypassed the VPN. Stronger evidence comes from matching the request’s client rule, upstream DNS settings, and test results.
On Windows, macOS, or Linux, you can use the command below to check system DNS resolution. It can help you understand your system’s setup, but it isn’t a full DNS leak test and doesn’t replace testing in your browser.
nslookup example.comThe command and your browser may use different DNS resolution paths. Some TUN clients may also return addresses used for internal mapping; that isn’t necessarily an error. Don’t replace your DNS settings just because you see an unfamiliar address. First check the client’s documentation for how its DNS modes work.
Test apps individually: a working browser doesn’t mean everything works
After checking the exit IP and DNS, test the app you actually want to use. Open the feature you need, then look for its process or domain in the client’s connection list. Check whether it matched a direct, proxy, or reject rule, and whether a connection was established. Don’t just open the app’s home screen: sign-in, video playback, and downloads may use different domains.
Desktop browsers can usually use the system proxy, but standalone proxy extensions, separately configured browser profiles, and Secure DNS can change the route. Command-line tools, games, and other desktop apps may not use the system proxy. If the browser works but another app doesn’t, first check which traffic is being captured. If needed, configure an app proxy or TUN mode as described in the client documentation.
A VPN status icon on a mobile device only means that a network configuration is active. Android clients may let you include or exclude specific apps, and iOS clients may also use split-tunneling rules. Coverage depends on the client and its configuration; the status bar alone doesn’t tell you what’s routed.
- ✅ Perform an actual task in the app you’re testing, then check its connection; don’t rely only on a browser lookup page.
- ✅ Check the matched rule and selected exit to make sure the request wasn’t sent directly or excluded.
- ✅ Review standalone proxy settings, the system proxy, and the client mode to avoid multiple configurations handling the same request.
- ✅ After switching servers, restart the app so existing connections close, then repeat the same test.
- ❌ Don’t treat a webpage loading as proof that all traffic uses the VPN, or assume playback failure means the VPN isn’t working.
Streaming services and AI tools may also check your account region, exit IP reputation, or supported regions. So an access failure and a routing problem are different issues. Check the traffic route first, then review the app’s message. For more, see VPNBX’s streaming guide and AI tools routing guide. Avoid masking the real cause by repeatedly changing settings.
Common reasons a VPN looks connected but traffic isn’t routed
The client is running, but the system proxy is off
Some proxy clients can start a local listening service without changing the system proxy. The interface may say the client is running while your browser still uses your regular network. Check the system proxy setting or network capture mode. If you use TUN, make sure it has the required permissions and the virtual interface is working. A successful subscription update only means the configuration was retrieved; it doesn’t mean requests are being routed through it.
Rules don’t match the request
A direct-connection rule may match the target domain first, or a rule update may have moved it to a different group. Checking which rule actually matched is more useful than guessing which category the domain should belong to. When testing a rule change, change just one setting and keep the original so you can tell whether the issue is with the rule or the server.
Some network traffic isn’t covered
Your device may have both IPv4 and IPv6 connectivity. If the client handles only one, an app that uses the other may take a different route. Check the client’s IPv4 and IPv6 support and settings; disabling IPv6 isn’t a universal fix. UDP and QUIC traffic also need suitable support. If webpages work but real-time communication fails, check the relevant forwarding capabilities.
Misleading results from configuration, protocol, or existing connections
A subscription link is a configuration source, not a client app. After importing it, select a server and confirm that the client supports the configured protocol and transport. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC aren’t interchangeable labels. If a protocol isn’t supported, choosing a similarly named option won’t fix compatibility.
The server type also doesn’t determine whether an app’s traffic is captured. IEPL describes a particular network transport arrangement; relay and direct connections describe different paths. None of these replace the device’s proxy, DNS, or split-tunneling settings. Existing sessions may also persist after switching servers, so start a fresh request before judging the result.
Final checks and what to include when asking for help
Be specific about what you’ve verified: the target request matched the expected proxy rule, the lookup showed an exit consistent with that route, DNS resolution followed the expected policy, and the app completed the task. A single green status, region label, or lookup result cannot guarantee that all traffic on every device is routed as expected.
If you still can’t tell, note your device OS, client name, current mode, server name, time of the test, and any error messages. Include the exit IP before and after connecting, DNS test results, and the rule matched by the target request. This makes it easier to separate issues with traffic capture, DNS resolution, the server, and app restrictions.
Before sharing screenshots or diagnostics, hide subscription links, access tokens, and account credentials. Subscription links may contain usable access credentials, so don’t post them in public comments. Check diagnostic logs for personal domains you’ve visited, too.
Start by checking the VPNBX setup in the getting started guide. Confirm the client and subscription settings, then test requests in the order described here. Change one relevant setting at a time and keep a record of the results; that usually makes it easier to pinpoint the cause than changing the server, DNS, and mode all at once.