VPN Connected but No Internet? 5 Fixes to Get Back Online

A VPN can show “Connected” while apps still cannot reach the internet. That status usually confirms that the client has started a local tunnel; it does not prove that the selected server, DNS settings, routing rules, or underlying network are working together. Start by checking whether the device can get online without the VPN, then test one change at a time. The five fixes below cover phones and computers and explain how to restore settings if a change does not help.

1. Check the base connection without the VPN

A VPN depends on the internet connection already provided by your Wi-Fi, Ethernet, or mobile network. If that connection is down, unstable, or restricted by a sign-in page, the VPN may remain in a connecting state or appear active while requests fail. Testing the base connection first prevents you from changing VPN settings to compensate for a router or carrier problem.

1. Disconnect the VPN using the client’s normal disconnect control. Do not force-quit the app yet.
2. Open a few ordinary websites or apps that do not depend on the VPN. If possible, test more than one site; a single site may be unavailable for unrelated reasons.
3. If you are on public Wi-Fi, open a browser and check whether the network requires a captive-portal sign-in. Complete that sign-in before reconnecting.
4. Switch between Wi-Fi and mobile data, or between Wi-Fi and Ethernet, if another connection is available. Try to keep the VPN disconnected during this comparison.

If apps still cannot connect with the VPN off, troubleshoot the local connection first: reconnect to Wi-Fi, check the router or access point, confirm that mobile data is enabled, and see whether the network requires a new login. A VPN cannot repair a failed internet connection. On a work or school network, access rules may also block VPN protocols; use only connections and services you are authorized to use, and ask the network administrator about permitted access rather than repeatedly changing client settings.

If the internet works normally without the VPN but stops as soon as you connect, the issue is more likely related to the selected route, DNS, client routing, or another proxy setting. Reconnect once and note what the client reports: a completed connection, a warning, or a connection that drops immediately. That distinction can help separate a traffic-routing problem from a tunnel that never established successfully.

2. Verify routing mode, rules, and app-level settings

Many clients support more than one routing mode. A global or “all traffic” mode attempts to send most device traffic through the VPN. Rule-based or split routing sends only selected apps, domains, or address ranges through it. A connected status can be genuine even if the app you are testing is excluded by a rule, or if the chosen mode is not the one you expected.

Open the client and confirm which mode is active. If the problem affects only one app, check whether that app is excluded from the VPN, assigned to a direct-connection rule, or placed in a different policy group. If no apps work, use the client’s standard routing mode as a temporary test, if available, and then retry a basic website. Avoid editing advanced routing rules until you have recorded or exported the current configuration; a small rule change can affect more traffic than intended.

On phones, check the operating system’s VPN settings as well as the client. Android may show a VPN key icon when the local VPN interface is active, but that icon alone does not confirm that remote traffic can reach its destination. Review per-app VPN or “exclude apps” settings if the client provides them. On iPhone or iPad, check whether another VPN profile or network-filtering app is enabled, and make sure you are testing the configuration that is currently selected in the client.

Desktop clients can also be affected by system proxy settings. On Windows, review the proxy section in Network & Internet settings and check whether a manual proxy was left enabled by another tool. On macOS, inspect the active network service’s proxy settings. Do not delete a proxy configuration just because it exists: some workplaces, development tools, and local applications rely on one. If you temporarily turn off a proxy for diagnosis, write down its values and restore them if the test does not help.

When choosing a service or client setup for travel, it is also useful to understand what the connection is intended to route and which configuration is active; the VPNRS VPN for China Travel information provides that broader context. For this issue, however, keep the diagnosis local: test one routing mode at a time and avoid changing the subscription or several policy rules together.

3. Refresh DNS and check filtering features

DNS translates a domain name into the address a device uses to contact a service. A VPN client may use DNS supplied by its configuration, send DNS requests through the tunnel, or work alongside DNS settings controlled by the operating system. If name resolution fails, apps may look offline even though the device can reach the network. A DNS problem often affects domain names more noticeably than an app’s connection indicator, but symptoms vary by client and operating system.

Begin with reversible actions. Disconnect and reconnect the VPN, then fully close and reopen the affected app. If the problem continues, toggle the device’s Wi-Fi connection off and on, or restart the network connection using the operating system’s normal controls. Restarting the device can clear a stale local network state, but record any custom DNS or proxy settings before doing so if you will be changing them as part of the test.

Next, review DNS-related options in the VPN client. Features may be labeled DNS protection, secure DNS, custom DNS, ad blocking, or domain filtering. Temporarily disable one optional filtering feature at a time, reconnect, and test the same app or site. If the connection works after a specific feature is disabled, that points to a configuration or compatibility issue; it does not prove that DNS filtering is generally faulty. Restore the option if it was not responsible.

On Android, Private DNS is a separate system setting from the VPN client’s own DNS configuration. If it is set to a custom provider, temporarily return it to the device’s automatic setting for a comparison, then reconnect and test. Restore the original selection if there is no improvement. On Apple devices, check for a DNS profile or content-filtering app installed separately from the VPN. On Windows and macOS, custom DNS can be set on the network adapter or service; note the current values before changing them, and prefer restoring the previous automatic or custom setting over guessing replacement addresses.

A useful test is to compare more than one destination. If one application fails but ordinary browsing works, the cause may be that app’s DNS cache, proxy configuration, or access policy rather than the whole VPN route. If domain-based services fail broadly while the client remains connected, DNS becomes a stronger possibility. Do not share private DNS profiles, account credentials, or full configuration files in public support posts; they can contain information that should remain private.

4. Check for another VPN, proxy, or network filter

Two network tools can compete to control the same traffic. Examples include a second VPN app, a proxy client, a firewall with filtering rules, a DNS-filtering utility, or a security product that installs a network extension. One tool may own the system VPN interface while another changes the device proxy or DNS settings. In that situation, the first client may show a connection even though apps are following a different route.

Close or disconnect other network-routing apps using their normal controls, then reconnect only the VPN you are testing. On Android and iOS, look for another active VPN profile in system settings. On Windows, check for other proxy or tunneling utilities and review whether a system proxy is enabled. On macOS, inspect active VPN connections, network filters, and proxy settings for the current network service. The exact menu names depend on the operating system version and the apps installed.

Do not uninstall security software or remove a work-managed profile simply to test this. Instead, disable only an optional feature when you understand what it does and are allowed to change it. If a managed device is involved, ask its administrator before changing filters or profiles. If two compatible clients are intentionally being used together, consult their documentation: some arrangements require a specific order or routing mode, while others cannot share the same system VPN interface.

• ✅ Disconnect other VPN or proxy clients before testing the selected client.
• ✅ Change one DNS, filtering, or routing option at a time and retest the same destination.
• ✅ Record original proxy and DNS values before temporarily changing them.
• ❌ Do not run multiple tunnel clients at once unless both providers document that setup.
• ❌ Do not delete work, school, or security profiles that you do not own or manage.

If disabling a competing tool restores access, re-enable tools one at a time to identify the conflict. You can then decide which tool should handle the traffic, or ask the relevant provider or administrator how to configure them together. If nothing changes, restore the settings you altered before moving on. Leaving diagnostic changes in place can create a new problem later, especially if the device relies on a custom proxy or DNS resolver for other tasks.

5. Try another server, then reconnect with a clean client state

A particular server or route can be temporarily unreachable from one network, or the route may not work well with a specific destination. This does not necessarily mean the account or device is broken. In the VPN client, select another available server or route and reconnect using the client’s normal controls. If the client has automatic selection, compare that choice with a manually selected option. Avoid repeatedly switching options without waiting for each connection attempt to finish; otherwise, it becomes difficult to tell which route was actually tested.

After changing the server, test the same destination you used earlier. If only one route fails and another works, report that distinction to the provider. If every route fails but the base connection is healthy, continue with a clean restart of the client. Disconnect, close the app normally, reopen it, and connect again. On a phone, check whether battery-saving restrictions are suspending the client in the background; on a computer, confirm that the app has permission to manage its network connection. Do not clear app data or remove a profile until you know how to retrieve the correct configuration again.

Subscription-based clients and compatible third-party clients do not all handle configuration updates in the same way. If you use a subscription link, refresh it through the client’s documented update function and check whether the configuration has an expiry or update warning. Do not paste the subscription address into a public forum or send it in an unprotected message: it may grant access to account-specific configuration. When using a third-party client such as Clash Verge, sing-box, or Shadowrocket, confirm that the subscription format is supported, that the intended profile is selected, and that the client’s system VPN permission has been granted.

Protocol settings can also affect whether a route works on a particular network. A client may offer protocols such as Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard, but the available choices depend on the service configuration and compatible client. Do not replace protocol fields with guessed values. If the service provides more than one supported option, test only a documented alternative and return to the original setting if it does not help. A protocol mismatch or incomplete configuration may prevent traffic from passing even when the app interface looks active.

Some clients include a kill switch or “block connections without VPN” option. This feature may intentionally prevent traffic from using the ordinary network whenever the VPN is disconnected or has not completed its route. If the client is reporting a failed connection, the kill switch can make the device appear completely offline. Check the feature’s description before changing it. If you turn it off temporarily for diagnosis, do so only when you understand that traffic may use the regular network, and turn it back on if that is your intended privacy setting.

When to contact VPN support

Contact the provider if the base internet works, competing tools have been ruled out, and the issue continues across the documented connection options. Include the operating system and version, client name and version, the network type you tested, the selected route, and the approximate time the failure occurred. Describe whether all apps fail or only particular ones, and whether the problem changes when the VPN is disconnected. These details help support staff distinguish a local configuration issue from a route or account problem.

Share only what is necessary through the provider’s official support channel. Do not send your password, payment details, or a complete subscription URL unless the provider has a secure, documented process that specifically requires it. If you changed system proxy or DNS settings during testing, mention what you changed and whether restoring the original values affected the result. Avoid posting screenshots that reveal account identifiers, private addresses, or configuration secrets.

Before finishing, restore any temporary DNS, proxy, filtering, or kill-switch changes that did not solve the problem. Keep the one change that helped only if you understand its effect and want to use it. A clear record of the original and tested settings makes it easier to undo a failed experiment and gives support a useful starting point.