Is your VPN really working? Check your public IP and DNS instead of relying on the client’s connection icon. First note the results before connecting, then compare your public IP, DNS lookups, and the behavior of the app you want to use. What matters is whether a specific request from a specific app takes the expected route.

What people call a VPN client may actually use proxy protocols and routing rules rather than routing all traffic from the device. The checks below apply to both system-wide connections and subscription clients, but you’ll need to account for the mode they’re actually using.

The connection icon vs. your actual public IP

“Connected” may mean that a system tunnel is established or a local proxy service has started. It doesn’t necessarily mean the remote server is reachable. Some clients stay active even when a server is unavailable, while other apps ignore system proxy settings altogether. Check the client status, your browser’s public IP, and each app’s behavior separately.

What different test results prove
Check What it tells you What it doesn’t prove on its own
Client says connected The client or system connection is active That the remote server is reachable or all apps are routed through it
Your browser’s public IP changed That this page request used a different public IP That other apps, address families, and DNS use the same route
DNS test results changed That a different set of resolvers handled the test domain That all network traffic is going through the proxy
The app you want to use works That the app’s current feature is available That all its login, media, and download requests use the proxy
The client log shows a matching rule That the client recognized the request and its selected route That the server accepted the request or the content will definitely play

Be clear about what you expect, too. In rule-based mode, sending local sites directly and international sites through the proxy may be exactly the right setup. If you want all traffic from a particular app to use the proxy, check every relevant rule for that app—not just one test page.

Check your public IP: note the baseline, then compare

Your public IP is the address a website sees when it receives your request, not your device’s address on the local network. Search for “what is my public IP” in your browser and choose a test page that can check both IPv4 and IPv6. The test service also receives your request, so review its privacy policy. Don’t upload subscription links or client configurations to a testing site.

  1. Disconnect the proxy and note your baseline. Keep your network unchanged, open the test page, and record your public IP, address family, and network provider. If your network already uses an upstream proxy, note that as part of the comparison.
  2. Connect the client and check its routing mode. Check the selected server, system proxy or tunnel settings, and whether rule-based mode matches your expectations. Selecting a server doesn’t mean system-wide routing is enabled.
  3. Load the test page again. Refresh it or reopen your browser if needed. A private window can reduce interference from some site caches and sign-in sessions, but it can’t replace checking your proxy settings.
  4. Compare the addresses and check the rules. If your public IP changed, that request took a different route. If it didn’t, first check whether the test domain matches a direct-connection rule, then investigate whether the connection has a problem.
  5. Check each available address family separately. Routing IPv4 through the proxy doesn’t mean IPv6 is routed too. If IPv6 is available, compare its result with the one you recorded before connecting.

The country or city shown by a test page comes from an IP geolocation database. It may be out of date or differ from the server label, so don’t judge a connection by the city name alone. More useful evidence includes whether your public IP changed, whether the network provider looks as expected, and whether the client logged the relevant proxy connection.

DNS tests: where a domain is resolved isn’t the same as where your web traffic exits

DNS translates domain names into IP addresses. A web connection can use a proxy while domain lookups are still handled by your local network. Or your browser’s secure DNS can resolve domains independently before sending web requests through the proxy. These paths are related, but they’re not the same thing.

Common DNS test pages ask your browser to look up a temporary domain, then show which recursive resolvers handled the lookup. Run the test once while disconnected and again after connecting, and compare the resolvers. The page usually shows the resolvers’ public IPs—not necessarily the DNS addresses configured directly on your device, and not necessarily a location shared with your proxy server.

A DNS leak is defined by the expected routing policy. If relevant domains are supposed to be resolved through the proxy but queries still go to your local network’s resolver, investigate further. If the rules explicitly allow certain domains to be resolved locally, that alone isn’t a problem. Seeing a familiar public DNS provider doesn’t tell you whether queries are encrypted or routed through the proxy.

If DNS results look unexpected, check these settings

  • Browser secure DNS: Your browser may use its own encrypted resolver, independently of system DNS. Note the setting and compare results under controlled conditions. Don’t leave a security feature disabled just to hide a problem.
  • Client DNS mode: Check whether the client uses proxy-side DNS, DNS interception, or Fake IP. Fake IP is an internal mapping mechanism; seeing a virtual address doesn’t by itself mean the connection has failed.
  • System and network settings: Corporate network policies, other networking tools, and manually configured resolvers can all change where queries go.
  • Cache: Previously resolved results may be reused temporarily. A test that generates a fresh domain is more useful than repeatedly refreshing the same ordinary webpage.

The nslookup command can help check traditional DNS lookups, but it may not reflect your browser’s secure DNS or show whether an app resolves domains through the proxy. A difference between command-line and browser results doesn’t by itself mean the client has failed.

Routing rules and coverage across platforms

A system proxy usually affects only apps that follow that setting. Your browser may use the proxy while your terminal, game, or download app connects directly. TUN mode routes traffic through a virtual network interface and usually covers more apps, but its reach still depends on routing, exclusion rules, address families, and system permissions. You still need to test it.

On Windows and macOS, first check whether the client uses a system proxy or a network tunnel. Then look for browser extensions, built-in proxy settings, or other networking tools that may override it. Terminal programs may use environment variables such as HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, or require separate configuration.

On Android, check whether the app is excluded from proxy routing and whether the client has system connection permission. On iOS, confirm that the expected network configuration is active and review the client’s rules. A system connection indicator doesn’t prove that every domain is routed through the proxy.

Linux desktop environments, terminals, and background services may each use different proxy settings. Enabling a proxy in the desktop settings doesn’t mean service processes will inherit it. Test in the program that’s actually having the problem rather than relying on a browser as a stand-in.

The protocol name alone can’t tell you whether the connection is working as expected. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy connection methods; whether apps are routed through them and where DNS is resolved still depends on the client and its configuration. Changing protocols won’t fix a routing rule that explicitly sends traffic directly.

Test apps one by one to verify where requests take a different route

Once the browser test passes, open the app you actually want to use and try the relevant action, such as signing in, loading media, or downloading a file. Check the client’s connection view or diagnostic logs for the app’s domains, matching rules, and selected route. Menu names vary by client, so don’t assume they match another app’s instructions.

A single app may use different domains for sign-in, images, and media. The home page loading doesn’t mean video requests use the proxy. Conversely, a service rejecting a particular exit doesn’t mean the request bypassed the proxy. Account region, content rights, cache, device location permissions, and the service’s own restrictions can all affect the result.

  • ✅ Start by stating your goal: which app and feature, and whether you expect a direct or proxied connection.
  • ✅ Change one setting at a time and keep a record of results before and after connecting.
  • ✅ Check the matching rule and selected exit, then repeat the action you’re testing.
  • ✅ Test the browser and the target app separately; don’t assume a webpage’s result applies to the whole device.
  • ❌ Don’t treat page language, search result region, or connection speed as conclusive evidence.
  • ❌ Passing an IPv4 test doesn’t mean IPv6 and DNS are working as expected too.

If you’re concerned about WebRTC exposing an address, use a dedicated test and distinguish between local and public IPs. Browsers may show local network details in a form that hides the local address. Seeing those details doesn’t mean your public traffic bypassed the proxy. If the test shows your original public IP, check your browser policies and UDP routing.

Troubleshooting a connection that appears active but isn’t working

Don’t start by deleting the client or wiping all your settings. Save your current configuration and baseline first, then narrow down the cause in the order below. This preserves evidence you can reproduce and avoids changing several settings at once without knowing what fixed the issue.

  1. Check your basic network connection. Disconnect and see whether ordinary websites load. First rule out an incomplete network sign-in or a local outage.
  2. Check your service and subscription. Review your plan, remaining data, and subscription details in the account panel. Refreshing your subscription updates the configuration; it won’t automatically fix local routing settings.
  3. Check that the remote server is reachable. Review any client error messages. If needed, try another available server for comparison, but don’t treat the client’s latency test as proof that webpages can load.
  4. Check that traffic reaches the client. Review system proxy settings, tunnel permissions, and app exclusions. If there are no records of the request you’re testing, start by checking what the client is set to route.
  5. Check the rules and DNS route. See whether the request was marked for direct connection and whether DNS behavior matches your expectations, then check the exit IP. If you change a rule temporarily, restore it and update the permanent configuration afterward.
  6. Check app-level restrictions last. If the exit IP and routing rules look right but the feature still fails, check the account, cache, app version, and target service’s access policies.

Bottom line: check the request route, not the connection icon.

Compare public IPs to check the web request route, use DNS tests to check name resolution, and test the app alongside the client’s routing logs. Consistent evidence gives you a basis to judge whether the connection behaves as expected. If one check fails, investigate that layer instead of drawing conclusions from “connected” or “site won’t load” alone.

With VPNEast, you can find the client and subscription details in the account panel. For connection setup, see the Guides or visit the Help Center. VPNEast’s privacy policy states that it keeps no logs. Check your client’s settings separately to see what diagnostic data it generates and stores.