VPN Connected? Don’t rely on the client’s connection indicator alone. Compare your public IP before and after connecting, check the DNS resolution path, then test the apps you actually use. Together, these checks show whether the traffic you care about is using the selected route.
It helps to distinguish a few things: the client can connect to a route without the system sending traffic through it; a browser can use the proxy while a meeting app does not; and a correct exit region does not guarantee that a service will allow access. Follow these practical checks in order.
First, distinguish connection status from what’s actually working
A VPN client may use the system VPN interface, the system proxy, or a virtual network interface in TUN mode to handle traffic. What gets routed depends on the client, its mode, and its routing rules—not just the app’s name.
| What you see | What it tells you | What to check next |
|---|---|---|
| The client says connected | The client has established a connection | Whether any actual requests are using the route |
| The browser’s public IP has changed | This browser request used a different exit IP | Other apps, IPv6, and routing scope |
| A DNS test shows a remote resolver | The test domain was resolved by the listed resolver | Whether the resolver matches your expected settings |
| The target app works | The current app’s access path is working | Whether the app is using the intended route |
A successful latency test is only supporting evidence. Some clients test connection setup; others check the response from a specific URL. Neither replaces testing the service you actually need. And if a site works over your regular connection, simply opening it does not prove the proxy is active.
Compare your public exit IP before and after connecting
- Establish a direct-connection baseline. Disconnect the client and make sure no system proxy settings are still active. Open the IP lookup page and note your current public IP, network provider, and region. Don’t mistake your device’s local network address for its public IP.
- Connect to the route you want to test. Make sure your subscription has been imported and the server list has loaded, then select a region. You need to log in to get a VPNMid subscription. See how to get a subscription for details.
- Run the check again. Refresh the lookup page after connecting, or close the old tab and open a new one if needed. Compare the full IP address, not just the country—your exit IP can change within the same country.
- Check the routing rules. If the result hasn’t changed, open the client’s connection log and check whether the lookup domain matched a direct, proxy, or block rule. If the lookup page is set to connect directly, that doesn’t mean other sites are bypassing the route.
IP geolocation comes from a database, not your device’s live location. Out-of-date data can make the detected region differ from the selected route. Check the IP and network provider first, then compare how the target service identifies your region. Don’t rely on the city name alone.
Your exit IP does not have to match the server address shown in the client. The connection entry point and the IP websites see can differ, especially on relayed routes. Compare the public IP that websites actually see.
Check DNS without treating resolver location as the whole story
DNS translates domain names into IP addresses. Even when a website connection goes through a proxy, DNS lookups may be handled by your system, local network, client, or browser’s encrypted DNS. So a correct public IP and an expected DNS path are related, but separate, checks.
Use a DNS test that triggers fresh domain lookups, check which resolvers it lists, and compare them with your client’s DNS settings. Results usually identify recursive resolvers; they may not show which server your device contacted directly. A resolver’s location alone also cannot confirm whether a leak occurred.
When to investigate further
If you expect all domains to use remote DNS but the test keeps showing resolvers provided by your local network, check your system DNS, the client’s DNS handling, and your browser’s Secure DNS settings. A browser’s separate encrypted DNS may bypass the client’s DNS policy, but that does not mean your queries were exposed in plain text to the local network.
Split-tunneling rules may intentionally use a local resolver for direct connections and a remote resolver for proxied domains. Interpret the result in light of those rules. Don’t change DNS servers just to make a test page show a particular country; incorrect settings can break resolution or make DNS results inconsistent with the actual exit IP.
After changing settings, reconnect and run a fresh lookup. Old cached results can hide changes. Browser and system DNS caches are separate, and private browsing does not necessarily clear every DNS cache.
Verify individual apps and check how the proxy handles traffic
A working browser is just a starting point. System proxy settings only apply to apps that honor them; some desktop apps, command-line tools, and real-time communications may not. TUN mode routes matching traffic through a virtual network interface, but is still subject to routing, permissions, exclusions, and protocol support.
- ✅ Browser: Open the site you want to test, then check the client’s connection log for its domain, matched rule, and actual exit IP.
- ✅ Desktop apps: Quit the app completely and relaunch it before testing. Existing long-lived connections may keep using the old route.
- ✅ Calls and voice chat: Test an actual call, not just the sign-in page. A page loading successfully does not prove that real-time media traffic is routed too.
- ✅ Command-line tools: Check the tool’s own proxy options and proxy environment variables. They may be configured separately from the system proxy.
What to check on each platform
On Windows and macOS, distinguish the system proxy setting from the TUN setting. Check whether the client is allowed to create a network interface, and whether another network tool is changing proxy settings at the same time. On Linux, desktop proxy settings may not cover terminal apps, so check each app’s documentation.
On iOS and Android, check that the system allows the client to establish a VPN connection and whether app exclusions or per-app proxy settings are configured. Android’s background restrictions can also interrupt the client. Menu names vary by platform; use the settings available in your version of the client. See the setup guide for more help.
If your IP hasn’t changed or an app still fails, troubleshoot by scope
Nothing changes in the browser or apps
First, confirm that the selected route isn’t set to connect directly, then check whether the system proxy or TUN mode is enabled. Pause other proxy tools to prevent conflicting settings, then look for the test request in the connection log. If there’s no entry, check traffic handling before switching exit routes repeatedly.
If the log shows a proxy request that failed to connect, check whether the subscription is up to date, your account has traffic available, and your system clock is correct. A subscription URL is an access credential: don’t post it in public groups or paste it into untrusted online conversion tools. Hide the URL and any tokens before sharing screenshots for help.
Only some apps fail
Check app exclusions, domain and process rules, and the app’s own proxy settings. Once you understand what will be affected, temporarily switch to a broader proxy policy to compare results, then restore your usual routing rules. Global proxy generally means that requests handled by the client use the proxy; it does not automatically cover every network connection on the device.
The browser looks fine, but you’re concerned some traffic may bypass the proxy
Check IPv4 and IPv6 separately. If the client handles only one type of connection, the other may still use your local network. If you expect all traffic to be routed, adjust the routes or client settings. If you intentionally use split tunneling, verify that the rules work as designed.
Check address types when running a WebRTC test. A browser may reveal local network addresses or hide them behind mDNS names; neither means your public IP has leaked. What matters is whether a connection that should use the proxy exposes your original public IP.
The exit IP is correct, but the service still denies access
A service may also check your account region, payment region, device location, past sessions, or IP reputation. Start a fresh session and review the service’s requirements. A correct exit IP confirms only part of the network path; it does not prove that you meet the platform’s access requirements.
Confirm it with repeatable results
Change one setting at a time and repeat the same checks: look up your exit IP, run a DNS test, open the target app, and review the client log. If you switch routes, change DNS, and reinstall the app all at once, it’s hard to tell what fixed the problem.
Protocol names such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC don’t replace these checks. Client support for the protocols and transport settings in your subscription determines whether a connection can be established correctly. System proxy, TUN, and routing rules determine which requests use it.
Likewise, IEPL dedicated lines, relays, and direct connections describe the route or how traffic is carried. They don’t prove that your device’s traffic is using that route. Verify traffic handling first, then compare route performance.
You have a complete picture when the target request’s exit IP matches the selected route, the DNS path matches your settings, the app works in practice, and the client log shows the expected proxy rule. With split tunneling, some requests can intentionally connect directly. If you expect all traffic to be routed, also check app coverage and IPv6—don’t rely on the connection icon alone.