To check whether your VPN is working, don’t rely on the connection icon. Start by comparing your public IP before and after connecting, then check DNS requests and verify the apps you actually use. A connected status only means the client tried to establish a tunnel. Whether your browser, desktop apps, and system services use that tunnel also depends on the proxy mode, routing rules, and each app’s network settings.
You don’t need to memorize your public IP for these checks. First, note the network details shown while disconnected. Then connect to the node you want to test and check again on the same device and network. When comparing results, keep in mind whether the test measures browser traffic or traffic from the whole device. Confusing the two is a common reason people see a connected status while traffic still uses the original network.
Check your public IP before and after connecting
Your public IP is the address websites see as the source of your connection. Disconnect the VPN, open a trusted IP lookup site in your browser, and note the public IP and approximate location it shows. You can also use our IP lookup page to check your browser’s current public IP. Then connect to the node you want to use, reload the page, and compare the results. Keep the lookup page URL and the node you tested handy so you don’t end up comparing results from different tools or networks.
- Disconnect the client, close any other proxy or network acceleration tools, and look up and note your browser’s public IP.
- Connect to the node you want to test and confirm the selected client mode. Reload the lookup page instead of relying on content left over from before you connected.
- Check whether the IP itself changed and whether its approximate location matches the selected exit location. Location databases can be out of date, so a city name alone doesn’t prove the VPN failed.
- To check another app, perform an action in that app that lets you observe its network result. Don’t assume the browser’s test results apply to it.
If the address changes, that means this browser request reached the lookup site through a different exit, but it doesn’t prove DNS or other apps use the VPN route too. If the address stays the same, don’t jump to conclusions: split tunneling may send the lookup site directly, a browser extension may override the system proxy, or the page may show cached content. Try another trusted lookup site and force a reload to rule out a display issue with one site.
Check DNS separately: the lookup route and web traffic are not the same
DNS translates domain names into addresses your device can connect to. Web requests going through a selected node doesn’t mean DNS queries take the same route. Use a test tool that shows the DNS servers actually responding to queries. Test before and after connecting with a domain you haven’t visited, then compare the DNS provider with what your client is configured to use. If the tool asks you to clear the cache or generate a new test domain, follow its instructions. Reopening a page that’s already been resolved may not trigger a new DNS request at all.
Before deciding there’s a DNS leak, check what your setup is meant to do. If the client is configured to route all relevant queries through the VPN but you repeatedly see your local network’s DNS resolver, review the DNS settings. With split tunneling enabled, local domains may use local DNS while international domains use another resolver; that may be expected. A DNS server’s country being different from your exit location doesn’t prove a leak either: public DNS servers’ physical locations may not match their displayed locations.
Check your browser’s Secure DNS settings too. Some browsers use encrypted DNS independently of the system resolver, so a test may reflect the browser’s settings rather than the client’s system-wide DNS behavior. Note whether Secure DNS is enabled, then test the browser and another app separately. Don’t change your system DNS just to get a more reassuring test result without understanding the consequences.
Test each app: one browser working doesn’t mean your whole device is covered
Clients commonly work as a browser proxy extension, a system proxy, or a virtual network interface that can handle more device traffic. A browser extension usually affects only that browser. A system proxy depends on apps honoring system settings. With a virtual network interface, routing and split-tunneling rules matter too. Options with names like “Global” and “Rules” can work differently across clients, so check the actual settings and test results.
| What to test | How to check | What the results mean |
|---|---|---|
| Browser | Check your public IP before and after connecting, then run a fresh DNS test | Shows only the route used by that browser’s test request |
| Another browser | Open the same lookup page in that browser separately | If the results differ, check extensions, proxy settings, and Secure DNS |
| Desktop app | Check for app-specific proxy settings and test a feature that uses the network | A changed browser IP doesn’t mean the app is using the VPN |
| Mobile app | On the same network, test the browser and target app separately | Check the app’s built-in connection method and the client’s routing rules |
When testing desktop or mobile apps, choose a feature that lets you observe the request result, such as in-app network diagnostics, a service region indicator, or connection logs. If the app doesn’t show its public IP, don’t treat being able to open content as proof of the route: it may work over a direct connection too. A better approach is to check the client’s connection logs or rule-match details and compare them with when the app made its request. Use those records only to identify where traffic went; don’t share screenshots that reveal account details or browsing addresses.
Common reasons a VPN shows as connected but traffic doesn’t use it
If a test result isn’t what you expected, keep the conditions consistent: use the same network, device, and app, and change only one client setting at a time. That’s the best way to identify what affected the result. Work through the checks below in order and retest after each one. Don’t change the node, routing rules, and browser settings all at once.
- ✅ Check the current mode. Rule-based routing may send an IP lookup site directly. To test the VPN route itself, you can temporarily switch to a suitable test mode if you understand the impact, then restore your original settings.
- ✅ Check which traffic the proxy covers. If only a browser extension is active, other browsers and desktop apps won’t automatically use the same exit.
- ✅ Check app settings. A separately configured proxy, built-in DNS, or an existing network connection may override the system route you expect the app to use.
- ✅ Check IPv6. If your local network provides IPv6 and the selected mode doesn’t handle that traffic, sites that support IPv6 may take another route. Check IPv4 and IPv6 results separately.
- ✅ Check DNS and rule matches. If your public IP changes but DNS still behaves unexpectedly, check DNS settings separately instead of repeatedly switching nodes.
IPv6 is easy to overlook. One lookup page may show only IPv4, while another site may prefer IPv6. If your test tool shows both address types, compare each one before and after connecting. If the results differ, check whether the client supports IPv6 routing in the selected mode and whether the current rules cover the request. Don’t mask an unclear routing issue by simply disabling IPv6 on your device.
Another possibility is that the connection was established but the node isn’t forwarding the request properly. Try an ordinary web page, then check whether the client reports a handshake, authentication, or subscription update error. Don’t assume every loading failure means the VPN route isn’t working: the destination service may be down, the app may have cached data, or DNS may be failing. Comparing IP, DNS, and app-level results is more useful than repeatedly clicking Connect.
Subscriptions and protocol names don’t replace real-world testing
Subscription links usually provide node and configuration details to compatible clients. A successful import only means the client received a configuration it could read. You still need to test whether the node connects and the routing rules work as expected. If results change after a subscription update, check which node and mode are actually selected instead of just looking for new entries in the subscription list. Client settings can vary by platform, and options with the same name don’t necessarily cover the same traffic.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are names of different connection protocols or approaches, not proof that a connection has passed a test. Protocols affect how a client connects to a node; public IP, DNS, and app routing tests show where traffic actually goes. IEPL, relay, and direct connections describe how routes are set up, but they don’t replace testing on your device. Even if a node is available, traffic may still use your local route if the app isn’t covered by the proxy rules.
If you need to describe an issue to support, include the client platform, mode, app you’re trying to access, and differences in public IP and DNS before and after connecting. Subscription links may contain access credentials, so don’t post the full link in a public forum. Hide unrelated account details in screenshots too.
How to interpret your test results
Limit your conclusion to what you actually tested. If the browser’s public IP matches the selected node, DNS behaves as expected for your mode, and you can confirm the target app’s traffic through a rule match or observable network result, you can say those tested requests behaved as expected. A client showing “Connected” or a changed browser IP alone isn’t enough to conclude that all traffic on the device uses the same route.
Test results can become outdated when your network or client settings change. When you switch networks or nodes, or update your subscription, repeat the checks in the same order. Your results apply to that device and app at that time; they aren’t a guarantee for future connections.