How can you tell whether your VPN is working after it says connected? Start by checking your public IP, then DNS, and finally the apps you actually use. A client’s “Connected” status only confirms that a connection has been established; it doesn’t prove that your browser, work software, and other apps are all using the selected route. The goal isn’t to make every address change, but to confirm that traffic follows your split-tunneling settings.
First, distinguish connection status from traffic routing
A client can connect to a server successfully while the system still sends an app’s requests elsewhere. Starting a local proxy listener, for example, doesn’t automatically enable the system proxy. And enabling the system proxy doesn’t mean every app will use it. Check whether your client is set to use the system proxy, tunnel traffic, or provide a proxy only for selected apps.
“Global” and “Rule” modes generally determine how traffic is routed after it reaches the client. System proxy and tunnel modes such as TUN determine how traffic gets to the client. These are separate layers. Switching from Rule to Global won’t automatically capture an app that bypasses the system proxy entirely. Check the documentation for the client you’re using for specific option names and supported features.
| What to check | What it can tell you | What it can’t confirm |
|---|---|---|
| Client connection status | Whether the client reports a connection to the server | Whether all apps are using the VPN |
| Browser public IP | The address used for that web request | Whether other apps and DNS use the same route |
| DNS test results | The resolver egress shown for the tested domain | Whether every DNS query avoids a direct route |
| App connection logs | The rule and route used by a target request | Whether every background connection from the app follows the same route |
The strongest evidence is when the target request matches the expected rule, its public IP agrees with the connection log, and the app’s actual feature works. A status icon or a webpage loading on its own can easily miss a problem.
Check your public IP before and after connecting
First decide whether the test site should use the proxy or connect directly. If your rules route that site directly, seeing the same address after connecting is expected. You can temporarily switch to the client’s global proxy mode for comparison, then restore your usual rules so the test setting doesn’t remain enabled in everyday use.
- Disconnect from the route, open My IP, and note your current public IP address and network provider. Don’t mistake a local address assigned by your router for your public IP.
- Connect to your chosen server, confirm that the system proxy or tunnel mode is enabled, and check whether the test site should use that server.
- Reload the test page so you don’t rely on an earlier result still displayed on screen. If your client supports connection logs, check the route used for that request too.
- Compare the IP address, rule, and server selection. If they don’t match, first rule out a cached page or a rule that sends traffic direct, then try another server if needed.
IP geolocation comes from address databases and doesn’t necessarily reflect a server’s physical location. Databases may report different cities, and a route’s entry point may differ from its public egress. A different city name alone doesn’t mean the connection failed; consider whether the address changed, the network provider, and the client logs together.
If your device supports both IPv4 and IPv6, check whether the test tool tests both paths. Verifying only one address type won’t rule out the other still connecting directly. Whether that traffic is captured depends on your client and configuration, so disabling a network feature shouldn’t be treated as a universal fix.
Check DNS: understand your resolution policy before looking for leaks
DNS translates domain names into network addresses. Routing webpage content through a proxy doesn’t guarantee that DNS queries use the same path. The system resolver, the client’s DNS module, the browser’s Secure DNS, and an app’s own resolver may all play a part.
Many DNS test sites generate test domains and display resolver details based on the queries they receive. They usually show the recursive resolver’s egress, not necessarily the address your device contacted directly. Public DNS services may also use distributed networks, so a resolver appearing in your region or nearby doesn’t by itself prove that DNS is leaking.
Check results against your intended configuration
- First check whether your client handles DNS and whether direct and proxied domains use different resolution policies. Different DNS paths under split tunneling may be intentional.
- Check your browser’s Secure DNS settings. Encrypted DNS requests made by the browser may bypass the system resolver, but encryption alone doesn’t determine whether they use the proxy or connect directly.
- Compare results before and after changing a setting while keeping the same network and server. Change just one setting at a time so you can identify what caused the difference.
- If you want proxied domains to avoid being resolved through your local network, check the actual resolution path for those domains. You don’t need to route every domain that connects directly within mainland China through a remote resolver.
Keep caching in mind. After you change DNS settings, the system, browser, or app may continue using cached results, so the current page may not trigger a new query. Follow the client and system documentation to clear caches, then fully quit and reopen the app you’re testing. Don’t treat a test with no new records as conclusive.
Test apps individually: a webpage loading isn’t enough
Testing each real-world use case is more useful than repeatedly reloading the same webpage. A browser handles web traffic, desktop software may have its own proxy settings, and games or real-time communications may use UDP. One request working doesn’t mean other traffic types are handled the same way.
On Windows and macOS, some apps use the system proxy while others have their own network settings. Linux desktop proxy settings, environment variables, and individual app options aren’t guaranteed to work together either. On mobile, a VPN status indicator doesn’t rule out per-app exclusions or destination-based routing; check the client settings.
- ✅ Browser: Open the target site and load real content, then check the public IP and the client connection log.
- ✅ Desktop app: Check its proxy settings, quit it completely and reopen it, then perform a real action such as syncing or downloading.
- ✅ Command-line tool: Check its own proxy options and proxy environment variables. A successful or failed terminal request doesn’t directly tell you whether the browser is working.
- ✅ Real-time communications: Test messaging, voice, and video separately. A successful text message doesn’t confirm that call traffic is working.
- ❌ Checking only the launch screen: It may come from cache, while the live data API uses a different domain and routing rule.
If your client provides a connection list, clear old entries first, then perform the action you want to test. Check the relevant process or domain, matched rule, actual route, and any error messages. Don’t assume an app is using the proxy just because the traffic graph is moving; other background processes may be responsible.
For troubleshooting, you can temporarily broaden traffic capture within a controlled scope. If the app works then but fails after you restore your rules, focus on split-tunneling rules. If the request never reaches the client, check the app’s proxy settings, capture mode, or app exclusions before blindly switching servers.
Common misdiagnoses: separate route issues, rules, and platform restrictions
The IP changed, but the target service still doesn’t work
That doesn’t necessarily mean the proxy isn’t working. A service may make decisions based on account region, licensing, the reputation of the egress IP, or device location. Verify the request path first, then check the platform’s rules. Streaming availability depends on testing the target platform; the egress country shown by itself isn’t enough to tell you what will work.
The app still uses its old connection after you switch servers
Some apps keep long-lived connections, which may not reconnect as soon as you switch servers. Fully quit and reopen the app to trigger new requests. Page content, existing sign-in sessions, and DNS cache can also affect what you see, so distinguish cached content from a genuinely new request.
A dedicated route is selected, but some apps still connect directly
IEPL, relay, and direct connections describe how a route is set up, not how traffic is captured on your device. A dedicated route won’t enable the system proxy for an app, and a relay doesn’t automatically send every domain through the proxy. Route selection determines the network path; client settings determine which requests use it.
Suspect a protocol mismatch and keep switching configurations
Shadowsocks, VMess, Trojan, and VLESS are different proxy protocols; Hysteria2 and TUIC also have their own transport and implementation requirements. Your client must support the protocols and settings provided by your subscription. Don’t try to fix a connection by changing only the protocol name. Get a fresh configuration from your dashboard and follow the setup guide to import and update it.
Wrap up troubleshooting with reproducible results
If the problem persists, note your network, client version, traffic capture mode, selected server, target app, and the steps to reproduce it. Replace “it won’t connect” with a specific report, such as “the browser’s public IP changed, but the desktop app’s requests don’t appear in the connection list.” That makes it much easier to narrow down the cause.
Before sharing screenshots, hide subscription links, credentials, and personal account details. Subscription links often contain access credentials and shouldn’t be posted in public forums. Logs may also include domains and device information, so share only what’s needed to diagnose the issue. For further help, see the troubleshooting guide in From Beginner to Advanced.
Use the public IP to check web requests, DNS to check resolution policies, and app-by-app tests to confirm real functionality. Compare all three before deciding whether a route suits your everyday needs. If one check doesn’t match expectations, troubleshoot that layer rather than redoing every setting.