To check whether your VPN is working, verify your public IP, check DNS, and test each app separately. The connection icon is only a starting point: it may mean a local proxy is running or a tunnel is established, but it doesn’t prove that requests from a particular app are going through the VPN.
Don’t rely on a single website. Compare results before and after connecting, then check your routing rules. This guide follows a practical sequence, requires no deep networking knowledge, and doesn’t ask you to install tools from unknown sources.
Connection Status vs. Actual Traffic: Know What You’re Testing
A VPN client may use a system-wide tunnel or simply provide a local proxy. A system proxy typically affects apps that honor the system’s proxy settings. Virtual network adapter or TUN mode attempts to capture traffic at the network layer, but exclusions, routing, and the client’s implementation still matter. Neither mode name alone tells you which traffic is covered.
Likewise, Shadowsocks, VMess, Trojan, and VLESS describe connection protocols; they don’t mean every app’s traffic is routed through them. IEPL, relay, and direct describe the route between endpoints, not how traffic is routed on your device. Check where a request goes before evaluating the route itself.
| Check | What it can confirm | What it can’t confirm on its own |
|---|---|---|
| Client shows connected | The client reports that the connection or proxy is active | That a specific app’s requests are actually using the VPN |
| Public IP comparison | The address seen by the site for that test request | That other apps or address families use the same route |
| DNS test | Clues about the recursive resolver used for the tested domain | That every DNS query follows the same route |
| App-by-app check | How a particular app behaves with the current settings | That the same result will persist after changing networks or rules |
Compare Public IPs: Record a Baseline Before Connecting
Your public IP is the source address remote websites see, not your device’s local network address. Disconnect the client, open a public IP lookup page in your browser, and note the address, network provider, and test time. Then connect to the route you want to check and repeat the test in the same browser on the same page. Avoid switching local networks during the test, so you can tell whether a change came from the VPN or the network.
- Record your public IP while disconnected. If the page lists IPv4 and IPv6 separately, save both results.
- Connect to the route, then confirm the selected node and proxy mode in the client before running the test again.
- Check whether the address changed. If it didn’t, see whether the test domain is routed directly by your rules.
- If the client supports it, temporarily switch to global proxy rules and test again. Restore your usual rules afterward.
- Check the client’s connection log to see which rule matched the test domain and which exit it used.
“Global” often means that the client applies proxy rules consistently; it doesn’t necessarily mean all device traffic is being captured. A successful browser test only confirms that the browser’s request took the expected route. You still need to check the apps you use.
DNS Tests: Check the Resolution Path, Not Just the Location
DNS translates domain names into IP addresses. Routing web requests through a proxy doesn’t mean DNS queries follow the same path. Browser Secure DNS, operating-system settings, the client’s DNS module, and an app’s own resolver may all be involved. A DNS leak generally means queries are leaving the intended protected path—not simply that a test shows a local region.
Choose a DNS test page that displays resolver details. Run it while disconnected and save the results, then connect and test again. These pages typically use a temporary test domain to identify recursive resolvers; they don’t show the complete network path between your device and the resolver. Public DNS services may also use location-based routing, so the resolver’s location need not match the VPN exit.
If the test still shows your local ISP’s resolvers after connecting, check whether the client handles DNS, whether your rules allow local resolution, and whether Secure DNS is configured separately in your browser. Don’t change everything at once: record your original settings, then adjust and retest one at a time. Otherwise, even if the result changes, it’ll be hard to tell which setting made the difference.
With split tunneling, local domains may use local DNS while international domains use a specified resolver. That may be exactly how your rules are designed. First clarify whether you want all queries to use a specific route or want DNS routed by domain, then assess whether the results match. A passing DNS test doesn’t replace checking your public IP and app traffic.
Test Apps Individually: A Working Browser Doesn’t Mean Every App Works
Test the apps you actually need, not just a test website. On Windows and macOS, some apps use the system proxy while others have their own network settings; command-line tools may only read proxy environment variables. Android clients may let you include or exclude individual apps. On iOS, check the current client configuration and routing rules. The exact menu may vary by client version.
Fully quit the app you’re testing, then reopen it to avoid reusing an existing connection. Visit a page that refreshes online content but doesn’t involve sensitive activity, and check the client’s connection log at the same time. If the app has no requests in the log, check whether it’s excluded or ignores the system proxy. If requests appear, inspect the matching rule and exit instead of repeatedly reinstalling the app.
- ✅ Browser: Check for separate proxy settings in extensions, Secure DNS, and the VPN client.
- ✅ Desktop apps: Check whether the app uses the system proxy. If needed, follow its official instructions to configure an in-app proxy.
- ✅ Mobile apps: Check the per-app routing list and make sure the app you’re testing isn’t excluded.
- ✅ Command-line tools: Check proxy environment variables and bypass lists. Don’t assume terminal results reflect what happens in your browser.
- ❌ Assuming that because a webpage loads, the VPN is working for every app on your device.
If your client supports virtual network adapter mode, you can enable it and test again by following the client’s guide, but it won’t necessarily solve every issue. Insufficient permissions, routing conflicts, excluded apps, and unsupported traffic types can all affect coverage. When troubleshooting, keep only one client actively capturing traffic to make the cause easier to identify.
Connected but Not Routing Traffic? Narrow It Down by Symptom
Public IP unchanged, but some websites work
The most common explanation is split tunneling: the test page uses a direct connection while the target site uses the proxy. Check the rule-matching log, then temporarily switch rules and test again. Your browser may also be reusing an old connection; close the relevant tabs and restart the browser before testing. Don’t delete all your settings based on a single result.
Public IP changed, but a service still reports the wrong region
A service may also consider your account region, payment details, device location permissions, previous sessions, or the reputation of the exit IP. A changed IP only confirms that the current request uses a different exit; it doesn’t guarantee the service will accept access. Check the service’s own terms and distinguish the website’s route from the app’s. Account-level restrictions shouldn’t automatically be blamed on DNS.
Browser works, but an app keeps failing to connect
First check whether the app bypasses the system proxy, then look for failed requests in the connection log. Some apps also rely on UDP or a separate background service, which may take a different route from web traffic. A successful browser connection doesn’t prove those connections will work too. Check the client’s documentation for support of the traffic you need; don’t change protocols blindly.
Problems after switching networks or waking the device
Switching networks can change the default route, and waking from sleep may leave stale connections. Reconnect the client, restart the app, and rerun the public IP test. If your basic network connection can’t reach familiar websites, troubleshoot your local connection first. If you already have a subscription, check its status in the dashboard. Being able to import a subscription only means the configuration was read; it doesn’t guarantee that the current node is available.
Test Results and Support Requests: Keep Reproducible Evidence
A thorough check should answer: Which app did you test? Which mode was active? Which rule matched the request? Did the public IP and DNS behave as expected? You don’t need to run a speed test for a long time to prove that you’re connected. Throughput and latency measure performance, but they can’t replace route verification.
How to tell: You have good reason to say the VPN is working for the current scenario when the target request uses the expected exit, DNS follows your intended routing policy, and the app has corresponding connection records. A successful browser test doesn’t prove that every app or all traffic has been tested.
If you need help, include your operating system, client name and version, selected mode, time of the issue, target domain, and error message, along with redacted rule-matching logs. Hide subscription links, account credentials, and unrelated browsing records before sharing screenshots. Subscription links often contain access credentials; don’t post them in public forums or share them with unfamiliar testing sites.
VPNSouth users can review the Guides for client setup and connection instructions, then submit the details above through a support ticket in the dashboard. Change one setting at a time and save the before-and-after results; this makes it easier to identify the cause than repeatedly switching between nodes.