If your VPN connects on mobile data but fails on Wi-Fi, the VPN account and app may be fine. The difference is the network path: Wi-Fi adds a router, local DNS settings, and sometimes a captive portal or firewall that can interfere with the tunnel. Start by checking whether the Wi-Fi itself works, then isolate the client, device, and router before changing connection settings.
Make one change at a time and repeat the same test after each change. Note whether the app cannot connect, connects but has no internet access, or works in some apps but not others. Those symptoms point to different causes. Avoid resetting the router or changing several security settings at once; doing so can erase useful clues and disrupt other people using the network.
Identify where the Wi-Fi connection fails
First, disconnect the VPN and check that the device can open ordinary websites over Wi-Fi. If it cannot, troubleshoot the Wi-Fi connection itself: reconnect to the network, check whether other devices can browse, and see whether the router or internet service is down. A VPN cannot repair an unavailable internet connection.
Next, connect the VPN and observe the exact result. A client that stays on “connecting” may be unable to reach its server through the network. A client that reports “connected” while pages fail may have a DNS, routing, or traffic-filtering problem. If only one app fails, check its proxy settings, VPN exclusions, and local firewall rules before treating the whole connection as broken.
If the Wi-Fi is public, shared, or newly joined, open a browser with the VPN disconnected and complete any sign-in or acceptable-use page first. A captive portal may block normal internet access until you accept its terms. Once the page confirms access, reconnect the VPN. Do not enter sensitive account details into a sign-in page unless you have confirmed that it belongs to the venue or network operator.
Compare more than one Wi-Fi network if possible. If the VPN works on a home network but not at work, school, a hotel, or a café, the difference is likely to be a network policy or router configuration. When you are evaluating what connection setup suits a trip, the VPN for China Travel home page is a useful starting point; it does not replace checking the rules and connectivity of the network you are currently using.
| What you observe | Likely area to check | First useful test |
|---|---|---|
| Wi-Fi fails with the VPN off | Router, access point, captive portal, or internet service | Check another device and reconnect without the VPN |
| VPN stays on connecting | Network filtering, blocked transport, client settings, or server reachability | Try another Wi-Fi network, then a different supported connection option |
| VPN says connected, but nothing loads | DNS, routing, MTU, or a conflicting proxy | Test a second website and check the client’s traffic mode |
| Only one app is affected | App-specific proxy settings, exclusions, or firewall rules | Test the same destination in another browser or app |
Rule out device and client conflicts
Before changing router settings, close and reopen the VPN client, confirm that it is up to date, and check that the device has the correct date and time. An incorrect clock can interfere with secure connections. If the device recently woke from sleep, changed networks, or moved between access points, disconnect and reconnect the tunnel rather than assuming its old session is still usable.
Look for other software that can intercept traffic. A second VPN, proxy app, antivirus web filter, endpoint security tool, firewall, or manually configured system proxy may compete with the VPN client. Disable or quit only the suspected competing feature for a brief test, if you are allowed to do so, then restore it. Do not leave device protection disabled as a workaround.
Check the client’s mode and exclusions. A system proxy, browser-only proxy, and TUN or virtual-network mode do not necessarily route the same traffic. Rule-based routing may intentionally send some destinations outside the tunnel. If the client shows a connected status but only selected apps fail, review whether those apps are excluded or whether the current mode covers their traffic. Do not assume that importing a configuration automatically selects the mode you intended.
- ✅ Test Wi-Fi with the VPN disconnected before changing VPN settings.
- ✅ Confirm there is only one active VPN or proxy controlling the device.
- ✅ Check app exclusions, system proxy settings, and the client’s traffic mode.
- ❌ Do not delete a working profile or reset all network settings before recording the current configuration.
- ❌ Do not install an unknown certificate or configuration profile to “fix” a connection.
On Windows, check the system proxy under Network & Internet settings, then review whether a firewall rule or security product is blocking the client. If you restart the network adapter, expect active network sessions to drop. Use broad network-reset options only after simpler checks, since they can remove saved connections or require adapters and settings to be configured again.
On macOS, check System Settings for VPN connections, network filters, and proxy settings, and make sure you have approved any permissions the client requested. If another VPN or filtering extension is active, test with only the intended client enabled. On Android, review Always-on VPN and “block connections without VPN” settings: lockdown can make a failure look like Wi-Fi has no internet. On iPhone or iPad, check for another VPN or management profile and reconnect after joining a network that uses a sign-in page.
On Linux, confirm that the client’s service is running and that another network manager, firewall rule, or proxy environment variable is not taking precedence. If you use a compatible third-party client, verify that it supports the subscription format and the specific protocol and transport parameters in the imported configuration. A successful import alone does not prove that every node or feature is supported.
Check router, DNS, and network restrictions
If several devices show the same Wi-Fi-only failure, the router or network is a stronger suspect. Rebooting the router can clear a temporary fault, but first check whether other users depend on it and whether the problem affects all devices. If you manage the router, review recent changes to parental controls, access-control lists, security filters, custom DNS, or traffic-shaping rules. A guest network can also apply different restrictions from the main network.
Some networks block or interfere with particular traffic types, including UDP, or restrict unfamiliar encrypted connections. This can prevent a client from reaching a server even while ordinary browsing works. If the client offers multiple supported protocols or transports, try another option that is actually listed in the client or service documentation. Change one option at a time, reconnect, and restore the original setting if the result is worse. No protocol is guaranteed to work on every managed network.
DNS is another common source of “connected but nothing loads.” A network may supply DNS settings that conflict with the client, or a device may have a private DNS or encrypted-DNS setting that changes name resolution. Compare access to a site by its normal domain with access to other known-working domains; do not treat a single site failure as proof that the whole tunnel is down. If the client has a DNS option, use documented settings and avoid entering an unfamiliar resolver address.
IPv6 behavior can also differ between a router, device, and VPN client. Some clients route IPv4 and IPv6 traffic differently, while some networks provide only one path reliably. Check the client documentation for its IPv6 handling and use its supported settings rather than applying a system-wide workaround without understanding the effects. Similarly, a low MTU or path-MTU issue can allow a connection to establish while larger packets or some sites fail. If the client offers an MTU setting, adjust it only as a documented troubleshooting test and change it back if it does not help.
Router settings vary, so avoid copying DNS, port-forwarding, or firewall instructions meant for a different model. Do not disable the router firewall as a general test. If you cannot administer the network, collect the error message, the time of the attempt, and whether the same device works on another Wi-Fi connection; that information is more useful to the network operator than a vague report that the VPN is “broken.”
Change server or protocol only after basic checks
Once ordinary Wi-Fi access works and obvious local conflicts are ruled out, try a different server or route provided by the service. A particular server may be temporarily unreachable from that network, while another route may connect. Keep the test controlled: switch the server first, test, and then consider a protocol or transport option if the client supports it. Avoid changing server, protocol, DNS, and routing mode together, because you will not know which change mattered.
When comparing routes, use the same device, Wi-Fi network, app, and destination. Check both whether the tunnel connects and whether the traffic you care about actually passes through it. A connection indicator alone does not confirm that all apps use the tunnel. If a route works only on mobile data, report that detail to the provider along with the client version, operating system, Wi-Fi type, selected route, and exact error text. Do not include passwords, private keys, or an unredacted subscription link in a public support request.
If you use Clash Verge, sing-box, Shadowrocket, or another compatible client, confirm that the profile was refreshed and that the selected node is enabled. Check whether the client is in rule, global, or direct mode, and inspect DNS and TUN settings only when the client documentation explains their effect. Names and controls differ between apps, and a setting from one client may not have an equivalent in another.
Frequently asked questions
Why does the VPN work on mobile data but not home Wi-Fi?
The two connections use different routers, DNS settings, and network policies. Your home router may have a filter or custom DNS setting that affects the tunnel, or the client may need to reconnect after the network changes. Test the VPN on Wi-Fi with it disconnected first, then compare another device on the same router. If only one device fails, focus on that device’s client, proxy, firewall, or VPN settings.
The VPN says connected, but websites do not load. What should I check?
Test more than one website and, if possible, more than one app. Check DNS settings, rule-based routing, app exclusions, and whether another proxy or network filter is active. If the client has a documented DNS or IPv6 option, test one supported change at a time. If only a particular site fails, the issue may be specific to that destination rather than the whole VPN connection.
Should I turn off my router firewall to make the VPN work?
No. Turning off the firewall can expose every device on the network and is not a safe general fix. Review permitted settings such as parental controls, custom DNS, or guest-network restrictions if you administer the router. Otherwise contact the network administrator or internet provider with the error and test results.
When should I contact VPN support?
Contact support after confirming that Wi-Fi works without the VPN, checking any captive portal, restarting the client, and testing a second permitted route or network where possible. Include your operating system, client name and version, selected protocol or transport, the type of Wi-Fi, and the exact error. Remove passwords, account secrets, private keys, and subscription links before sending logs or screenshots.