VPN Connection Test: Check Your IP and DNS
A connected status doesn’t mean your traffic is using the VPN. Check your IP and DNS, test apps individually, and troubleshoot common connection issues.
How can you tell whether a VPN is working? Don’t rely on the connection icon alone—check your IP address, DNS query path, and whether the apps you need actually work. Before testing, note your IP and DNS results without the VPN so you can compare them afterward. A successful browser test doesn’t mean every app is using the VPN.
Distinguish connection status from traffic routing
“Connected” may mean a system tunnel is established, or simply that a local proxy has started. The exact meaning depends on the client. If an app doesn’t use that proxy, or its domain matches a direct-connection rule, it may still use your regular network.
System proxy settings usually affect only apps that follow them. A virtual network adapter can route more traffic, but routing rules, excluded apps, protocol support, and DNS settings still matter. “Global proxy” doesn’t necessarily mean every connection on the device goes through the tunnel. Check the client’s documentation and test it yourself.
| Test | What it can tell you | What it can’t confirm on its own |
|---|---|---|
| Client shows “Connected” | The client reports that the connection is established or the proxy has started | That every app is using the selected route |
| Your public IP changes on a web check | That this web request used a different exit | That other apps or address families use the same route |
| A DNS test lists resolvers | That the listed resolvers handled queries for the test domains | That the resolvers’ locations match the VPN exit location |
| The app you need works | That the app’s current feature is accessible | That all traffic is proxied or every privacy risk is eliminated |
Compare your IP before and after to verify the VPN
Choose a reputable public IP lookup site and use the same one before and after connecting. It should show your public IPv4 and IPv6 addresses, along with location details. The site can see the IP address your request comes from. Don’t upload subscription links, account credentials, or your full client configuration just to run a test.
- Record your results without the VPN. Disconnect the client, look up your public IP, and note the address, network provider, and reported location. A local network address isn’t your public exit—don’t substitute the device’s IP from system settings.
- Connect to your chosen route. Confirm the client has selected the intended exit and check its current mode. Don’t change browser proxy settings, DNS, and routing rules at the same time, or you won’t know which change affected the result.
- Run the test again. Refresh the page. If the result looks suspicious, close the old tab and open a new one. If needed, cross-check with another reputable testing service.
- Compare the result with what you expected. If the address changes and its reported network details broadly match the selected exit, the web request likely used the intended route. If they don’t match, check your rules and client logs rather than relying on the location label alone.
IP geolocation databases can lag behind, and the route name may not exactly match the location reported by every testing site. Conversely, a changed address alone doesn’t prove the VPN is working—switching networks or having your provider assign a new address can also cause a change. Keep your network connection the same while testing.
Check DNS, not just the reported location
DNS translates domain names into IP addresses. A DNS leak generally means queries that should follow a specified or protected route are being sent another way—for example, through a local network resolver outside the tunnel. To tell whether that’s happening, consider the client mode, routing rules, and browser settings together.
Run a test on a reputable DNS leak test site and note the organizations operating the listed resolvers. Compare the results with the VPN disconnected. If a resolver from your local network appears after connecting, and the test domain is supposed to use the proxy, check whether DNS routing is working. But a resolver being shown in your local region doesn’t prove there’s a leak; public DNS services may use nearby servers or centralized exits.
Browser Secure DNS and client DNS work at different layers
A browser may resolve domains through encrypted DNS instead of using the resolver set by your operating system. In that case, seeing a public DNS service on a test page isn’t necessarily a problem. Also check whether the connection to that DNS service goes directly or through the proxy. Encrypting DNS queries and changing their route are two different things.
System DNS lookup tools can help you investigate how the operating system resolves names, but they can’t replace a browser-based test. A tool may query a server you specify directly, while the browser may use its own cache or encrypted DNS. Seeing the system’s resolver name doesn’t prove that every webpage uses the same DNS route.
Save your original settings first. Check the client’s recommended DNS configuration, then review browser Secure DNS, custom resolvers, and routing rules one at a time. Don’t treat switching to a public DNS service as a universal fix: it may change the resolver without fixing queries that bypass the proxy.
Check split tunneling and address families for each app
Browsers, desktop apps, and command-line tools may use different network settings. A browser using the system proxy doesn’t mean a download tool or meeting app will use it too. For each app you need, try the relevant feature, check whether it works, and review the client’s connection logs to confirm the route.
- ✅ Check whether browser proxy extensions override system settings, especially rules that switch by site.
- ✅ In the client’s connection logs, check the destination domain, process, and matching rule to see whether the connection is proxied or direct.
- ✅ Test public IPv4 and IPv6 separately. If your device has no working IPv6 connection, note that IPv6 couldn’t be tested; don’t treat a missing result as a leak.
- ✅ Check for in-app proxies, environment variables, and exclusion lists that may conflict with system settings.
- ❌ Don’t take a successful speed test, a connection icon, or a webpage loading as proof that every app is using the VPN.
If IPv4 uses the VPN but IPv6 still shows your regular network exit, first check whether the rule allows a direct connection to that destination and whether the client supports and routes IPv6. Prefer settings provided by the client. Don’t leave system networking features disabled if you’re unsure of the effects.
How to interpret WebRTC test results
Browser real-time communications may use a different route from regular web requests. If a test page shows your public IP from before connecting, check how the browser and client handle this traffic. A private address on your device or a masked local hostname isn’t the same as a public IP leak. Identify the type of address first, then determine whether your original public IP is exposed.
Common reasons a VPN looks connected but isn’t working
The subscription imported, but the right connection wasn’t enabled
Importing a subscription adds route configurations to the client; it doesn’t turn on the proxy. First confirm the subscription updated successfully and the intended route is selected. Then check that the system proxy or virtual network adapter is enabled. Download the client and get your subscription from the user dashboard, subject to the applicable login and plan requirements.
The client also needs to support the protocols and configuration format used by the subscription. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC aren’t interchangeable names. If importing fails, check client compatibility and the subscription format rather than editing protocol fields yourself. This article doesn’t make any claims about which protocols VPNMT offers.
Multiple proxy settings are overriding one another
Browser extensions, old clients, and manually configured system proxies can all be active at once. Quitting an old app doesn’t necessarily remove the settings it left behind. During troubleshooting, keep only the connection method you need, check whether system settings point to a local proxy that’s still running, and save your original configuration so you can restore it.
Old connections and cached rules can affect your results
Apps may reuse existing connections, and DNS lookups may come from a cache. After switching routes, close and reopen the app you’re testing, then make a new request. A private browsing window can reduce interference from some browser data, but it won’t necessarily clear the system DNS cache or make the app use a new route.
Mistaking a route type for proof that the VPN works
Direct connections, relay routes, and IEPL dedicated lines describe a transport path or delivery method. They don’t prove that your device’s traffic is using that route. Even if an exit IP test succeeds, the destination service may restrict access based on account region, content licensing, or network risk controls. Test encryption, exit location, and service access separately.
What to check on different platforms
Windows and macOS: Check system proxy settings, virtual network adapter permissions, and potential conflicts with other networking software. If a browser works but a desktop app doesn’t, first check whether the app follows the system proxy. Then see whether a client-supported virtual network adapter mode is needed.
iOS and Android: First confirm the connection is enabled in system settings. Then check whether the client excludes any apps or applies per-app routing. Retest after switching between Wi-Fi and mobile data, as a change in network access can affect routing and DNS behavior.
Linux: Desktop proxy settings and environment variables used by terminal tools may be independent. Background services may not inherit the current terminal’s settings either. Test the browser, terminal, and app you need separately; one process’s results don’t verify the others.
VPNMT supports Windows, macOS, iOS, Android, and Linux, with no device limit for simultaneous connections. Test each device separately, especially when routing rules and browser DNS settings differ.
How to document a verifiable result
Keep the before-and-after exit results, current mode, name of the app you tested, and relevant rule match records. If you need help, share only the details related to the issue. Before sharing screenshots, hide usernames, subscription links, tokens, and any network address details that aren’t needed.
What counts as verified: A request that’s supposed to use the proxy goes through the intended exit, DNS follows the current configuration, and the app works as expected. Limit your conclusion to the device, app, and mode you tested; don’t generalize it as a guarantee for all traffic.
If the issue persists, check the exit, DNS, and app rules in that order. Change only the relevant setting at a time, then repeat the same tests. Military-grade encryption can’t replace route verification: connection status, encryption, and the actual traffic path all need to be checked separately.