How can you tell if your VPN is really working? First, check whether the app you're testing is routed according to its rules, then check your IP and DNS. VPN56's app-based split tunneling separates direct connections in mainland China from international routes. So if a website in mainland China still shows a local IP, that doesn't necessarily mean the VPN failed. And a changed IP in your browser doesn't mean your other apps are routed through the VPN.
A reliable check compares where traffic is supposed to go with where it actually goes. A connected status usually only confirms that a connection was established; it doesn't prove that a particular app's new request is using an international route. Follow these steps: establish a baseline, check your IP, review DNS, and test the app.
Set your routing rules before connecting
Before you start, check the current mode and rules in your client. Confirm whether the browser or app you're testing should connect directly or use an international route. If the client has both app and domain rules, check which takes priority. Matching behavior varies by client, so a mode name alone doesn't tell you where every request will go.
Disconnect temporarily and open the network test page on the same network. Note your current public IP, ISP, and the time of the test. Also check whether the target app can complete the task you need. Then connect to VPN56 and repeat the test without changing your network. Keeping the conditions the same helps avoid false results caused by a network switch, cached pages, or the app's state.
- ✅ Define the expected route: apps in mainland China should connect directly; selected international apps should use an international route.
- ✅ Record your setup: network, client mode, selected route, and app name.
- ✅ Keep the comparison consistent: use the same device, network, and test method before and after connecting.
- ❌ Don't treat the status icon, page load speed, or access to a single website as conclusive proof.
Check your IP: the result should match your rules
Your public IP is the address a test site sees as the source of your request. After connecting, if your browser is set by the rules to use an international route, its public IP will usually differ from your direct-connection baseline. But the result only shows how that browser reached that specific test domain; it doesn't represent your entire device. If the test domain is set to connect directly, an unchanged result may be expected.
IP geolocation comes from address databases, which may take time to update. Check whether the address changed, whether the client logs show the connection using the selected route, and how the target app behaves. A location label that doesn't match your expectations doesn't prove the route failed. Likewise, matching locations don't mean the IP addresses are the same.
| What you see | What it may mean | What to check next |
|---|---|---|
| Browser IP has changed | The test request may be using an international route | Check the connection log, then test the target app |
| A website in mainland China still shows a local IP | This may be expected under direct-connection rules | Check which rules apply; don't switch to global mode right away |
| An international app fails, but the test page works | The test page and app may be using different routes | Check the app's rules, its own proxy settings, and any error messages |
| Different test pages show different IP addresses | Split tunneling, IP version, or multiple exits may be involved | Compare IPv4 and IPv6, then check the specific request |
Your device may have both IPv4 and IPv6 connectivity. Some tests show only one, while an app may prefer the other. If the client doesn't handle that traffic, a test can look normal even as some connections still go direct. First check the client's IPv6 support and routing policy; disabling a system feature isn't a universal fix.
Check DNS: focus on the lookup route, not just location
DNS translates domain names into IP addresses. That lookup is separate from the connection that follows. A DNS leak generally means a request that should use a specific DNS route instead went to an unexpected resolver. With split routing between direct connections in mainland China and international routes, using a local resolver for domains in mainland China isn't necessarily a problem. What matters is whether it matches your rules and privacy expectations.
DNS test pages typically trigger a lookup for a test domain and report the resolvers they observe. A resolver's listed location isn't your device's exit location, and it doesn't prove every app uses the same DNS. Resolvers may be distributed across locations, and the ISP or region shown by the page may be imprecise. Don't draw conclusions from the location label alone.
- Run a DNS test before connecting. Note the resolver configured on your system and the one observed by the test page.
- Run the test again after connecting. Check whether the client has enabled the expected DNS routing or interception rules.
- Check your browser's Secure DNS settings. The browser may use DoH to resolve domains separately from your system DNS.
- If the result isn't what you expected, close the target app and try again. If needed, clear the DNS cache as instructed by your operating system, then compare the results with the client's logs.
DoH sends DNS requests over HTTPS, but that doesn't automatically mean they go through the VPN. Their route is still determined by routing and split-tunneling rules. Likewise, a changed public IP doesn't prove DNS is handled as expected: app traffic may use an international route while DNS requests still use your local network.
Test each app: start a fresh session
After checking your browser, test the app you actually want to use. Long-lived connections may keep using an existing session after you switch routes, and changing client rules may not affect connections that are already open. Finish what you're doing, fully close the app, then reopen it and make a new network request. Don't rely on a cached home screen.
If your client provides connection logs, look for the target process, domain, matched rule, and exit route. If not, use the app's network diagnostics and perform a clear online action, then compare the results. Locally downloaded content, offline lists, and cached images don't prove that the network is working.
Why browsers and desktop apps may behave differently
A browser may have a separate proxy configured by an extension. A desktop app may ignore the system proxy or have its own proxy settings. The system proxy usually affects only software that honors it. A virtual network adapter can route more traffic at the network level, but routing and exclusion rules still apply. Enabling the system proxy alone doesn't mean every app is covered.
What to check on mobile and desktop
On Windows, macOS, or Linux, check the system proxy, virtual network adapter permissions, and the target app's own settings. On iOS or Android, check that the system connection profile is active, the operating system hasn't stopped the client, and the current mode supports the app routing you need. Features vary by platform and client, so check the actual settings in your app.
When testing apps in mainland China, confirm they still connect directly as expected and work normally. For international apps, check that new requests match the selected route. A service refusing access may be due to account region, service policies, or an outage; it doesn't by itself mean the VPN isn't working.
Common “fake connection” signs and how to troubleshoot them
A “fake connection” usually means the connection status doesn't match the route used by the app. It doesn't necessarily mean the client failed to establish any connection. Start by identifying the scope: is all internet access down, is just one app failing, or can the app connect but shows an unexpected exit IP? Each case calls for different checks.
- ❌ The test page shows a new IP, but the target app doesn't: Check whether the app honors the system proxy or is excluded from traffic routing.
- ❌ Nothing changes after switching routes: Close and reopen the target app to rule out an existing connection or cached data.
- ❌ Some domains aren't working: Check rule priority, DNS results, and the app's own Secure DNS settings.
- ❌ Multiple networking tools are running: Save your current settings, then check for proxy, virtual adapter, and routing conflicts one at a time. Avoid making several changes at once.
- ✅ Retest after changing networks: A different network can change DNS and routing, so don't rely on earlier test results.
If you still can't identify the issue, note when it happened, your platform and client mode, the route name, the app's error message, and what changed between tests. Before contacting support, redact account credentials, subscription links, and other sensitive information. Subscription links may contain access credentials, so don't share them in public screenshots or forums.
For more help, see Troubleshooting, or submit the details you've gathered through the support portal. Clear steps to reproduce the issue are more useful than “connected but not working.”
How to reach a verifiable conclusion
A useful test should record which app you tested, which rule it was expected to match, which exit route you observed, and whether DNS behaved as expected. Repeat the same process after changing networks, rules, or client versions to see what caused the difference, rather than guessing from the status icon each time.
Reliable evidence that split tunneling is working means new requests from international apps use the selected route, apps in mainland China connect directly as expected, and DNS follows the relevant rules. A “connected” status or a changed browser IP alone isn't enough to verify the full setup.
Finally, distinguish route checks from security assessments. VPN56 uses “military-grade encryption” as its primary security messaging, but IP and DNS tests can't verify how encryption is implemented or prove that a destination website is trustworthy. A correct route shows how traffic reaches its destination; you still need to check account security, website certificates, and device permissions separately.