How to Check If Your VPN Is Working: IP and DNS Tests

First, distinguish the connection status from the traffic route

VPN clients don’t all use “Connected” to mean the same thing. It may indicate that a system tunnel is established, or simply that a local proxy is listening. The local proxy can start even if the server is unreachable; conversely, a reachable server doesn’t mean an app is using the proxy.

A system proxy is generally used by apps that honor your system proxy settings; it doesn’t automatically cover all network traffic. TUN mode routes eligible traffic through a virtual network interface and usually covers more, but its scope still depends on exclusions, permissions, and the client’s implementation. A VPN icon on a mobile device doesn’t mean every app uses the same exit IP.

Also distinguish a successful node latency test from successful access to a website. The former may test only a connection or test address; the latter also depends on DNS, routing rules, the target service, and account restrictions. Protocol names such as Shadowsocks, VMess, Trojan, and VLESS aren’t a substitute for testing. Support for particular transport features depends on the client and service configuration.

Public IP check: record a baseline, then compare

Your public IP is the address websites see—not the local address your computer uses on your router’s network. Don’t compare the address in your device’s network settings with the result from an IP-check website. The country, city, and provider shown in the result come from IP databases and may be outdated, so location labels are only a supporting clue.

1. Record your IP before connecting. Disconnect the client, search for “what is my public IP” in your browser, and open a trusted IP-check site. Note the public IP, listed location, and network name. Stay on the same network throughout the comparison; don’t switch Wi-Fi.
2. Connect and check the mode. Choose a server and confirm that the system proxy or TUN mode is enabled as instructed. In rule-based mode, make sure the IP-check site itself is routed through the proxy; otherwise, seeing your local exit IP may be exactly what the rules are designed to do.
3. Run the test again. Refresh the IP-check page, or open a new private window if needed, and compare the addresses. Cross-check with a separate IP-check service to avoid being misled by cached results or an inaccurate database.
4. Verify with the app you’re testing. Review the client’s connection logs to confirm that requests to the target domain matched the proxy rule and selected server. When you’re done, restore your usual routing mode.

If the IP-check page reports both IPv4 and IPv6, check them separately. Some configurations route only one, and your browser may prefer the other. Don’t assume that a change to one address means all requests are covered; check your client’s IPv6 support and routing documentation.

DNS leaks: check the resolution path, not just the country

DNS translates domain names into network addresses. Routing web traffic through a proxy doesn’t mean DNS requests follow the same path. Whether a DNS leak is a problem depends on your configuration: it’s a routing mismatch when DNS was meant to go through the tunnel but requests are instead sent over your local network.

After connecting, search for and open a trusted DNS leak test, follow its instructions, and note the resolver names it reports. Compare them with the client’s DNS settings. These tests typically use dedicated domains to identify recursive resolvers involved in the lookup; they don’t show the entire path from your device to the resolver.

A local ISP resolver is a signal worth investigating, but seeing a public DNS provider outside your country doesn’t automatically prove there’s no leak. Public resolvers may use nearby points of presence, and browser Secure DNS (DoH) may work independently of system DNS. The resolver’s location isn’t the only factor.

• ✅ Check the client’s remote DNS, direct DNS, and domain routing settings; understand which requests each one handles.
• ✅ Check whether browser Secure DNS conflicts with the client’s setup. After changing a setting, restart the browser and test again.
• ✅ Check the client logs for DNS lookups and matched rules to confirm that the test domain followed the intended route.
• ❌ Don’t switch every DNS address to an unfamiliar public resolver. That may bypass your existing configuration without fixing the routing issue.

After changing DNS settings, existing DNS cache entries and persistent app connections may still use old results. Try closing and reopening the target app. If you need to clear the system cache, follow the official instructions for your platform. Avoid changing the server, DNS, and rules all at once; otherwise, even if the next test works, you won’t know what fixed it.

Test by app: a working browser doesn’t mean everything is routed

Browser extensions often affect only browser traffic; standalone apps won’t automatically use the proxy because an extension is installed. Conversely, an extension may override the system proxy, so the browser and other apps can use different exits. Pause any proxy extensions you don’t need and use one clearly defined routing method while troubleshooting.

On Windows and macOS, check whether another network tool changed the system proxy settings, and confirm that the app you’re testing honors them. Linux desktop proxy settings aren’t necessarily used by command-line programs: some read proxy environment variables, while others need to be configured separately. A browser IP check can’t verify a command-line tool’s route.

iOS and Android clients typically use the system VPN interface, but may still exclude specific apps or route traffic by destination address. If your browser works but a standalone app doesn’t, check whether the app is excluded and whether its domain matches a direct-connection rule before assuming the server is down.

The most useful approach is to open the client’s connection logs, launch the target app, and perform a real task such as signing in, loading content, or sending a request. Look for new domains, matched rules, and exit servers. An app may connect to several domains at once; opening its home screen doesn’t mean sign-in or media requests use the same route.

How to troubleshoot common “false connections”

Public IP hasn’t changed: check the rules, then traffic capture

Rule-based mode allows some sites to connect directly, so seeing your local exit IP on a local IP-check site isn’t necessarily a problem. First check which rule matched the request. To compare results, temporarily route the test request through the proxy explicitly, then restore your original settings. Even if the client calls a mode “Global,” check what it covers; implementations don’t all route every system connection.

Websites load, but the app still reports an error

First check whether the app uses the proxy and whether all relevant domains are routed correctly. Once you’ve confirmed the route, look into regional availability, account status, service outages, or restrictions on the exit IP. Cached pages can also give the impression that a site works; test a new action that requires a network connection instead of relying on content that has already loaded.

Changing servers doesn’t change the result

An existing connection may still be active, or the app may reuse an earlier session. Close and reopen the target app, then check the logs for new connections. If nothing changes, confirm which server the active policy group actually selected. Automatic selection, failover, or a separate app-specific policy group may differ from the selection shown on the home screen.

The subscription imports, but you can’t access anything

A successful subscription import only means the client read the configuration; it doesn’t mean a server is available. Check that the subscription is up to date, your account plan is active, and the client supports the configured protocol and transport. Don’t disable certificate verification or install certificates from unknown sources to fix a connection. Check the configuration against the service’s guide instead.

If switching to another route fixes the issue, note the original route, affected app, error message, and matched rules, then send the details to support. IEPL, relay, and direct describe how a route is set up; they don’t replace proxy routing or DNS configuration on your device. A route’s name alone doesn’t prove it’s working.

Confirm the results with this checklist

You don’t need to run every test after every connection. Repeat the checks after your first setup, switching clients, changing rules, or encountering an unexpected location. Keeping brief notes makes it easier to find the cause than reinstalling everything repeatedly.

• ✅ Recorded the public exit IP before and after connecting, and confirmed that the test request should use the proxy.
• ✅ Checked DNS settings and browser Secure DNS without relying on the resolver’s country alone.
• ✅ Performed a real network action in the target app and checked its connection logs.
• ✅ Checked IPv6, app exclusions, and existing connections, then restored the usual routing settings.

VPNUY users can check their client settings using the setup guide. For help, visit the Help Center and include the error message and troubleshooting notes, with sensitive information redacted.