How can you tell if your VPN is working? Compare your public IP first, check DNS next, then test the apps you actually use. A “Connected” status usually means the tunnel or proxy connection is up; it doesn’t mean your browser, work apps, and system updates all use the same route. The key is whether the traffic you’re testing follows the expected path—not whether an icon changed color.
First, distinguish a successful connection from routed traffic
Network access involves apps, system proxy settings, routing, DNS resolution, and the remote exit. Differences in any of these can mean your browser works while other apps don’t, or some sites use the VPN while others connect directly. With rule-based routing, that may be exactly what you configured.
Before testing, clarify your goal: should specific sites use the VPN, or should all supported network traffic go through the tunnel? For the first, check the relevant routing rules. For the second, confirm the client’s global routing or tunnel mode. “Global” can mean different things in different clients, and global proxy mode may not cover apps that don’t support proxies.
| What you check | What it can tell you | What it can’t prove on its own |
|---|---|---|
| Client shows as connected | The client considers the connection established | That every app is using the VPN |
| Your browser’s public IP changes | This request used a different exit address | That other domains or apps use the same exit |
| A public DNS resolver appears in a DNS test | That resolver handled the test domain lookup | That DNS queries definitely went through the tunnel |
| The target app can access the service | The app can access it right now | That the VPN provided the connection |
Public IP check: compare before and after under the same conditions
Your public IP is the address websites see—not your device’s local address on your home network. Open our network test page and note the result, then connect and check again. If the page doesn’t return an address, troubleshoot the test first; a blank result doesn’t mean your privacy is protected.
- Disconnect the VPN, make sure your current connection works, and note your public IP, internet provider, and the region shown on the test page.
- Connect to your chosen route and check that the client reports no authentication, configuration, or connection errors.
- Reopen the test page in the same browser so you’re not relying on content from a previously loaded page.
- Compare the full IP address, and check whether the test site should use the proxy or connect directly under your current rules.
- To check whether switching routes makes a difference, choose another exit and repeat the test. See whether the result matches the client’s routing configuration.
Treat the reported region as a clue, not proof. IP geolocation databases can be out of date, and a server’s registered location may not match its physical location. A mismatch on the map doesn’t necessarily mean the route is broken; seeing the expected region doesn’t prove all traffic is going through the tunnel.
If your IP hasn’t changed, check which routing rule matched first. The test page may be set to connect directly even while your target international site uses the proxy. Temporarily switching to a suitable global routing mode can help you compare results, but restore your original settings afterward. Some exits share a public IP, so reconnecting won’t always give you a different one.
DNS check: review the resolver path, not just its location
DNS translates domain names into addresses your device can connect to. A DNS leak generally means queries that should be protected by the tunnel are instead sent through your local network to an outside resolver. DNS and web traffic are separate checks: your public IP can change while DNS queries still take a different path.
When using a DNS leak test, read how it works first. Compare the resolver names and network affiliations before and after connecting, along with your client’s DNS settings. These tests typically check which recursive resolvers query the test service for a test domain. They reveal only part of the resolution chain, not the full path between your device and the resolver.
- ✅ Check whether the client handles DNS, and which resolution policies it uses for direct and proxied domains.
- ✅ Check your browser’s Secure DNS settings. A browser may use its own resolver, so its results can differ from the system’s.
- ✅ Use your routing settings to determine whether a public resolver is expected; don’t judge by its name or location alone.
- ❌ Don’t assume a leak just because the resolver and exit are in different regions. Public DNS services may use distributed servers.
Encrypted DNS doesn’t automatically route DNS through your VPN. It can protect DNS traffic, but routing determines where that traffic goes. Changing the resolver address alone doesn’t show which traffic the tunnel handles.
If a resolver from your local internet provider still appears after connecting and that doesn’t match your settings, check the client’s DNS forwarding, bypass list, and browser settings. A DNS server shown by a system command is only a clue: some clients use a local forwarder or virtual address, so the address alone may be misleading.
Test apps individually: a working browser doesn’t mean everything works
System proxy settings generally apply to apps that honor them. Some desktop apps, command-line tools, and games use their own networking stack, while browser extensions usually affect only the browser they’re installed in. TUN or system VPN interfaces can handle traffic at a lower level, but exclusions, permissions, and platform behavior still matter.
Desktop: check how traffic is routed
On Windows and macOS, first confirm whether you’re using a system proxy or tunnel mode, then check whether the target app has its own proxy settings. On Linux, desktop proxy settings, environment variables, and routing tunnels may affect different apps. If terminal and browser results differ, don’t assume either test is wrong.
Mobile: check which apps are covered
iOS and Android clients typically need system permission to set up a VPN configuration. Android clients may also offer per-app routing; an excluded app will connect directly. Available options depend on the client. During testing, check whether your connection switched from Wi-Fi to mobile data so you don’t mistake a network change for a route change.
To test an app, close and reopen it, then perform the task you need—for example, load a remote document or join a meeting. Existing connections may keep using their original route. If your client provides connection logs, check the matched rule and exit for the target domain. Avoid sharing screenshots that expose account details, visited domains, or subscription information.
Connected but not routed through the VPN? Troubleshoot by symptom
Websites load, but your IP hasn’t changed
Check your routing rules before repeatedly switching servers. Look for direct-connect rules by domain or region, or app exclusions; then check whether a browser extension is using a separate proxy. If only certain sites need the VPN, a test site connecting directly may be expected—but test the target site’s route separately.
Your IP changed, but the service is still unavailable
This shows that the test request took a different route; it doesn’t mean the target platform will accept that exit. Account region, access permissions, platform policies, and the exit IP’s reputation can all affect the result. Don’t label every restriction a DNS leak, and don’t assume switching routes will necessarily fix it.
Most websites stop loading after you connect
Disconnect and test your regular connection first, then check your account status, available data, and whether the configuration is valid. If you use a subscription link, make sure it updated successfully in a compatible client and that you imported the actual server configuration—not the account webpage. Subscription links may contain access credentials, so don’t post them in public forums or submit them to unfamiliar test sites.
Next, check whether another proxy, VPN, or network filtering tool is running at the same time. These can compete for system proxy settings or routes. Change one setting at a time and note the result. If needed, restore the client’s default network settings; don’t delete configurations required by your workplace network without a backup.
Some addresses connect directly, or your browser reports additional addresses
If your network supports both IPv4 and IPv6, check the exit for each address family in use. If one route isn’t covered, an app may connect directly over the other. For WebRTC test results, distinguish public and local addresses from masked local identifiers. A local address doesn’t necessarily mean your public IP leaked, and seeing no extra address doesn’t prove other apps are protected.
How to interpret results and when to check again
Retest after changing routes, updating the client, modifying DNS, or switching networks. Keep the test conditions consistent and record the exit result, routing mode, target app, and any error messages. That’s more useful for troubleshooting than a screenshot showing only “Connected.”
Bottom line: A meaningful verification confirms that the target request uses the expected exit, DNS follows your configuration, and the app can complete the task you need. Passing any one test doesn’t prove that all traffic is protected.
To learn more about routing and protocols, see our protocol reference. For help setting up a client, start with our guides. If you can’t identify the issue, use the contact page to share your operating system, client version, routing mode, and error message. Hide credentials and private browsing details before sharing.
VPNJoin supports Windows, macOS, iOS, Android, and Linux, with no device limit. No email address is required—create an account with a username and password. Our no-logs policy reflects our privacy stance; it doesn’t replace checking your device settings. The full refund policy is: you can request a no-questions-asked full refund within 60 days of your first payment.