A VPN connection icon isn’t proof that your VPN is working. For a reliable check, compare your public IP, verify the DNS resolution path, and test apps individually. If a webpage loads in your browser, that only confirms that particular request succeeded. It doesn’t prove that every app is using the proxy—or that all traffic is routed as expected.
First, define what you need: should specific websites use international routes, or should most of your device’s network requests go through the tunnel? With split tunneling, local websites may continue using your regular connection—that can be completely normal. Follow these checks in order: establish a baseline, inspect the route, then test individual apps. There’s no need to keep reinstalling the client.
First, separate connection status, exit IP, and app results
“Connected” in the client may only mean that the local proxy is listening or the system VPN interface is up. Access to the selected server, domain resolution, and whether the target app uses that interface are separate steps. An issue at any one of them can occur while the client still shows a connected status.
| What you check | What it can tell you | What it doesn’t prove |
|---|---|---|
| Client shows connected | The local connection process is running | Every app is using the remote exit |
| Browser exit IP has changed | This test request used a different exit | Other apps, DNS, and other address-family traffic follow the same route |
| A DNS test shows a particular resolver | That resolver handled lookups for the test domain | DNS queries definitely went directly over your local network |
| The target app works as expected | The connection path for this feature is working | All of the app’s background connections use the proxy |
To determine whether the VPN is working, combine the evidence. An IP check shows where a request exits; a DNS check looks at whether resolution matches your configuration; and an app test confirms whether your actual need is met. Relying on just one can make normal split tunneling look like a failure—or hide requests that bypass the proxy.
Check your exit IP: compare before and after connecting
Disconnect the client and open a trusted IP-checking site in the same browser. Note your public IP, network provider, and approximate location. Then connect to your chosen server and refresh the same page. Don’t mistake the local network address in your system settings for your public exit IP; it’s only the device’s address on your local network.
- Keep the same network and browser, and note the results while disconnected.
- Connect to your chosen server and confirm the client’s current mode and selected exit.
- Reload the test page. If needed, use a private window to reduce the chance of stale results affecting the test.
- Check the client’s connection log to confirm the test domain matched a proxy rule rather than going direct.
- Disconnect and test again. Check whether the result returns to its original state to create a repeatable comparison.
With rule-based routing, the test site itself may be set to connect directly. If so, an unchanged IP doesn’t mean the server has failed. Check which rule matched first. If you temporarily switch proxy modes for diagnosis, make sure the test request is covered. Restore your original settings when you’re done to avoid affecting local services.
Check both IPv4 and IPv6. A test page may show only one address while the other still uses your regular network. Use a test that displays both separately, and check whether the client handles traffic for each. If your current network doesn’t support IPv6, not seeing an IPv6 result isn’t proof that the client is routing it.
IP geolocation comes from databases, and different sites may show different cities. Focus on whether the address changed, whether the network provider makes sense, and whether the connection log matches. A different city name alone doesn’t prove you chose the wrong route.
Check for DNS leaks: focus on the resolution path, not just location
DNS translates domain names into addresses that devices can connect to. An app’s requests may use the proxy while its DNS queries still go over your local network, potentially exposing lookup information or returning results that don’t suit your current exit. But a DNS test shows which services took part in resolving a domain; it isn’t a complete map of the traffic path.
Before testing, review the client’s DNS settings. System DNS, remote resolution, encrypted DNS, and fake-IP modes work differently. Your browser may also have Secure DNS enabled separately, bypassing the system’s default resolver. Check the browser and client settings together instead of treating an unfamiliar provider as proof of a leak.
After connecting, run a trusted DNS test. Note the resolver names and their network providers, then compare them with the results from when you were disconnected. A resolver from your local ISP is worth investigating, but seeing a public resolver doesn’t by itself prove either safety or a leak. The same resolver may operate in multiple locations, and its displayed location may not show where your request actually went.
More useful evidence comes from the client’s DNS logs, matched rules, and outbound connection records. First check which resolver handled the domain, then confirm that the DNS connection used the expected outbound route. Some proxy modes resolve domain names remotely, so the corresponding DNS request may not appear locally. Don’t draw conclusions from missing local records without considering your configuration.
Old cache entries can affect results after you change settings. Close the relevant apps, reconnect, and clear the DNS cache as directed by your operating system before testing again. Don’t disable certificate checks or install certificates from unknown sources; neither will fix routing or DNS resolution issues.
Test apps individually: a working webpage doesn’t mean every app works
On desktop, “system proxy” settings usually affect only apps that follow them. Some apps use their own networking libraries and ignore the system proxy; command-line tools may need proxy environment variables set separately. TUN mode routes traffic through a virtual network interface and usually covers more, but it’s still affected by routes, exclusions, and system permissions.
Check the actual settings on mobile, too. Android clients may have per-app proxy settings or bypass lists, allowing excluded apps to connect directly. On iOS, traffic routing depends on the client’s tunnel and rules. A status-bar icon still isn’t a substitute for testing access and checking logs.
- ✅ Browser: Visit the site you need to test and check which outbound route its domain matched.
- ✅ Desktop apps: Quit and reopen the app, then check sign-in, content loading, and the feature you need.
- ✅ Command-line tools: Check the tool’s own proxy settings; don’t assume it inherits the system proxy.
- ✅ Mobile apps: Check whether the app is on a bypass list and compare the same action before and after changing settings.
- ✅ Audio and video apps: Test page loading and actual playback separately; a visible thumbnail isn’t enough.
Apps often use separate domains for sign-in, content, downloads, and media. If the home page loads but playback fails, media requests may not be matching the proxy—or the issue may involve exit IP reputation or content licensing. Check new connections while reproducing the failure instead of testing only the home page domain.
A browser WebRTC test can provide additional context. A local network address or a masked localhost identifier doesn’t mean your public exit IP has leaked. If you see an unexpected public IP, check browser permissions, tunnel routing, and actual connection logs together.
Common false connections: narrow down the cause by symptom
IP hasn’t changed, but the client still says connected
First check whether the system proxy or TUN mode is actually enabled. Then see if a browser extension is overriding the proxy settings. When multiple networking tools are running, they can interfere with routes or proxy ports. For the test, keep the client you’re troubleshooting and quit other tools according to their instructions, then repeat the baseline check.
IP changed, but the site still reports the wrong region
A site may use your account region, payment details, location permissions, cookies, and IP reputation to determine access. A changed exit IP only shows that the request used a different network; it doesn’t guarantee the platform will accept that region. Check your account and the site’s rules first, then look at cached data. Don’t assume every region warning is caused by DNS.
Browser works, but other apps keep spinning
Check whether the app uses the system proxy, is on an exclusion list, or has domains matching a direct-connection rule. For real-time communications, also check whether the client, server, and transport path support UDP. A protocol name alone doesn’t prove that the current setup supports all the traffic an app needs.
Domain resolves, but the connection won’t establish
A successful DNS lookup only means a result was returned. The server may be unreachable, subscription details may be outdated, transport settings may not match, or the system clock may be wrong. Start with the specific error. Don’t keep changing DNS just because resolution worked, or assume settings are compatible just because they use the same protocol.
Keep records so you can reproduce the issue
Change one setting at a time. If you switch servers, change proxy modes, update DNS, and reopen the app all at once, even a successful result won’t tell you what fixed it. Record the test time, network, client version, mode, server name, failed action, and relevant logs.
Subscription links usually contain access credentials. Don’t post the full link, QR code, or configuration file in a public forum. Before sharing logs, check for tokens, account details, and full addresses; provide support with only the relevant excerpts. If you need to import the subscription again, retrieve it from your account and confirm that the client supports the protocols and settings it contains.
If you’ve confirmed that local traffic routing works but your chosen server keeps failing, update your subscription and compare it with another available route. If you still can’t find the cause, follow the reproduction steps on the troubleshooting page. For client setup, see the user guide. Specific details about where things fail are more useful to support than simply saying “it won’t connect.”
How to tell: Requests expected to use the proxy have matching exit IP and connection-log evidence; the DNS path matches your configuration; and the target app’s actual feature works. Together, these provide good evidence that the VPN is working for the scenario you tested. This conclusion applies only to the apps and actions you checked—it isn’t a permanent guarantee for all network traffic.
Finally, don’t confuse privacy policies with connection tests. VPNGlass’s privacy statement is “anonymous, no logs.” That’s a statement about the service’s policy; an exit IP test can’t verify its logging practices, and a privacy policy can’t replace checking local traffic routing. Keep clear about what each can prove, and troubleshooting gets much simpler.