To check whether your VPN is working, test your public IP, DNS, and app-by-app routing separately, then compare the results with your current routing rules. A connected indicator only shows that a connection has been established; it doesn’t prove that your browser, desktop apps, and system processes all use the same exit route.
The goal isn’t to make every IP address change. In rule-based mode, local sites may connect directly while requests that need international routes go through the proxy. That’s normal if the actual traffic follows your intended rules. Follow these repeatable steps to verify the route with evidence, rather than guessing from how quickly a page loads.
First, understand the difference between connection status and traffic routing
Network requests may pass through an app’s own proxy settings, the system proxy, or a virtual network interface. The client’s rules then determine whether each request connects directly or is forwarded. A connection between the client and a server doesn’t mean the operating system has routed every request through the client. Successfully importing a subscription only confirms that the client read the configuration—not that the routes in it have been tested.
The system proxy usually affects only apps that follow that setting. TUN mode routes traffic through a virtual network interface, but its coverage still depends on routing, exclusions, and the client’s implementation. Android’s per-app list may include only selected apps. Don’t assume that “global” in the client interface means every connection on the device.
Public IP: Compare results before and after connecting
Your public IP is the address a website sees as the source of your request, not your device’s address on a local network. Use a reputable public IP lookup page and, if possible, the same browser and lookup service for both checks. Your IP address is personal network information; there’s no need to post the full result publicly.
- Disconnect the client and make sure no other proxy tools are still running. Open a public IP lookup page and note the address, network or provider, and time of the check.
- Connect to the server you want to test and confirm that the browser’s app is included in the proxy scope. Reload the lookup page, using a new browser window if needed, so you don’t mistake an old page for a fresh result.
- Compare the public IP address and network information. If the lookup page matches a proxy rule, you’ll generally see a different exit IP. If it matches a direct-connection rule, an unchanged address doesn’t by itself mean the VPN has failed.
- If the lookup service supports it, check IPv4 and IPv6 separately. Routing one address family through the proxy doesn’t mean the same rules apply to the other.
IP geolocation databases can take time to update, and lookup services may show different cities. The server name, the location of the access server, and the final exit location may not match exactly. First check whether the IP changed and whether the request matched the expected rule; then assess the location label. Don’t declare a routing problem based only on the city shown.
A browser lookup confirms only the exit route for that browser request. Standalone apps may use their own network settings, so this check can’t replace the app-by-app tests below.
DNS: Check the resolution path, not just the location
DNS translates domain names into IP addresses. A web request may go through the proxy while DNS lookups are still handled by your local network’s resolver. Whether that’s a DNS leak depends on what you’re trying to protect: it’s a concern if relevant lookups are expected to use a specified route but instead bypass it.
With a reputable DNS test page, note the results while disconnected, then connect and run the full test again. Check the resolver’s operator, the client’s DNS settings, and your browser’s Secure DNS settings. A browser may use encrypted DNS independently rather than following system settings, so browser results don’t represent every app on your device.
The addresses shown by a test page usually identify the recursive resolver’s exit, not the full path between your device and the resolver. Public DNS services may use anycast and distributed infrastructure, so a different location doesn’t necessarily mean a leak. If the results show your local provider, check your rules, logs, and configuration before drawing a conclusion.
- ✅ Record the DNS settings for your system, client, and browser, and identify which one handles lookups.
- ✅ Compare the resolver information before and after connecting, and check whether the client records the relevant lookups.
- ✅ After changing settings, reopen the app and run a fresh lookup so you don’t rely on cached results.
- ❌ Don’t treat a test page’s color or location label as a security verdict for your entire device.
Don’t disable all Secure DNS features or change system settings just to make a test page “turn green.” First check for conflicting settings, then adjust them according to the client’s instructions, changing one item at a time.
App-by-App Verification: Why a Working Browser Doesn’t Mean Other Apps Are Covered
Test the browser, desktop software, or mobile apps you actually plan to use, making a fresh network request in each one. Start with the client’s connection logs and check the destination domain, process, matched rule, and outbound route. Some clients don’t show every field. If information is missing, check the app’s network settings rather than guessing.
On Windows and macOS, distinguish between the system proxy, an app’s own proxy, and TUN routing. Command-line tools may read only their own proxy options or environment variables. On Android, check whether per-app proxying uses an allowlist or a blocklist. On iOS, refer to the client’s routing policy and the system’s connection status instead of looking for desktop menu names.
Some apps keep connections open in a connection pool. After switching servers, an existing connection may temporarily continue using its original route. Save your work, fully quit and reopen the app, then check a new request. This is more useful than repeatedly clicking the client’s connect button.
| What you see | Possible explanation | What to check next |
|---|---|---|
| The browser’s exit IP changes, but a standalone app’s doesn’t | The app may not follow the system proxy or may be excluded by per-app rules | Check the app’s proxy settings, routing scope, and process logs |
| Some sites connect directly while others use the VPN | Rule-based mode routes traffic by destination; this may be expected | Check which rule matched the domain and which outbound route it used |
| The web exit IP changes, but DNS results still appear related to the local network | DNS may use a separate route, or the test may show the resolver’s exit | Check Secure DNS, the client’s DNS policy, and its logs |
| Results don’t change immediately after switching servers | A cached page, a persistent app connection, or a direct-connection rule may still be in effect | Make a fresh request and check the new connection and rule logs |
| The route looks right, but the destination platform still denies access | The platform may have separate restrictions based on region, account status, or exit IP reputation | Note the error message and distinguish a network failure from a platform denial |
Connected but not routed through the VPN: Troubleshoot by layer
Check that the configuration is actually enabled
A subscription link lets the client retrieve server and routing settings; it doesn’t prove that the connection is working. After importing it, check that the update succeeded, the intended configuration is selected, and the current server comes from that configuration. An old configuration still being active, a failed subscription update, or a disabled system proxy can all make the interface differ from the actual route.
Check the rules and routing permissions
First check whether the request matched a direct, proxy, or reject rule. Rules usually have a matching order, so a broad direct-connection rule may take precedence over a more specific rule later in the list. TUN routing may also fail if it hasn’t been granted the required permissions or system network extension access. Follow the instructions for your operating system and client to authorize it.
Check whether multiple tools are conflicting
Multiple proxy clients, browser proxy extensions, or network filtering tools may compete over system proxy, routing, or DNS settings. Record your current configuration, then disable nonessential tools one at a time and test again. Don’t delete unfamiliar certificates, network interfaces, or system components, as this could cause further problems.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are names of different proxy protocols or solutions. A protocol name alone doesn’t prove that traffic is being routed, nor does it tell you which exit an app is using. Check permissions, rules, connection logs, and actual requests; don’t skip verification just because you recognize a protocol.
Distinguish access problems from a failed connection
If the exit IP and rule logs match your expectations but a site still won’t load, check whether the problem is DNS resolution, a connection timeout, a certificate error, or an explicit denial by the platform. Site outages, account region, sign-in status, and access policies can all affect the result. A network route can’t override a platform’s own access requirements.
Conversely, a page loading doesn’t prove that it used the VPN. The site may be reachable directly, or the browser may be showing a cached page. A speed test reflects only a specific request; it can’t prove how other apps are routed or whether your account or subscription link is secure.
Final verdict and retest notes
A useful test record includes the network, client mode, selected server, test app, destination domain, exit IP changes, DNS results, and matched rule. After changing networks, updating the configuration, or adjusting routing rules, repeat the same tests to identify what caused any difference.
How to assess the result: You can conclude that a request followed the intended route when the app’s new request matches the expected outbound rule, the exit result is consistent with that route, and relevant DNS lookups follow the configured policy. This conclusion applies only to the apps and scenarios you tested; it doesn’t mean the entire device is permanently protected.
When using VPN57, follow the setup guide to configure your client, then run the checks above. If the results are still unclear, submit redacted error details and test steps through the support ticket portal. VPN57 uses military-grade encryption, and no email address is required to get started. Keep your account and subscription link secure.