If your VPN connects but doesn’t work, don’t rush to switch servers. Your public IP, DNS, and app-by-app checks answer different questions: where requests exit, which resolver handles domain names, and whether the target app is using the current settings. A connected indicator is only a starting point, not a substitute for these checks.
The easiest approach is to compare results before and after connecting, changing just one setting at a time. Test your browser first, then the app you actually use. Confirm the traffic route before investigating regional messages on the site itself. This helps avoid mistaking account restrictions, cached data, or routing rules for a server problem.
Connection status vs. actual traffic routing
A client showing “connected” may mean that a tunnel has been established or that a local proxy has started; the exact meaning depends on the client. A VPN icon in your system tray also doesn’t mean every app and domain uses the same exit. Rule-based modes may intentionally send some requests directly.
Assess each piece of evidence within its limits. An IP lookup in your browser shows the exit used by that particular request. A DNS test only shows the resolution path observed during that test. Neither proves how all traffic from your device is routed.
| What you check | What it tells you | What it does not prove |
|---|---|---|
| Client shows connected | The client reports an active connection | That every app is using the VPN route |
| Public IP address has changed | The exit used for this lookup has changed | That other apps and DNS use the same route |
| DNS test lists a resolver provider | The test domain was handled by the listed DNS infrastructure | That the resolver’s location is the same as the traffic exit location |
| Target app works again | The target request from this app can complete | That other services will have the same result |
Public IP: compare before and after connecting
Use a site that displays your public IP, and compare results in the same browser and on the same network where possible. Don’t switch between Wi-Fi and mobile data during the test, as a change in your underlying network’s exit can skew the results.
- Disconnect the client, open the lookup site, and note the public IP, network provider, and reported location. Keep these details private; there’s no need to share your full address.
- Connect to the server you want to test, make sure the client shows no connection errors, then reload the lookup page. If needed, use a new private window to avoid results from an older page.
- Compare the IP addresses themselves, not just the location labels. Different addresses may be listed in the same location, and geolocation data may not be up to date.
- If the address hasn’t changed, check whether the lookup site matches a direct-connection rule. Following your client’s instructions, temporarily switch to a broader routing mode and test again. Restore your original settings afterward.
A changed public IP means this browser request used a different exit, but the location label alone can’t identify the specific route. Conversely, an unchanged address doesn’t always mean the connection failed: the lookup site may be routed directly, or the page may be showing cached results. Check the client’s rule-match logs as well.
DNS checks: resolver location isn’t traffic exit location
DNS translates domain names into addresses needed to connect. Apps may use the system resolver, encrypted DNS in the browser, a DNS module in the client, or their own resolution method. So a change in your browser’s public IP doesn’t automatically mean every DNS request follows the expected route.
A DNS leak test typically queries specific domains, then reports the recursive resolvers it detects. Check the resolver provider, test environment, and current settings rather than drawing conclusions from an unfamiliar country label. Public DNS services may use distributed infrastructure, so the reported location may differ from yours or your VPN server’s location.
How to interpret local DNS results
If you expect a target domain’s DNS requests to use the VPN route but see your local network provider’s resolver, check the DNS path. However, rule-based modes may intentionally use local DNS for domains routed directly. Whether that’s a leak depends on your configuration and what you expect it to do.
First check whether your browser uses its own encrypted DNS. Then see whether the client handles system DNS and whether direct and proxied domains use different resolution policies. If the client offers remote DNS or leak protection, consult its documentation to understand each option instead of enabling every setting at once.
After changing DNS settings, old records may remain in your browser, system, or app cache. Close and reopen the target app before testing again. To clear the system cache, follow the official instructions for your operating system. Changing DNS alone won’t route traffic through the VPN or fix an app connection that bypasses the proxy.
Test apps individually: the browser works, but what about other apps?
If your browser works but a desktop app doesn’t, they may be using different network paths. Some apps follow the system proxy; others ignore it. Browser extensions may only affect the browser itself. Don’t assume a successful test in one browser tab applies to your whole device.
A system proxy provides settings to apps that support it; it doesn’t automatically handle every connection. Tunnel mode routes traffic through a virtual network interface, but can still be affected by routing, exclusion lists, and app-scope settings. Mode names vary between clients, so check what traffic is actually covered—not just whether a toggle is on.
- ✅ Browser: Check the system proxy, proxy extensions, and custom DNS settings to make sure they aren’t overriding one another.
- ✅ Desktop apps: Check for proxy settings in the app itself. Quit background processes, restart the app, and try the same action again.
- ✅ Android: Check whether the target app is excluded from the VPN and whether battery management is stopping it from running in the background.
- ✅ iOS: Make sure the system allows the current VPN configuration to run, and check for other network-filtering configurations. Don’t rely on the status bar icon alone to determine whether an app is covered.
- ✅ Command-line and developer tools: Check the tool’s own proxy options or environment variables. A proxy setting in a graphical interface may not carry over to terminal programs.
When retesting an app, repeat the same real-world action, such as refreshing a page or fetching the same resource. If the app keeps using an existing connection, results may not change immediately after switching servers. Fully quitting and reopening it makes comparisons more reliable.
Troubleshoot by symptom: caching, routing rules, and conflicts
Your IP lookup changed, but the site still shows the old location
The site may also use your account region, cookies, previous sessions, or device location. Its IP geolocation database may differ from the one used by your lookup tool. First compare in a private window while signed out, then check the service’s regional rules. Clearing your cache doesn’t guarantee access will be restored.
A speed test works, but the site you need won’t load
A client’s latency check or connectivity test usually covers only a specific probe target. It doesn’t prove that the target site’s domain resolves or that its connection and application-level requests will work. Check how the target domain matches your routing rules, then compare with another available server instead of focusing only on the speed-test panel.
No working connection after importing a subscription
A subscription link is a way to obtain configuration, not proof that a connection is working. Make sure the update completed without errors, the client supports the subscription’s protocols and configuration format, and a working server is selected. Shadowsocks, VMess, Trojan, and VLESS are distinct protocols; changing a display name won’t add protocol support.
It worked at first, then stopped after the screen locked
Check whether the client is still running, the system has paused background activity, or the underlying network has changed. On desktop devices, also check for conflicts from other proxy apps, network-filtering tools, and old configurations. Temporarily pause only one potentially conflicting feature at a time, retest, and restore unrelated settings so you don’t introduce new variables.
Retest steps and recording results
If the checks above haven’t pinpointed the issue, use the steps below to narrow it down. The goal isn’t to collect more screenshots, but to change one thing per test and record steps that can be repeated.
- Record the basics: operating system, client name, current mode, selected server, and the app where the problem occurs.
- On the same network, compare your public IP while disconnected and connected. Note whether the lookup domain is routed directly.
- Review the DNS test and the browser’s custom DNS settings to see whether they match your current routing goals.
- Restart the target app and repeat the same action. If only that app has a problem, start by checking its proxy settings and exclusions.
- Keep all other settings unchanged and test another available server. If the issue persists, note the error message and what triggers it, then contact support through the site.
Useful feedback describes observable facts, such as “the browser’s exit IP changed, but the target app still times out,” rather than just “it doesn’t work.” If the client provides diagnostic logs, review and redact credentials and personal information before sharing only the relevant excerpts.
VPNGL’s key security feature is quantum encryption, but connection checks should still focus on the actual request path. For setup help, see the Quick Start Guide and Complete Manual. If an issue is hard to reproduce or persists, find support options on the Contact Us page.