How can you tell if your VPN is working? Don’t rely on the connection button alone. Check your IP, DNS, and individual apps together: confirm which traffic should use an international route, check the actual exit, then test the apps you use. This helps distinguish expected split tunneling from a missed setting or a connection problem.
Your setup is working as expected when the target site uses the intended exit, DNS resolution follows your configuration, and the app can complete its task. A successful browser test only confirms that browser’s requests at that moment; it says nothing about other apps.
First, know the difference: connected doesn’t mean everything is routed
“Connected” usually means the connection process finished or a local proxy is running. It doesn’t necessarily mean every app is using it. System proxies, virtual network tunnels, and in-app proxies cover different traffic, so the same connection status can lead to very different results.
A system proxy relies on apps following the system settings. Some browsers do; command-line tools, games, and desktop apps may use their own network settings. Tunnel mode usually routes more traffic through a virtual network interface, but exclusions, destination addresses, protocol support, and system permissions still matter. Even a setting called “Global” doesn’t necessarily route every connection on the device.
Rule-based mode uses domains, addresses, or apps to decide what goes direct and what uses the proxy. So if an IP lookup site matches a direct-connection rule, seeing your local IP may be expected. Before testing, define your goal: should a particular work app use an international route, or should most device traffic go through the tunnel? The right result depends on what you’re trying to do.
Public IP: compare before and after connecting
Open this site’s IP lookup page. With the client disconnected, note your IP address and network provider. Then connect and run the same check in the same browser. Make sure the page sends a new request when you refresh; don’t mistake a cached or previously loaded result for your current connection.
- Pause other browser proxy extensions, and note the client mode and selected route. This helps prevent conflicting settings from affecting the test.
- Check your IP with the client disconnected and note the result. Connect, check again, and compare the address and network provider.
- If the result hasn’t changed, check which routing rule applies to the lookup domain. If it’s set to connect directly, first decide whether that matches your intended setup.
- To verify the proxy exit, temporarily route the lookup domain through the proxy if your client supports it. Restore your usual rules after testing.
- Finally, open the app you actually want to use. Don’t stop at the lookup page.
IP geolocation databases only provide an estimate of where an address is registered. Results can vary across databases and may be out of date. A changed address shows that this request used a different exit; a map label can’t confirm a server’s physical location or guarantee that a streaming service will accept the exit.
DNS checks: focus on the resolution path, not just the country
DNS translates domain names into network addresses. Routing a website connection through a proxy doesn’t guarantee that DNS queries take the same path. Likewise, a resolver showing a local region doesn’t by itself prove there’s a leak. What matters is whether DNS queries bypass the route you intended them to use.
DNS test sites often generate temporary domains and check which recursive resolvers handle the queries. They usually show the resolvers’ locations, not the full path between your device and those resolvers. Distributed public DNS infrastructure, forwarding, and geolocation database errors can all affect the results.
Start by checking your client settings: does it handle system DNS, how does it resolve domains sent through the proxy, and are direct-connection domains resolved separately? Then run a test and compare the results. If DNS is supposed to go through the tunnel but local ISP resolvers keep appearing, investigate further. If your rules allow direct domains to use local DNS, judge the results against that intended behavior.
Why can Secure DNS in your browser affect the results?
Your browser may use encrypted DNS instead of the resolver configured by your system. Encryption protects DNS traffic in transit; it doesn’t decide whether the connection uses a direct route or a proxy. The encrypted connection itself still follows your network routing. Apps with built-in DNS can behave similarly.
For troubleshooting, temporarily change your browser’s Secure DNS setting and compare it with the client settings. Change only one setting at a time and note its original value. If needed, clear the relevant DNS cache or restart the app. Refreshing a page may not trigger a new DNS lookup, and existing connections may continue to be reused.
Test apps individually: a browser check isn’t enough
Browsers and desktop apps may use different network stacks. Your browser’s IP can change while a terminal, meeting app, or game still connects directly. That’s not a contradiction. Use the table below to troubleshoot cases where the VPN works for only some apps. The exact setting names depend on your client.
Swipe horizontally to view the table on narrow screens.
| App type | Recommended test | What to check |
|---|---|---|
| Web browser | Check your public IP, then visit the target site and complete a real task | Proxy extensions, browser Secure DNS, domain routing rules |
| Desktop productivity and sync apps | Reconnect, then test sign-in, syncing, and file transfers | Whether the app follows the system proxy, has its own proxy settings, or reuses an existing connection |
| Meetings and real-time communication | Test audio and video in an authorized test environment | Different routes for media and sign-in traffic; UDP support |
| Command-line tools | Check the tool’s proxy options and whether its requests reach the client | Environment variables, tool-specific settings, tunnel coverage |
| Mobile apps | Check the system VPN status, restart the target app, and test again | App exclusions, other VPN settings, network changes |
If your client provides connection logs or a rule-match view, use it to check the target domain, process, and outbound policy on your device. Seeing a request assigned to the proxy is a useful clue, but check the actual response too. Some apps use different domains for sign-in, downloads, and media, so loading the home page doesn’t mean every feature will work.
System proxy and terminal settings can differ, especially on Windows, macOS, and Linux. On iOS and Android, check system permissions, app routing rules, and whether another VPN configuration is in use. Don’t assume every platform has a setting with the same name or behavior. See the client setup guide for download and import instructions.
Connected but not routed: troubleshoot by symptom
The client isn’t receiving the target app’s requests
First check whether the system proxy is enabled, whether the app follows proxy settings, and whether tunnel permissions have been granted. Also rule out interference from old browser extensions, other proxy software, or organization-managed settings. On a work device, don’t change managed routes or certificates without authorization; follow your organization’s network policies.
The request reaches the client but matches a direct-connection rule
Check rule order, domain matching, and app exclusions. Successfully importing a subscription only means the client accepted its contents; it doesn’t mean the rules fit your situation. Before updating, confirm the configuration source and keep any local settings you need. Don’t paste subscription links into public testing sites for troubleshooting—they may contain access credentials.
The lookup page works, but the target service doesn’t
The service may be affected by your account’s region, account permissions, cached data, or its own access policies. A changed exit doesn’t change your account region or guarantee access to all content. First distinguish a connection timeout from a DNS failure or a clear account message. If you see an account-related message, check the service’s guidance rather than repeatedly changing your network settings.
Web browsing works, but calls or games don’t
These apps may rely on UDP or use a separate route for media traffic. A successful web request doesn’t prove those data streams are routed through the tunnel. Check whether your client, protocol, and route configuration support the traffic involved. A protocol name alone doesn’t mean all device traffic is covered; the transport protocol and the operating system’s traffic-routing method are separate settings.
Troubleshooting checklist: keep results reproducible
Changing routes, DNS, modes, and app settings all at once makes it hard to know what fixed the problem—even if things start working again. Use the checklist below to compare results, and retest the target app after each change. After connecting or switching networks, an app may keep using an old connection; close and reopen it if needed.
- ✅ Identify the target app and expected route. Note the current mode, route, and relevant rules.
- ✅ Compare your public IP with the client disconnected and connected. Make sure the lookup page isn’t affected by an unexpected rule.
- ✅ Check DNS results against the client and browser settings; don’t rely on the region label alone.
- ✅ Complete a real task in the target app and check any available rule-match or connection details on your device.
- ✅ Change only one setting at a time, and restore temporary changes after testing.
- ❌ Don’t share subscription links, access credentials, or diagnostic screenshots containing sensitive work information.
When contacting support, include your device platform, client mode, network environment, target app, and what changed between connected and disconnected tests. Before sharing diagnostics, check for personal IP addresses, account identifiers, or subscription credentials. Submit your issue through the support section of the user panel. Don’t post your full configuration in public forums.
A connection icon alone isn’t enough evidence, and a changed IP only confirms part of the picture. Match the expected rules to actual requests to see which traffic is working and what still needs attention. GaoVPN’s no-logs policy describes the service’s privacy practices; it doesn’t replace connection checks on your device or prevent a target website from recognizing an account that’s signed in.