Connected Doesn’t Mean Everything Is Protected
How can you tell if your VPN is working? The most useful approach is to check your public IP, DNS, and the apps you want to use. A “Connected” status usually means the local VPN feature is on or a session has been established with a server. It doesn’t prove that your browser, meeting app, and terminal are all using the expected international route.
First, define what you need to verify: should a particular overseas website use the proxy, or should every app supported by the VPN go through the tunnel? With rule-based routing, local websites connecting directly may be the expected behavior. Don’t treat the same public IP for every website as the only sign of success, or assume everything is working just because one page loads.
Record a Baseline Before Connecting
Keep your network setup unchanged while testing. Pause other proxy extensions or clients so they don’t interfere with each other. If you use a hotel network before connecting and switch to another network afterward, a changed IP won’t prove the VPN caused it.
- Record your original public IP. Disconnect the VPN client and visit a reputable public IP lookup site in your browser. Note the IP address, network provider, and location. Don’t share screenshots that show your full IP address.
- Record your DNS results. Run a DNS leak test in the same browser. Note the detected recursive DNS resolvers and their network providers—not just the locations shown on a map.
- Connect and note the mode. Record the selected server, whether you’re using system proxy or tunnel mode, and the active routing rules. Change one setting at a time to make the cause easier to identify.
- Start a fresh connection. Close the old test tabs and reopen the lookup page. If needed, quit and restart the app you’re testing so it doesn’t reuse an existing connection.
You don’t need a complicated speed-test report. A short note listing the app, mode, destination, expected route, and actual result is usually more useful than repeatedly switching servers. Subscription links contain access credentials; never paste them into test sites, public posts, or screenshots.
How to Check Your Public IP Accurately
Your public IP is the address the destination server sees as the source of your connection. After connecting, compare the results in the same browser and on the same lookup page. If the IP changes from your local internet provider’s address to a network associated with the selected server, that web request took a different route. This only tells you about the request you tested—not other apps.
The city shown by an IP lookup site may come from an outdated geolocation database. A server’s name, registered address, physical location, and the location a website identifies may not match exactly. If lookup services show different cities, compare the public IP and network provider first. A map label alone doesn’t mean the route is failing.
Check IPv4 and IPv6 separately, too. If one address type uses the proxy while the other connects directly, an app may choose a route based on its own connection behavior. Check the client’s current settings and documentation to see which traffic it handles. Disabling a network protocol isn’t a universal fix.
| What You See | Possible Explanation | Check First |
|---|---|---|
| Browser IP has changed | The tested webpage request used a new IP | Check the target app and DNS next |
| Browser IP is still on the local network | The lookup site connected directly, or the browser isn’t using the proxy | Rules for this domain, extensions, and system proxy settings |
| Webpages work, but desktop apps don’t | The app may not follow the system proxy or may have its own settings | The app’s proxy options and which traffic the tunnel handles |
| IP has changed, but DNS still shows the local network | DNS queries may not be going through the tunnel as expected | Client DNS settings, browser Secure DNS, and exception rules |
| Lookup services show different locations | Different databases, address types, or routing rules | The actual IP, network provider, and connection logs |
A DNS Test Is About More Than Location
DNS translates domain names into addresses used to connect. A DNS leak usually means a domain lookup that should be protected by the tunnel was accidentally sent to a resolver over a route outside it. A changed public IP doesn’t automatically mean DNS traffic took a different route. Conversely, a DNS resolver and your public IP being in different locations doesn’t necessarily indicate a leak.
Public DNS services may use anycast and different egress points, so a location shown by a test page is only a clue. If you expect DNS queries to follow the tunnel, check whether a local internet provider’s resolver still appears and whether the client logs explain those queries. A test site usually sees the resolver’s public IP—not the full path each query took from your device.
Browser Secure DNS Can Change the Results
Your browser may use its own encrypted DNS service instead of the system settings. Encryption describes how queries are protected; it doesn’t guarantee they go through the VPN. First, note whether Secure DNS is enabled in your browser, then compare its configuration with the client’s documentation. If you change it temporarily for troubleshooting, restore it afterward or make a deliberate choice about which policy to keep.
Interpret Command-Line Results in Context
On Windows, you can run the command below in Command Prompt. On other systems, first check that the relevant tool is available. This example uses a sample domain; the command only shows the result returned by the tool in your current setup.
nslookup example.comThe server field in the output can help identify the resolver the tool is contacting, but a local forwarder or the client’s virtual DNS may sit in between. It may not be the final recursive resolver. Your browser may also use a different DNS path, so this command isn’t a substitute for a browser DNS test—and the returned address alone can’t tell you which route a webpage used.
Check Proxy Settings and Routing by App
System proxy settings provide a proxy for apps that follow them; they don’t guarantee that every network request is handled. Browser extensions may only affect the browser, while some desktop apps have their own proxy settings. TUN or a system VPN tunnel routes traffic through a virtual network interface, but exclusions, destination networks, protocol support, and routing rules still affect what’s covered.
“Global” mode in a client also depends on what the interface means by that term. It may send all requests that have already reached the proxy engine to one policy, without routing every app into the engine. On Windows and macOS, distinguish the system proxy setting from the tunnel switch. Even when a VPN icon appears on mobile, check the client’s routing rules and app exclusions.
- ✅ Browser: Check your public IP and DNS, and make sure proxy extensions aren’t overriding system settings.
- ✅ Desktop apps: Restart the app, make a real request, and look for the process or domain in the client’s connection logs.
- ✅ Command-line tools: Check the tool’s own proxy options and environment variables; don’t rely on browser results.
- ✅ Rule-based routing: Make sure the destination matches a proxy rule—not a direct, blocked, or excluded rule.
- ❌ Don’t treat a system tray icon, connection duration, or one speed test as proof that every app is covered.
For example, whether curl in a terminal uses a proxy depends on its arguments, environment variables, build, and network routing mode. Don’t assume it follows the desktop system proxy. First check whether the app’s traffic reaches the client, then see which route it takes. That’s more useful than reinstalling the client right away.
What to Check When You’re Connected but Can’t Browse
First, check whether the client can load your current subscription and server list. A successful import only means the client read the configuration; it doesn’t mean every server in it is available. Update your subscription through the service dashboard and check that the client supports the configuration. Never share your username, password, or full subscription link with an unfamiliar online converter.
Next, check whether the target request appears in the connection logs. If there’s no entry, start with system proxy settings, tunnel permissions, and the app’s own settings. If there is an entry but it uses a direct route, check the rules. If the proxy is selected but the connection fails, check server availability, restrictions on your current network, and the client’s error message. Logs may include domains you visited and local paths, so redact sensitive details before asking for help.
If your public IP and DNS look right but an AI tool or streaming service still reports that your region isn’t supported, don’t assume the VPN isn’t working. Platforms may also consider your account region, payment details, past sessions, and IP reputation. You can start a new session and check the platform’s guidance, but that doesn’t guarantee regional restrictions will be lifted.
Finally, distinguish a correct route from a good connection experience. Checking your public IP doesn’t tell you the route’s bandwidth, latency, or stability, or whether an intermediate link is a dedicated IEPL line. “Transit” and “direct” describe connection or forwarding paths; a dedicated line refers to the underlying network. Check the service documentation for details instead of inferring the route type from the IP location.
Privacy Considerations After Testing
Confirming that a VPN is working only verifies the traffic path within the scope of your test. It doesn’t mean websites can’t identify an account you’re signed into. Cookies, account sessions, browser fingerprints, and information you submit can still link your activity. If a WebRTC test shows a local address, distinguish a private address from one that’s publicly routable; seeing a local network address alone doesn’t prove your public IP is leaking.
9DVPN’s privacy policy is anonymous and no-logs. Privacy policies and device settings are separate matters. No email address is required; create an account with a username and password. Keep your credentials secure, review app permissions, and verify your traffic as needed. For connection setup, see the Quick Start Guide. If you encounter a specific error, use the Help page to document what happened.