How to Check If Your VPN Is Working: IP and DNS Leak Tests
Check your exit IP, test for DNS leaks, and verify each app. Learn why a VPN may show as connected without routing traffic through the proxy—and how to troubleshoot it.
Is Your VPN Working? Check the Connection and Traffic Route Separately
You can't tell whether a VPN is working just by looking at the connection icon. An exit IP check shows where a request leaves the network; a DNS leak test shows how domain names are resolved. You also need to test the apps you use. Taken together, these checks help distinguish expected split tunneling from a configuration issue.
When a client shows as connected, it usually means the tunnel or proxy service has started—not that all traffic is using it. A system proxy may affect only apps that follow system settings. TUN mode routes matching traffic through a virtual network interface, but routing rules, exclusions, and platform permissions still apply. Neither mode's name alone tells you which traffic it covers.
Before testing, decide what you expect: should only selected international websites use the proxy, or should all external traffic from the device go through the tunnel? With rule-based routing, keeping local services on a direct connection may be intentional. Treating every direct connection as a leak can lead you to break routing that is working as designed.
Compare Your Exit IP Before and After Connecting
Start by recording a baseline in an environment where it's safe to disconnect the proxy. If you can't risk a direct connection for your current task, don't disconnect just to test; check the client logs first and record a baseline later when it's safe. Note the full IP address, network operator, and address type—not just the country or region shown on the page.
- With the proxy disconnected, open the IP lookup page and note your browser's current public exit IP. If the page shows separate IPv4 and IPv6 results, record both.
- Connect to the route you plan to use. Make sure your subscription is active, the node is selected, and the system proxy or required TUN mode is enabled.
- Reload the lookup page instead of relying on a previously opened tab or cached result. Compare the full addresses before and after connecting, not just the region names.
- Check the client connection log to see which rule matched the lookup domain and which exit it used. If the lookup page is set to go direct, it won't show the proxy exit.
- Cross-check with a separate lookup service, then test the target app. Don't assume the entire route is down just because one site won't load.
IP geolocation databases can be outdated, and their results may not match a route's name. The same region doesn't mean the same exit, and a change in region doesn't prove that all traffic uses the proxy. Better evidence is a changed IP address together with a client log showing that the request used the expected route.
DNS Leak Testing: Check the Resolution Path, Not Just the Location
DNS translates domain names into addresses that devices can connect to. Routing app traffic through a proxy doesn't necessarily route DNS queries through it too. Queries might be sent by the operating system, handled by the browser's Secure DNS, resolved by the client, or processed by the proxy server. Whether this is a leak depends on the resolution path you intended to hide or control.
You can use an independent testing site such as DNSLeakTest. Run its test and note the resolver operators shown, then compare them with your operating system, browser, and client DNS settings. The test site receives test requests, so review its privacy information before using it.
These tests typically have your browser request specially generated domain names, then check which recursive resolvers looked them up. The results mainly show resolvers used for those test domains—not a complete list of DNS activity from every app on your device. Not seeing a local resolver doesn't prove that background apps use the same resolution path.
If you expect all external DNS queries to use the tunnel but repeatedly see resolvers from your local access network, investigate further. A public resolver isn't automatically safe or unsafe based on its country or brand. A browser connecting directly to a public resolver over encrypted DNS may show similar results to using the same resolver through a tunnel, even though the network paths differ.
- Check whether the client has DNS interception, remote resolution, or related DNS routing rules enabled. Names and options vary by client, so consult its documentation.
- Check whether your browser's Secure DNS uses a separate service. If you need a consistent route, coordinate its settings with the client rather than blindly layering configurations.
- After changing settings, clear the relevant DNS cache or restart affected apps, then test again to avoid relying on previous lookup results.
- With Fake-IP enabled, an app may first receive a mapped address that the client then handles. That address is not necessarily the public exit IP.
Common Test Results and What to Check Next
Review the exit IP, resolver, and connection logs from the same test session. Change one setting at a time and save the results before each change so you can identify what made a difference. The table below suggests troubleshooting steps; it isn't a definitive diagnosis based on one test.
| Test result | Possible cause | Next step |
|---|---|---|
| Exit IP hasn't changed | The lookup site is going direct, the system proxy isn't active, or the browser has a separate proxy setting | Check which rule matched the domain and review the browser and system settings |
| Browser exit IP changes, but the target app's doesn't | The app ignores the system proxy or is explicitly excluded | Check the app's proxy settings, process rules, and TUN coverage |
| Exit IP changes, but a local network resolver appears | DNS isn't being routed through the client, or a separate resolution path is in use | Compare the system DNS, browser Secure DNS, and client logs |
| IPv4 uses the proxy, but IPv6 still uses the original network exit | IPv6 routing or interception isn't covered | Check the client's IPv6 support and exclusion rules, then test IPv4 and IPv6 separately |
| Exit IP looks right, but a service reports a location issue | Account region, cached session, IP classification, or server-side restrictions | Check the target service's rules and your account status instead of repeatedly switching routes |
A successful latency test only means that a particular probe got a response. It doesn't prove that web pages, login endpoints, images, and real-time connections all use the same route. Likewise, loading a homepage doesn't mean every domain used by the app matches the right rule. Check the logs for the specific action that failed.
Verify Routing by App: Browser, Desktop, and Mobile
Windows and macOS: Check Which Apps Use the Proxy
First, make sure the system proxy settings match the client, then check whether browser extensions override them. Desktop apps may use the system proxy or a separate network stack. For an app that must use the proxy, try a real task—such as signing in, loading content, or sending a request—and check the client logs at the same time.
Developer tools and terminal commands need particular attention. Some programs read HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY; others need to be configured separately. Don't assume environment variables cover every command. If you need a local proxy port, copy it from the client's current settings rather than using a port from another guide.
iOS and Android: Check What the Client Routes
Check that the operating system allows the client to establish a VPN connection and that no other VPN configuration is routing traffic. Android clients may offer per-app include or exclude rules; make sure the target app is in the right group. The VPN status indicator on iOS isn't a substitute for checking the exit IP and testing apps. The route depends on the client configuration.
Linux: Separate Desktop Settings from Process Environments
Proxy settings in the desktop environment aren't necessarily inherited by background services, containers, or terminal tools. Check the configuration and environment variables the process actually uses. With TUN mode, also verify routing and permissions. Containers may have their own network environment, so results from a browser on the host don't necessarily apply to requests from inside a container.
Protocol names such as Shadowsocks, VMess, Trojan, and VLESS don't tell you how a client routes traffic through the operating system. A protocol determines part of how a connection works; system proxy settings, TUN mode, and routing rules determine which requests use it. Don't confuse changing protocols with expanding the traffic coverage.
IPv6, WebRTC, and What Happens When the Connection Drops
Even if an IPv4 test looks fine, check IPv6 too. If your device and network support IPv6 but the client doesn't handle it as expected, some connections may take a different route. First check the client's IPv6 support and routing policy. Only consider temporarily changing system settings once you understand the impact, and test again afterward.
WebRTC supports real-time browser communication, and test pages may show host, server-reflexive, or relay candidate addresses. A private address or a masked host candidate isn't necessarily a leak of your real public exit IP. If the page shows a public address that differs from the expected exit, investigate the browser's policies, UDP routing, and client logs.
To check whether protection works when the connection drops, use a test environment with no sensitive activity and see whether requests that should use the proxy fail or switch to a direct connection when the tunnel is interrupted. A toggle in the settings isn't proof that protection is working. Don't disrupt a live work session just to test this.
IEPL, transit, and direct connections describe how a route is organized; they don't configure DNS interception or app routing on your device. Switching route types may change network performance, but it won't automatically fix a browser's separate proxy, an app exclusion, or an uncovered IPv6 route.
Retest Checklist and Results Log
After making changes, repeat the test in the app and with the action that originally failed. Save the connection mode, route name, matched rule, IP lookup result, and test time. For help, visit the Help Center to find support options, or check the client settings against the Setup Guide.
- ✅ The lookup request matched the expected rule, and the exit address matches the intended route.
- ✅ DNS test results are consistent with the DNS settings in the operating system, browser, and client.
- ✅ The target app completed a real task—not just showed a successful connection in the client.
- ✅ On networks where applicable, IPv4, IPv6, and real-time communication routes were checked separately.
- ✅ After changing settings, you re-established the relevant connections instead of judging the new configuration by an old session.
- ✅ Before sharing screenshots or logs, you hid subscription links, credentials, tokens, and unnecessary personal information.
Subscription links may contain access credentials. Don't paste them into public test sites or discussion forums. Troubleshooting usually requires only redacted rule matches, error messages, and exit results—not your full configuration. If you're unsure which log fields are sensitive, ask support what minimum information they need.