A VPN can show “Connected” while an app remains stuck on a loading screen, fails to sign in, or reports that it cannot reach the internet. The status usually confirms that a tunnel was established; it does not prove that every app is using that tunnel, that name resolution is working, or that the destination service is responding.
Work through the checks in order: confirm which connection the affected app uses, review its permissions and proxy settings, then test DNS, protocol, and route selection. Change one thing at a time and retest the same app. This makes it easier to identify the cause and undo a change that did not help.
Identify where the connection breaks
First, note exactly what “won’t open” means. An app that closes immediately points to a different problem from one that opens but spins indefinitely, displays a sign-in error, or cannot load only certain pages. Record the app name, device, operating-system version, VPN client, selected route, and the time the issue began. If the problem started after an app or operating-system update, include that detail when you investigate.
Check whether the affected app fails only while the VPN is connected. Disconnect the VPN briefly and try the same action on a trusted network. If the app works without the VPN, the difference is useful evidence, but it does not identify the cause by itself: routing, DNS, a proxy setting, an app restriction, or the destination service could all be involved. If the app still fails with the VPN disconnected, troubleshoot the app, device, or local network first.
Next, compare more than one destination. Try opening a page in a browser, then test a second app that uses the network. If only one app fails, focus on its own settings, traffic rules, and service status. If several unrelated apps fail, investigate the device’s VPN route, DNS configuration, and network permissions. A browser test is not conclusive: browsers and other apps can use different proxy settings or network stacks.
4
connection layers to check
1
change per retest
5
supported platform families
2
VPN states to compare
Think of the path as four layers: the app’s route selection, the device’s VPN permission and tunnel, DNS lookup, and the destination’s response. A “connected” indicator is evidence about the tunnel, not a guarantee that all four layers are healthy. Keeping this distinction in mind prevents repeatedly reinstalling an app when its traffic is simply bypassing the VPN.
Check split tunneling and app permissions
Split tunneling lets a client include or exclude selected apps or destinations from the VPN route. A rule can be intentional, left over from an earlier setup, or changed during an update. Open the VPN client’s routing, app filter, or split-tunneling settings and look for the affected app. Menu names differ by client, so check the client’s own documentation if the option is not obvious.
If the app is excluded, it may be trying to connect over the ordinary network while you expect it to use the VPN. If it is included but still cannot connect, temporarily switch to a broader routing mode for a controlled test, if the client offers one. Do not change several routing rules at once. After each adjustment, fully close and reopen the app; some apps keep existing network sessions until they are restarted.
On Windows and macOS, confirm that the client is allowed to create or manage a VPN connection, and approve a system prompt only when it matches the client you intentionally installed. On Android and iOS, review the system VPN permission and any per-app VPN or network controls exposed by the client or device. The names and locations of these settings vary by operating-system version. Avoid removing unrelated security permissions simply to see whether the app starts.
Also check for a second network tool. Another VPN, proxy app, firewall, endpoint-security product, or manually configured proxy can compete with the client for traffic. If two tools are active, turn off one at a time using its normal controls, then reconnect and test. Do not disable a firewall globally as a first step; if a firewall rule appears relevant, inspect the specific app or VPN-client rule and restore the previous setting if the test makes no difference.
If you use Clash Verge, sing-box, Shadowrocket, or another compatible client, check both the active profile and its routing mode. Importing a subscription does not necessarily select the profile you expect, and a rule-based configuration can send different apps or domains through different outbound routes. Confirm that the app is matched by the intended rule and that the selected outbound is available. Do not assume that a “global,” “rule,” or “direct” label has identical behavior in every client.
- ✅ Confirm whether the affected app is included in or excluded from the VPN route.
- ✅ Restart the app after changing its routing or permission settings.
- ✅ Test with only one VPN or proxy client active.
- ❌ Do not erase every network or security setting before identifying a likely cause.
Follow a controlled retest sequence
Use a short, repeatable sequence rather than changing settings at random. This is especially helpful when the app fails intermittently or when a device has several network tools installed. Before starting, note the current route and client settings so you can restore them. If you rely on a work-managed device or network, follow its administrator’s rules instead of changing managed configuration.
- Close the affected app completely. On a computer, quit it rather than leaving it in the background. On a phone or tablet, close it using the operating system’s normal app controls. Reopen it only after the VPN has finished connecting.
- Check the basic route. Confirm the VPN client shows an active connection and that the intended profile or route is selected. If the client has a built-in connection or DNS test, use it as a diagnostic, not as proof that every application will work.
- Test a browser and a second app. Compare the affected app with a browser and another network-dependent app. Note which ones work and whether the failure affects all destinations or only one service.
- Switch one variable. If the client supports multiple routes, choose a different available route and reconnect. Keep the same device, app, and test action. If the result changes, record the selected route rather than repeatedly switching without notes.
- Restore and compare. If the change does not help, return to the original setting before trying a different diagnostic. This keeps the test interpretable and reduces the chance of leaving the device in an unknown configuration.
When reviewing service information or setup guidance, use the official site rather than an unverified mirror; the VPN61 VPN for China Travel homepage is one starting point for finding the service’s own information. This does not mean that a particular app or destination is guaranteed to work through every route. The app’s requirements, the current network, and the selected client configuration still matter.
For a useful test record, write down the operating system, client name and version, connection mode, selected route, whether split tunneling is enabled, and the exact error or screen behavior. Include whether the same app works with the VPN disconnected. These details help separate a client-side routing issue from an app outage and make support requests more actionable.
Troubleshoot DNS, protocol, and routes
DNS translates a service name into the address a device needs to connect. If the app cannot resolve a name, it may show a generic network error or remain on a loading screen even while the VPN tunnel appears connected. Check whether the VPN client has a DNS option, whether the operating system has a manually configured DNS or encrypted-DNS setting, and whether another privacy or filtering app changes DNS behavior.
For diagnosis, use the VPN client’s documented DNS settings and change only one setting at a time. If the operating system or a separate app provides custom DNS, note the current value before testing a different configuration. Reconnect the VPN and restart the affected app after a change. Avoid copying DNS addresses from random posts: an address may be unavailable, inappropriate for your network, or unrelated to the failure.
Protocol settings can also affect whether a connection remains usable on a particular network. Clients may support different protocols or transports, but their availability and behavior depend on the client version, service configuration, and network. If the client offers another documented option, test it as a controlled comparison and then return to the preferred setting if there is no improvement. Do not treat a protocol name as a guarantee of speed, compatibility, or access to a specific service.
Try a different route only after checking app routing and DNS. A route change can help determine whether the problem is limited to a particular path, but it can also change the connection conditions and make a test harder to compare. Record the route name, reconnect cleanly, and test the same app action. If a browser works but an app does not, that difference still points toward app-specific proxy behavior, routing rules, or service-side requirements rather than proving that the entire VPN is working perfectly.
| Observed behavior | Check first | Useful next test |
|---|---|---|
| Only one app fails | App-specific routing, proxy, permissions, or sign-in state | Restart the app and compare its route with a browser |
| Several apps fail | VPN permission, active profile, DNS, or competing network tools | Test with one client active and review DNS settings |
| App works without VPN | Split tunneling, route selection, DNS, or protocol compatibility | Change one client setting and repeat the same action |
| App fails in both VPN states | App update, account state, device connectivity, or service status | Check the app’s own diagnostics and test another network if available |
Do not infer that a service is down from a single failed attempt. A destination can reject a connection, require a fresh sign-in, or be temporarily unavailable independently of the VPN. Check the app provider’s service notices or support information through a connection you trust, and note whether the problem is limited to one account, feature, or destination.
Device-specific checks and when to escalate
Windows and macOS
On Windows, confirm the VPN client is permitted by the system and that the intended profile is active. Review any app-specific proxy configuration in the affected app; a manually set proxy can point somewhere different from the system route. If a network adapter or filter driver was recently installed or updated, record that change and consult the client’s support instructions before removing components. On macOS, check whether the client’s VPN configuration is enabled in system settings and whether the operating system displayed a permission prompt that still needs approval. Quit and reopen both the VPN client and the affected app after a controlled configuration change.
Android and iOS
On Android, check the system VPN indicator and verify that the client has not been paused or excluded by a per-app rule. Battery or background restrictions can affect whether some apps remain active, so review the operating system’s app-specific controls without broadly disabling device protections. On iOS, confirm the VPN profile is enabled and that any on-demand or per-app behavior matches the intended setup. If the app uses its own proxy or private DNS option, compare that setting with the client’s documented configuration.
Linux and compatible clients
On Linux, check which client or network manager owns the active connection and whether a second tool has changed routes or DNS resolution. Desktop environments, distributions, and resolver setups differ, so prefer the documentation for the specific client and distribution. If a compatible client imports a subscription, verify that the imported profile is selected, its configuration has loaded, and the app’s traffic matches the relevant routing rule. A successful import only confirms that configuration data was accepted; it does not establish that every rule or outbound is suitable for the affected app.
Escalate when the issue persists across a clean reconnect and a documented alternate route or setting, or when the client shows a specific error that you cannot interpret. Provide the device and operating-system version, client and version, route or profile name, connection mode, exact error text, and the tests already performed. Remove account identifiers, subscription URLs, passwords, tokens, and other private values from screenshots or logs before sharing them. If the issue affects a work or school device, ask its administrator before changing managed network settings.
Reinstalling should not be the first step. It can remove useful configuration evidence, and it will not fix a destination-side outage or an app’s own proxy rule. If you do reinstall after following the client’s official instructions, first note any settings you need to restore and obtain the installer from a trusted source. Afterward, reconnect with a known profile, test a browser and the affected app separately, and reintroduce custom rules only when the basic setup works.