Verify the VPN: a connected status isn’t proof
How can you tell if your VPN is working? Check your public IP first, then DNS, and finally test each app. An app is using the VPN only when its new requests follow the expected route. The connection icon merely shows that one part of the connection has been established.
A proxy client may have started a local listener or completed a handshake with a remote server without routing traffic from apps other than your browser. In rule-based mode, some sites may intentionally connect directly. So “every result must change” is not the right test. First define what you expect: which app is accessing which domain, and whether it should connect directly or through the VPN.
How to check your public IP before and after connecting
Use the same trusted public IP lookup tool for both checks. Before connecting, note the address, IP version, and network or ISP. Check again after connecting. Don’t mistake your device’s private LAN address for its public IP, and don’t judge the result by the city shown on a map alone.
- Establish a baseline. Disconnect the VPN, make sure no other proxy extension is handling browser traffic, then check your public IP. Note which network you’re using, and don’t switch networks during the test.
- Connect to the intended server. Check the client’s current mode and which rule should apply to the lookup site. If the rule is set to connect directly, an unchanged public IP isn’t a problem.
- Send a fresh request. Reopen the lookup page and refresh the result while checking the client’s connection list. If needed, restart the browser to rule out reuse of an existing connection.
- Cross-check the result. Use another independent lookup tool and compare the IP and network details. Geolocation databases may not update at the same time, so a mismatch in city labels alone doesn’t indicate a problem with the server location.
If your network supports both IPv4 and IPv6, check where each one goes. If only one IP version is routed through the VPN, a site may prefer the other. One lookup page can show a changed public IP while another app still connects directly; that isn’t necessarily a contradiction.
DNS checks: follow the lookup path, not just the location
DNS translates domain names into addresses that apps can connect to. Routing website requests through a proxy doesn’t guarantee that DNS queries use the same route. A DNS leak generally means queries that should follow the tunnel or proxy policy are instead sent through an unexpected local network or resolver.
DNS test tools typically generate test domains, then infer the lookup path from the recursive resolvers that receive the queries. The results describe those resolvers; they don’t necessarily identify the server your device connected to directly, and they aren’t another way of showing your public IP.
- Record the results before connecting. Note the resolver names and network details so you can compare them afterward.
- Check the client settings. Look for DNS interception, remote DNS resolution, or rules that select a resolver. The setting names vary between clients.
- Check secure DNS in your browser. A browser may use its own encrypted DNS service instead of the system resolver. If its results differ from the client’s, investigate the connection path further.
- Test a new domain lookup. Cached results may prevent a fresh DNS query. Clear the cache as described in your system or client documentation, then test again.
A resolver in a different region from your VPN server doesn’t mean there’s a leak. Public DNS services may use anycast, and test databases may show only the provider’s registered location. Likewise, a resolver appearing to be in the intended region doesn’t prove that all app traffic uses the VPN. What matters is whether the resolver matches your configuration and how DNS queries are sent.
Test each app: one working browser doesn’t prove everything works
System proxy settings are a set of proxy details that apps can choose to use. Whether they do depends on each app. Browsers, command-line tools, chat apps, and games may use different network paths. A browser extension may handle traffic only in that browser.
Virtual network adapter mode is commonly called TUN. It uses system routes to capture eligible traffic and pass it to the client, typically covering more traffic. However, excluded routes, permissions, process rules, and IP version settings can still affect what gets routed. Turning on TUN doesn’t replace testing the actual traffic.
| Capture method | Common limitations | What to check |
|---|---|---|
| Browser proxy extension | Usually affects requests in that browser only | Check the extension rules and test desktop apps separately |
| System proxy | Apps may ignore system settings or use a separate proxy | Check app settings and the client’s new connection logs |
| Virtual network adapter mode | Excluded routes and process-based bypass rules may still apply | Check permissions, routes, DNS interception, and IP versions |
| In-app proxy | Usually affects only the features in that app that support proxies | Test sign-in, content loading, and real-time connections separately |
Generate a recognizable new request from the app
Open the client’s connection list, then launch the app you’re testing and trigger an action such as refreshing content, loading a new page, or reconnecting. Look for the corresponding entry by time, domain, or process, then check the matched rule, routing policy, and any error details. Not all platforms show which process owns a connection. If the process name isn’t available, use the request time and destination domain to find the match.
If there’s no matching entry, first rule out reuse of an existing connection, cached results, or filtered logs. Don’t assume traffic is leaking. If the logs clearly show a direct connection, check for a direct-connect rule, an app exclusion, or a separate proxy setting. An increase in traffic counters alone doesn’t prove that the app you’re testing generated the traffic.
Handling differences between platforms
On Windows and macOS, check system proxy and virtual network adapter modes separately. Linux desktop proxy settings may not be passed to command-line programs. Android clients may have app include or exclude lists. On iOS, check the active client configuration and system VPN status rather than following desktop instructions. Refer to the client documentation and current interface for exact settings.
Why traffic may not use the VPN even when it looks connected
The subscription is imported, but the active configuration hasn’t changed
A subscription link is used to get servers and related configuration; it doesn’t route traffic by itself. After updating a subscription, check which configuration is active, which server is selected, and which proxy mode is in use. Some clients save the new configuration but keep running the previous one.
The rules don’t match what you expect
Rules may route traffic based on domains, destination addresses, or processes, usually according to the client’s matching order. An app may use different domains for sign-in and content loading. If you can sign in but content won’t load, check the failed requests individually. Adding only the app’s homepage domain doesn’t necessarily cover all its features.
Existing connections, other proxies, or permissions get in the way
Switching servers won’t necessarily move existing long-lived connections right away. Reconnect the app you’re testing, then check its new connections. Other VPNs, proxy extensions, or corporate network clients may also cause conflicting settings, competing routes, or access restrictions. Troubleshoot settings one at a time only in environments where you’re authorized to make changes. Don’t disable security settings required by your organization.
Don’t confuse server types with traffic routing
IEPL, relay, and direct connections describe the route or setup of a network connection; they don’t determine whether an app on your device uses the proxy. Protocols such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC don’t replace checks of your rules and routes. Switching to a different server may change how the connection behaves, but it won’t automatically fix an app bypassing the proxy.
Privacy limits: passing these checks doesn’t guarantee anonymity
An IP check shows the address presented to a site by a particular request, while a DNS check helps you inspect the lookup path. Neither is a complete privacy audit. Signed-in accounts, cookies, device characteristics, and information an app submits can still be used to link activity. Anonymity and no-logs claims describe a service’s privacy policy; a single IP lookup can’t prove them.
Interpret WebRTC test results in context, too. A page may show local interface details, a privacy-masked hostname, or a public candidate address—these don’t all mean the same thing. Not every address shown is a leaked public IP. If an unexpected public address appears, check your browser policy and whether the client handles UDP traffic.
When sharing troubleshooting details, include only the mode, rule name, error time, and necessary destination domains. Before sharing screenshots, hide subscription links, access tokens, account details, and unrelated browsing records. Subscription links may contain authentication information, so don’t paste them into public test pages or discussion forums.
Checklist and how to interpret the results
- ✅ Recorded the public IP before connecting and compared it afterward on the same network.
- ✅ Checked which rule applies to the lookup site instead of assuming it must use the proxy.
- ✅ Checked the IP versions available and reviewed DNS and browser secure DNS settings.
- ✅ Sent a new request from the target app and checked its route in the client.
- ✅ Distinguished existing connections, cached results, app-specific settings, and actual direct connections.
- ✅ Saved the necessary troubleshooting details without sharing subscription credentials.
If you still can’t identify the issue, check the import and traffic capture settings in the Guides, then send redacted connection logs through the Support page. If the route matches your expectations but the destination platform still denies access, check its regional policies, account eligibility, and how it evaluates your current public IP. Not every access issue means the VPN isn’t working.