How to Check If Your VPN Is Working: Public IP, DNS Leaks & App-by-App Tests

To check whether your VPN is working, don’t rely on the client’s connection icon alone. A changed public IP shows that the tested request is using a different exit; a DNS test shows how queries are resolved; and app-by-app testing confirms whether the software you’re using follows the expected route. Taken together, these checks help distinguish normal split tunneling from a proxy that isn’t handling traffic or a genuine connection failure.

“Connected” doesn’t always mean your traffic is protected

Clients don’t all define “connected” the same way. It may mean the proxy core is running, a system tunnel is up, or the client has confirmed that a server responds. None of these statuses alone proves that your browser, desktop apps, and background processes all use the same exit.

Start by defining what you expect. With rule-based routing, direct connections to local sites and proxy routing for selected international sites may be exactly right. If you want all traffic handled by the client to use the chosen exit, check the traffic interception method and exception rules. “Global” mode usually means traffic that has reached the proxy core uses one selected exit; it doesn’t necessarily mean every app is routed through the core.

What you observe	What it tells you	What it doesn’t tell you
The client shows Connected	The client reports that the connection or core is running	Whether the target app’s traffic is being intercepted
The browser’s public IP has changed	Requests tested in that browser are using a different exit	How other apps and protocols are routed
The DNS resolver matches the configuration	The resolver observed in this test matches expectations	Whether every domain and app always uses the same resolver
The target app’s request matches the expected rule	The request reached the client and selected the specified policy	Account eligibility, content access, or ongoing connection quality

Check your public IP: record a baseline first

Your public IP is the network address websites see, not your computer’s local network address. The IP shown in a browser is more useful for checking your route than the local address in system settings. Before testing, note your current network setup so you don’t mistake a Wi-Fi change, another proxy, or a browser extension for the result of this connection.

Record a baseline. When a brief direct connection is safe and no sensitive task is running, pause the client and open a trusted IP lookup site. Note the public IP, network provider, and whether the page reports IPv4 and IPv6 separately.
Enable the expected setup. Connect to the chosen route and make sure the system proxy or virtual adapter is enabled as needed. Note whether the client is in rule-based or global mode.
Make a fresh request. Reload the lookup page, or reopen it if the result looks cached. Compare the addresses from before and after connecting, and check whether the client logs a connection for the domain.
Cross-check the result. Verify it on a separate lookup site. Geolocation databases may not update in sync, so focus on whether the IP changed and the request used the expected exit—not just the city label.

If your IP doesn’t change with rule-based routing enabled, first check whether the lookup site is set to connect directly. Testing another site only changes the request being checked; a more reliable approach is to inspect how the client’s rules handle that domain. If you temporarily switch modes to troubleshoot, note the original settings and restore them afterward.

Check IPv4 and IPv6 separately. A changed IPv4 exit doesn’t prove that IPv6 traffic is also being handled. But if the client doesn’t support IPv6 forwarding and your system has no available IPv6 route, the page not showing IPv6 isn’t necessarily a problem. If IPv6 traffic still uses your local exit, check the client’s support, routing, and leak protection settings rather than disabling system-wide security features.

DNS leak test: check the resolution path, not just the flag

DNS translates domain names into network addresses. A DNS leak generally means that queries aren’t following the expected protected route and are instead being sent to your local network or another unintended resolver. Even when web traffic goes through a proxy, DNS queries may take a different path, so being able to open a website isn’t a substitute for checking DNS.

Run the full test on a trusted DNS leak test site and note the resolvers it reports. Compare them with the client’s DNS configuration, your system settings, and the browser’s secure DNS settings. These sites typically check which recursive servers handle queries for specially generated domains; they don’t capture every DNS request from your device.

Seeing your local provider’s resolver after connecting is a reason to investigate, but the resolver’s country alone can’t confirm a leak. Public DNS services may use nearby access points, remote exits, or different registration details. Conversely, a resolver listed overseas doesn’t prove that queries passed through the selected tunnel.

✅ Compare settings: Check whether the client is set to use remote DNS, system DNS, or domain-based DNS routing.
✅ Check your browser: Secure DNS may select a resolver independently. Make sure that choice fits your privacy goals.
✅ Test again: After changing settings, clear relevant caches as recommended by your system or client, then make a fresh request to avoid stale results.
❌ Don’t treat a resolver’s country flag as a definitive result, or a single successful test as proof that every app is covered.

Encrypted DNS protects queries in transit between your device and the resolver, but the resolver may still see them. It also doesn’t automatically ensure that queries pass through a VPN. Some proxy modes send domain names to be resolved remotely, while some apps resolve them on their own, so check the actual connection logs. If the client shows Fake-IP, it usually refers to an internal domain-mapping mechanism—not a real public exit IP.

Test apps individually: a working browser doesn’t mean everything works

A system proxy gives apps that honor the setting an HTTP or SOCKS proxy endpoint; it isn’t a universal switch for routing all network traffic. Some desktop software, command-line tools, games, and background services ignore system proxy settings. Other apps have their own proxy settings. A browser extension may affect only the browser and can’t confirm how desktop apps are routed.

Virtual adapter mode typically routes more traffic through system routes, but app exclusions, route exceptions, DNS policies, permissions, and protocol support still matter. On Windows and macOS, check whether other network tools are competing for the system proxy or routes. On Android, review per-app include and exclude lists; on iOS, check the active network configuration and client rules. Features vary between clients, so don’t assume settings have the same names across platforms.

Reproduce a real task in the target app

Open the client’s connection panel or logs and check existing requests first, so you don’t mistake background updates for traffic from the app you’re testing.
Refresh content or perform a real task in the target app. Check the new domains, destination addresses, and matched policies; if the client identifies processes, verify the process name too.
Make sure the request uses the expected proxy group and route—not a direct connection, a reject rule, or an unexpected automatic selection.
If you changed a rule or proxy setting, save it and reconnect. If needed, quit and reopen the target app so it doesn’t keep using an existing long-lived connection.

No log entry doesn’t necessarily mean the app isn’t connecting. The log level, filters, or client’s visibility may be limited. First check whether the log shows other known requests, then review the app’s own proxy settings and whether its traffic is being intercepted. Command-line tools may also read proxy environment variables, so a working browser doesn’t prove that a terminal connection will work.

Web pages, voice, and video may use different transport methods. Browser QUIC typically runs over UDP, so check whether UDP is being handled and whether the proxy chain supports the required forwarding. If text loads but voice calls fail, check protocol and routing support first instead of assuming the network path is fine because a page loaded.

Common false connections: find the problem by symptom

Connected, but the exit IP never changes

Check whether only the proxy core was started while the system proxy remains off, or whether the test domain matches a direct-connection rule. Then check for another browser proxy extension or outdated app settings. Avoid running multiple traffic-interception tools at once: they can override each other’s proxy endpoints, routes, and DNS settings, making the cause hard to identify.

The exit IP changed, but the service you need is still unavailable

That doesn’t necessarily mean the VPN isn’t working. A platform may also restrict access based on account region, an existing session, IP reputation, or service availability. Note the exact error and distinguish a connection timeout, DNS failure, certificate error, or an explicit access restriction from the platform. The last one isn’t necessarily a network transport problem.

The subscription imported, but all requests fail

A successful import only means the client received and parsed the configuration; it doesn’t mean a node can connect. Check the selected node, subscription update status, and client compatibility. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different protocols or protocol families. The client must support the protocol and transport settings used in the configuration. These protocols aren’t the same as route descriptions such as IEPL, relay, or direct connection.

IEPL, relay, and direct routes describe the network path traffic takes; they don’t replace app routing or DNS checks. The same route may perform differently on different local networks, so a route label alone can’t establish latency or reliability.

Drawing a conclusion: keep evidence, then adjust settings

A useful troubleshooting record includes your local network, client mode, selected route, IP changes, DNS test results, the target app’s exact error, and which rule matched. Change one factor at a time and repeat the same steps. That way, you can tell whether the improvement came from switching routes, fixing a rule, or having the app establish a new connection.

Don’t disable your firewall, ignore certificate warnings, or install untrusted root certificates just to “pass” a test. Military-grade encryption describes connection protection; it doesn’t replace correct traffic routing, HTTPS verification by the destination site, careful account security, or device protection.

A practical way to tell if your VPN is working

The tested request uses the expected exit, DNS follows the configured route, and real requests from the target app match the right policy and produce an explainable result. These checks show that the connection is working as expected in the scenario you tested; they don’t guarantee the same for every app, at all times, or for access permissions on every platform.

For more help configuring your client, see the setup guides. To understand how plan data allowances work, see plans and pricing. Verify the route first, then look at route choices and performance—it makes troubleshooting more straightforward.