A connection icon alone can’t tell you whether your VPN is working as expected. Check your IP, DNS, and individual apps to find out where traffic exits, which resolver handles domain lookups, and whether each app follows the intended route. Compare results before and after connecting, then check them against your routing rules.
Define what you’re testing: connected doesn’t mean all traffic is covered
“Connected” usually means the tunnel or proxy connection is established. It doesn’t mean every request on your device passes through it. A browser extension may affect only browser traffic; system proxies generally rely on apps to use them; and a TUN interface or system VPN can route more traffic, but may still be affected by routing, app exclusions, and protocol support.
“Global” in a proxy client also depends on context. It may send all requests that have reached the proxy core through the selected node, rather than automatically routing every app through the proxy. Rule-based mode selects a proxy, direct connection, or block action based on criteria such as domain, destination address, or process. So a local exit for a mainland China website isn’t necessarily a problem.
Check your public IP: compare before and after connecting
Your public IP is the address a destination website sees as the source of your request. Open our IP lookup page and record your public address, IP type, and ISP while disconnected. Recheck after connecting. Keep the same network throughout the test; switching between Wi-Fi and another network can change your exit address independently of the proxy.
- Turn off other proxy extensions and any duplicate client sessions. Record the results while disconnected.
- Connect to the node you want to test, make sure the client mode matches your use case, then refresh the lookup page.
- Check the client’s connection log to confirm the request matched a proxy rule and used the expected outbound route.
- Disconnect and run the lookup again to see if the result returns to your original network. If needed, close and reopen the page.
A changed IP shows that this request used a different network path; it doesn’t prove that other apps are routed through the proxy too. If the address hasn’t changed, don’t assume the node has failed. The lookup site may be set to connect directly, your browser may bypass the system proxy, or the test may be checking a different IP type.
IP geolocation databases don’t always agree. A city shown on a lookup page that differs from the node name isn’t, on its own, evidence of a problem. Compare the public IP, ISP, client outbound logs, and whether the target service works as expected.
| Result | What it tells you | What else to check |
|---|---|---|
| The lookup shows a different exit IP | This page’s request used a different exit route | Check whether the target app and DNS follow the same rules |
| The lookup shows the same exit IP | This request didn’t use the expected exit route | Direct-connection rules, proxy entry point, cache, and IP type |
| DNS shows a different region | The DNS resolver and website exit may be in different locations | Check whether the resolver matches your expected configuration |
| The browser works, but other apps don’t | Apps may be using different proxy routes | App-specific proxy settings, exclusions, and routing |
Check DNS: distinguish resolver location from leaks
DNS translates domain names into addresses that devices can connect to. Routing web traffic through a proxy doesn’t mean DNS lookups use it too. If DNS is meant to stay inside the tunnel but requests go to your local network’s resolver, check for unintended DNS exposure. Conversely, if your rules explicitly send local domains to a local resolver, that result isn’t automatically a leak.
Use a DNS test page that triggers lookups for new domains, then compare the resolver list before and after connecting. Focus on whether the providers match your client settings, rather than expecting them to be in the same country as the proxy node. Distributed public DNS, upstream forwarding, and how the test site identifies resolvers can all affect the results.
Check browser secure DNS separately from system DNS
A browser’s secure DNS feature may use DoH to make lookups independently of the system resolver settings. Those requests may then use a proxy or connect directly. When troubleshooting, note the browser settings first, then check whether the client routes those requests. Encrypted DNS doesn’t automatically mean DNS traffic is inside the tunnel.
The commands below can help show which servers and results your system’s resolver tools return, but they can’t prove the browser’s DNS route on their own. Depending on the operating system, a tool may show a local forwarding address or contact a specified resolver directly.
nslookup example.comIf you recently changed settings, cached DNS results may mean the test doesn’t trigger a fresh lookup. Start with the test page’s option to run a new query, then restart the app and test again. Clearing the cache can remove stale results, but it doesn’t replace checking the DNS route.
Test each app: a browser result doesn’t cover all your software
Fully quit the app you want to test, connect the proxy, then reopen it. Existing long-lived connections may keep using the old route, and background processes may retain their connections. Next, check the client’s connection panel for the app’s domain, matched rule, outbound node, and traffic changes. A rise in total traffic alone doesn’t prove the app is routed through the proxy.
- ✅ Browser: Check for overlapping extension and system proxy settings, then review the outbound route for a lookup request.
- ✅ Desktop apps: Check whether the app has its own proxy settings, then make sure the client isn’t excluding it.
- ✅ Command-line tools: Check proxy environment variables and the tool’s own settings. Don’t assume terminal results apply to your browser.
- ✅ Games, meetings, and real-time communications: Check sign-in, content loading, and media connections separately. Confirm that the current mode supports UDP and other relevant traffic.
- ✅ Mobile apps: Check the system VPN status, app routing rules, and background restrictions. Retest after switching networks.
System proxies and virtual network interfaces route traffic differently on Windows and macOS. On Linux, terminals, desktop environments, and apps may each use their own proxy settings. The VPN interfaces on iOS and Android don’t replace checks for app routing and client capabilities. When results differ, troubleshoot using the options available in your operating system and client.
If a website opens, that only shows it’s reachable right now; it may have been accessible directly. Likewise, a site refusing access could be due to your account’s region, the site’s risk controls, service availability, or app cache. That alone doesn’t mean the proxy has completely failed.
Common causes of different results: IPv6, WebRTC, and routing rules
Different IP types may use different routes
Your device may have both IPv4 and IPv6 connectivity. If the proxy covers only one, the other may still use your regular network connection. Use a tool that tests each IP type separately, then check the client’s IPv6 support and routing settings. If a test doesn’t detect an IP type, your current network may simply not provide that connection; it doesn’t prove that traffic can never leave directly in other environments.
Interpret WebRTC results by address type
Browser real-time communications may probe network paths using candidate addresses. A local network address or a masked local hostname in test results isn’t the same as your network’s public IP. If you see an unexpected public address, check UDP routing and browser settings further; an extra address alone doesn’t mean all traffic is exposed.
Rules, subscriptions, and connection status are separate layers
Importing a subscription gives the client the nodes or configuration provided by the service; it doesn’t enable the system proxy by itself. After updating a subscription, check that the selected node, mode, and rules match your expectations. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are protocol names; they don’t tell you whether an app’s traffic is being routed through the proxy.
Troubleshoot with evidence to avoid changing settings over and over
Keep your original settings and change one relevant option at a time. For example, first make sure the app is routed through the proxy, then check DNS. If you change nodes, rules, and resolvers all at once, it’s hard to tell what fixed the issue. When testing is done, restore the configuration that suits your everyday use.
When contacting support, include your operating system, client version, connection mode, affected app and domain, and redacted details of the matched rule and IP change. “The browser’s exit IP changed, but the app still connects directly” is more useful than “The VPN doesn’t work.”
How to assess the result: The evidence should line up: the exit IP matches expectations, the DNS route matches your configuration, and the target app uses the correct outbound route. Together, these confirm that the tested use case is working. A single test doesn’t replace checking your configuration over time. Retest after changing networks, updating the client, or editing rules.
VPN97 provides client setup guides and route information to help you check your configuration. The no-logs policy describes the service’s privacy practices; it doesn’t guarantee that your device will never connect directly by mistake. Check local routing, DNS, and app settings separately.