How can you tell whether your VPN is working? Start by comparing your public IP and checking DNS, then test the apps you actually use. A client’s “Connected” status usually means the connection is up or a local proxy has started; it doesn’t prove that your browser, chat apps, and other programs are all using the intended route.
This guide doesn’t present made-up test results. Run checks on your own device and compare what you see before and after connecting, alongside the client’s rules and connection logs. Your public IP, DNS path, and app routing are separate questions; one green icon cannot answer them all.
Connection status vs. your actual IP route
Clients may use a system VPN tunnel, or simply start a local proxy and change your system proxy settings. A tunnel routes traffic that matches its routing rules through a system network interface. A local proxy depends on whether each app honors the proxy settings. Both can show “Connected,” even though they cover different traffic.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are proxy protocols or protocol families—not client operating modes. Their names alone don’t tell you whether all traffic is covered. VLESS does not provide encryption by itself; actual protection depends on the transport configuration. For other protocols, check the client and server settings in use.
| Check | What it tells you | What it can’t prove on its own |
|---|---|---|
| Client shows connected | The connection or proxy status reported by the client | That every app is using the tunnel |
| IP shown by a webpage | The address used for that particular web request | The route used by other apps, DNS, and all address families |
| DNS test results | Which servers took part in resolving the test domain | The full path taken by DNS queries or whether they were encrypted |
| Client connection logs | Which rules matched, which route was selected, and which requests were handled | All system traffic not handled by the client |
Public IP: compare before and after connecting
Choose a test page that displays your public IP. Search for “public IP check” to find one, but don’t install an unfamiliar extension just to run a test or enter account credentials. Test pages can see your IP address, so review the tool’s privacy policy before using it.
- Record your direct-connection baseline. Disconnect the client, open the test page in the same browser, and note your public IP, network provider, and the location shown. Don’t share your full IP address publicly.
- Connect to the route you want to test. Check the selected route and operating mode in the client. For a clear comparison, you can temporarily choose a mode that sends the test request through the proxy, then restore your usual rules afterward.
- Run a fresh test. Test the page again rather than relying on an old screenshot or cached result. Compare the IP addresses and check whether the client logs the corresponding request.
- Read the results. A changed IP plus a request matching the expected route is a useful sign. If the IP hasn’t changed, first check whether your rules send the test domain directly, then investigate the connection.
IP geolocation comes from databases that may be out of date or reflect only the address’s registered location. If the client names one location and a test site shows another, that alone doesn’t mean the route is broken. Cross-check the network provider, route details, and request logs; contact support if needed.
Likewise, opening a website doesn’t prove the VPN is working: the site may already be reachable directly, or much of the page may come from cache. Conversely, the expected IP with a site that won’t load could point to the site’s security checks, account restrictions, or a blocked exit—not a completely broken client.
DNS test: check how names are resolved
DNS translates domain names into network addresses. A DNS leak usually means DNS queries bypass the intended tunnel or resolution policy, allowing an unintended resolver to see them. DNS and your web traffic are separate checks: a webpage can go through a proxy while DNS uses different settings.
Run a DNS test while disconnected and note the resolvers it identifies. Then connect to the route you want to check and run the test again. These tests usually identify resolvers by querying newly generated domains, so you need to start a fresh test; refreshing the results page may not trigger a new query.
- ✅ Check whether the client handles DNS and whether its rules allow some domains to use your local resolver.
- ✅ Review your browser’s “Secure DNS” settings to see whether it uses your system configuration or a specified encrypted DNS service.
- ✅ Compare the connection logs with the resolver’s network provider to see whether the results match your chosen policy.
- ❌ Don’t assume there’s a leak just because the resolver and exit IP appear to be in different locations.
Your browser may use DNS over HTTPS instead of the resolver configured by your system, while the connection to that DNS service may still go through the proxy. Public resolvers may also use distributed networks, so the location shown in a test need not match your exit IP. Seeing a public DNS resolver doesn’t automatically mean there’s a leak, and not seeing your local provider’s name doesn’t prove your privacy is fully protected.
Don’t change your DNS settings to an unfamiliar address at random. Read the client’s guidance on DNS, remote DNS, and split tunneling first. Then change one setting at a time and keep a record of the results before and after.
If a test shows a local resolver but you want all DNS queries to use the tunnel, check the client’s DNS handling, browser overrides, and system settings. Close the old test page and run a fresh test after making changes. If the results are still unclear, share redacted results and client settings with support.
Test apps individually: your browser isn’t the whole picture
Not every app follows your system proxy settings. Some make connections on their own, some support only certain proxy types, and others need to be fully closed before they pick up new settings. Once your browser passes the test, check the apps you actually use instead of repeatedly testing the same webpage.
On Windows, macOS, or Linux, first check whether the client is using a system proxy, TUN mode, or another tunnel mode. TUN can cover more traffic, but routing rules, permissions, and exclusions still matter. An option labeled “Global” may mean only that all handled requests use the proxy—not that every program is covered.
On iOS and Android, check the system VPN status and the client’s app exclusion settings. Android clients may offer per-app proxy settings; coverage on iOS depends on the client and system configuration. A status-bar icon is only a clue—make a fresh request in the app you want to test.
- Open the app you want to test and perform a recognizable online action, such as refreshing content or loading a new page.
- Check the client logs for the corresponding domain or connection and see whether it matched a direct or proxy rule.
- If the request isn’t in the logs, check app exclusions, proxy support, and client permissions. Missing entries may also mean logging is disabled.
- After changing settings, restart the app and test again. Don’t change the route, rules, and DNS at the same time, or you won’t know which change made a difference.
Command-line tools may behave differently from browsers. Terminal apps don’t necessarily read your desktop’s system proxy settings, and not every tool supports proxy environment variables. To test a command-line app, check its documentation for proxy options rather than assuming the browser’s results apply.
IPv6 and WebRTC: check for traffic outside the tunnel
A device may have both IPv4 and IPv6 connectivity. If the tunnel covers only one address family, an app may connect over the other route. Use a tool that displays both public address types and check before and after connecting. Seeing only one address doesn’t tell you whether the other type of traffic is covered.
If IPv6 after connecting matches your direct-connection baseline, but the client is meant to cover all public traffic, check its IPv6 routing and support. Follow the client’s official guidance; disabling IPv6 at the system level isn’t a universal fix. If no IPv6 address appears, your network or the test tool may simply not support IPv6.
WebRTC supports real-time browser communication, and its network route may differ from ordinary webpage requests. A test showing a local network address or a masked local identifier doesn’t mean your public IP has leaked. If it shows a direct public IP, check your browser, the client’s UDP handling, and routing rules.
Web-based tools can check only the requests they trigger. They can reveal useful clues, but they can’t prove there are no other routes on your device or confirm tunnel encryption based on an IP address alone. To verify encryption, check the protocol and transport settings in use. For deeper diagnosis, someone experienced can inspect system routes or analyze packet captures.
Common issues: diagnose by symptom
When troubleshooting, distinguish between “not using the expected route” and “using the route but unable to access the site.” Direct, relayed, and IEPL routes describe how traffic is carried or organized; they don’t automatically determine whether DNS, browser routing, or app rules are configured correctly on your device. Changing routes won’t fix every local traffic-handling issue.
| Symptom | Check first | Next step |
|---|---|---|
| Connected, but webpage IP is unchanged | Whether the test domain is set to go direct; browser proxy settings | Review the rules and run a fresh test |
| Works in browser, not in other apps | App exclusions, system proxy support, tunnel mode | Check app request logs and adjust traffic handling if needed |
| IP changes, but DNS results don’t match expectations | Client DNS policy, browser Secure DNS settings | Set your DNS resolution goal, then adjust one setting at a time |
| Expected IP, but target website denies access | Website error, account region, and exit IP restrictions | Distinguish website policy from route issues |
| Results change after switching networks | Reconnected session, system routing, and new network settings | Reconnect, then retest your IP and DNS |
If the client has no selectable routes or configuration updates fail, check your subscription status and client compatibility in the user panel. A subscription link retrieves route configuration; it isn’t proof that a connection is working. Select a route after updating, then run the checks above. Don’t share your full subscription link with a testing site.
Interpreting results and retesting
A useful conclusion is specific: the target browser uses the expected route, DNS results match your chosen policy, requests from your usual apps match the intended rules, and applicable address families have been checked. This is more useful than saying “everything is fine”—if something goes wrong later, you’ll know what changed.
Repeat the comparison after changing clients, updating your system, changing split-tunneling rules, or switching networks. Redact screenshots and logs first: hide full public IP addresses, usernames, subscription links, sensitive domains, and authentication details. When asking for help, start with your operating system, client name, operating mode, and a description of the issue.