VPN Connected but No Internet? Fix It Fast With 5 Checks

A VPN can appear connected while browsers and apps still fail to reach the internet. This usually means the encrypted tunnel was created, but traffic is being blocked, misrouted, or sent to a DNS or proxy service that cannot answer. The problem may come from the local device, the Wi-Fi network, the VPN client, or the selected server route. Reconnecting repeatedly without checking these layers often changes nothing.

The fastest approach is to test one layer at a time. First confirm whether the device has internet without the VPN. Then check DNS, system proxy settings, routing mode, Wi-Fi restrictions, and the selected protocol or server. The instructions below apply broadly to official Windows, macOS, Android, iOS, and Linux clients, as well as compatible tools such as Clash Verge, sing-box, and Shadowrocket.

Start with a simple control test

Before changing advanced settings, disconnect the VPN and open two unrelated websites or apps. If nothing works without the VPN, the VPN is probably not the main cause. Restart the Wi-Fi connection, check whether other devices on the same network can browse, and confirm that the operating system has received an IP address, gateway, and DNS server. A captive portal at a hotel, airport, school, or café may also require you to sign in before a VPN can work normally.

Next, reconnect the VPN and compare the result. If the normal connection works but the VPN connection does not, note the exact symptom. A browser that reports a DNS error points in a different direction from an app that times out. If only one application fails, the application may be using its own proxy, DNS-over-HTTPS setting, firewall permission, or network policy. If every application fails, inspect the VPN client and operating-system network settings first.

Do not change several settings at once. Make one change, reconnect, and test the same website or app. This keeps the diagnosis understandable and makes it easier to undo an unsuccessful change.

Check DNS resolution

DNS translates a domain name such as a website address into an IP address. A VPN may establish a tunnel successfully while DNS requests continue to use an unreachable local resolver, a blocked resolver, or a resolver that is incompatible with the client’s routing mode. In that situation, the connection indicator looks healthy, but browsers may display messages such as “DNS_PROBE_FINISHED,” “server not found,” or an equivalent name-resolution error.

Start by checking whether the problem affects domain names only. If your operating system or browser provides a network diagnostic tool, compare a domain lookup with a connection to an already known IP address. You do not need to rely on a particular command for the first diagnosis; the important distinction is whether name resolution fails before the connection is attempted. Avoid treating an IP address test as proof that normal browsing will work, because modern websites often depend on domain names, certificates, and multiple related services.

In the VPN client, look for settings named DNS, remote DNS, encrypted DNS, fake-IP, redir-host, or DNS hijacking. The exact names differ between official clients, Clash Verge, sing-box, and other compatible clients. A fake-IP mode can be useful when the client’s DNS and routing rules are designed for it, but it can produce failures when mixed with an incompatible rule set or another DNS application. If you recently imported a configuration, the DNS mode may have changed even though the server list looks normal.

Try these changes in a controlled order:

• ✅ Disconnect other DNS-changing applications, browser-level DNS tools, and local filtering software temporarily.
• ✅ Enable the VPN client’s recommended remote DNS option if the client provides one.
• ✅ Restart the client after changing DNS mode so its virtual adapter and resolver rules are recreated.
• ✅ Clear the operating system or browser DNS cache when an old failed result may be retained.
• ❌ Do not configure several unrelated DNS tools at the same time and assume they will cooperate.

On Windows, inspect the active adapter and confirm that the VPN’s virtual adapter is not disabled. On macOS, review the active network service and any custom DNS entries. On Android and iOS, check whether Private DNS, an encrypted DNS profile, or a content-filtering profile is competing with the VPN. Linux users should also consider NetworkManager, systemd-resolved, and a locally installed resolver. The correct setting depends on the client’s tunnel mode, so copying a desktop DNS recipe to a mobile device may make the problem worse.

Check proxy and routing conflicts

A VPN client may use a virtual network interface, a system proxy, or both. A second proxy application can intercept the same traffic and send it to a port that is no longer listening. This is common after switching between an official client and a third-party client such as Clash Verge, sing-box, or Shadowrocket. The VPN indicator may remain active because its tunnel is valid, while applications are still trying to use an old local proxy.

Open the operating system’s proxy settings and compare them with the current client mode. On Windows, check the system proxy and automatic configuration script. On macOS, inspect HTTP, HTTPS, and SOCKS proxy entries for the active network service. On Android and iOS, review the Wi-Fi network’s proxy setting and any installed VPN or filtering profile. Linux users should check desktop proxy settings as well as environment variables used by command-line tools. A browser can also have independent proxy settings, so inspect it if only that browser is affected.

There is an important difference between a VPN tunnel and a local proxy. A tunnel mode can route traffic through a virtual adapter without requiring each application to know a proxy address. A local proxy mode requires applications to send traffic to a local listening port. If that port is wrong, blocked, or already occupied, the client may appear connected while applications have no usable path. Do not manually enter a random proxy port; use the value shown by the active client and remove obsolete entries when changing tools.

Routing rules create another possible conflict. Rule-based clients can direct some domains to a proxy, some to the local connection, and others to a rejected or unavailable group. A mistaken rule may make one app fail while ordinary websites continue to work. Global mode is useful as a diagnostic test because it temporarily reduces rule complexity. It should not automatically be treated as the best permanent configuration, especially when local services, banking applications, printers, or corporate resources need to remain on the direct route.

Identify the active client

Use only one traffic-routing client at a time during troubleshooting. Quit the others completely rather than merely closing their windows, because background services may continue to own a virtual adapter or proxy port. If an official client and a compatible client both installed profiles, remove or disable the unused profile temporarily. Afterward, reconnect the remaining client and test before importing a new configuration.

For a subscription-based configuration, verify that the client supports the delivered format. A subscription containing Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard entries cannot be assumed to work identically in every application. The client must support both the protocol and the transport parameters used by that entry. An imported server can appear in the list even when a particular feature is unsupported, so a visible entry is not proof of compatibility.

Perform the five-minute repair sequence

Once the basic cause is understood, use this sequence instead of changing settings randomly. It is suitable for a desktop or mobile device, although menu names differ by operating system.

1. Disconnect the VPN. Confirm that ordinary internet access works and complete any captive-portal login required by the network.
2. Close competing clients. Quit official and third-party routing tools that are not part of the current test. Disable unused VPN, proxy, filtering, or DNS profiles temporarily.
3. Reconnect one client. Use its default or recommended mode first. Do not begin with a complicated custom rule set.
4. Test DNS and browsing. Open a fresh private browser window and try more than one unrelated domain. This helps separate cached browser data from a network failure.
5. Change only one route. If the connection fails, select another available server or route, then reconnect. A single entry may be temporarily unavailable even when the client and account are working.
6. Try a different protocol. If the client supports several protocols, test the documented alternatives one at a time. Keep the configuration that works on the current network and device.
7. Restore normal settings. Remove temporary global mode, test DNS entries, or manual proxy values that are no longer needed. Confirm that local services still behave as expected.

On mobile devices, also toggle airplane mode briefly or restart the network connection after changing a VPN profile. Android may display a warning when another VPN profile is active, while iOS generally allows only one active VPN connection through the system framework. On desktop systems, a full restart can clear a stuck virtual adapter, but restarting should follow configuration checks rather than replace them.

Keep a short note of the original settings before editing them. For a manually managed sing-box or Clash Verge configuration, save a backup of the working file. For an official client, record the selected mode, DNS option, and server name. This prevents a troubleshooting session from becoming an irreversible configuration rewrite.

Check Wi-Fi, firewall, and network restrictions

Some networks permit ordinary web traffic but interfere with particular VPN transports, UDP packets, encrypted DNS, or long-lived connections. Public Wi-Fi networks may also isolate devices, require browser authentication, or block traffic until their terms page is accepted. If the VPN works on mobile data but not on Wi-Fi, the local network is an important clue. If it works on Wi-Fi but not on mobile data, inspect mobile carrier restrictions, data-saving settings, and the mobile VPN profile.

Test the same client on a different network when possible. This does not prove that the first network is intentionally blocking the connection, but it separates device configuration from network behavior. Record whether the failure occurs during connection establishment or only after the connection indicator appears. A handshake failure points toward protocol, transport, credentials, or firewall issues. A successful handshake followed by total loss of internet access points more strongly toward DNS, routing, or proxy conflicts.

Local security software can also block the virtual adapter. Check whether a firewall, endpoint security product, parental-control tool, or traffic filter recently changed its rules. Do not permanently disable security software just to make the VPN work. Instead, use its event log to determine whether the VPN application, virtual adapter, DNS process, or local proxy was denied permission. On Linux, firewall rules and policy routing can survive a client restart; inspect them if the problem began after installing another networking tool.

Wi-Fi power-saving features and background restrictions matter on mobile devices. Android may suspend a client when battery optimization is aggressive, while iOS can interrupt or delay background network activity when an app is not active. These settings usually cause intermittent access rather than a constant failure, but they are worth checking when the VPN works briefly and then stops.

• ✅ Complete the Wi-Fi sign-in page before connecting the VPN.
• ✅ Compare Wi-Fi and mobile data to identify whether the network is the variable.
• ✅ Review firewall logs instead of permanently disabling protection.
• ✅ Allow the client to run in the background when mobile restrictions interrupt it.
• ❌ Do not assume that a successful connection indicator means every transport is permitted.

Check protocol, server, and client compatibility

If DNS and proxy settings look correct, the selected server or protocol may not suit the current network. Protocols have different transport behavior. Shadowsocks, VMess, and Trojan are commonly delivered through compatible proxy clients with specific server and transport parameters. Hysteria2 relies on a different transport design and may behave differently on networks that handle UDP unusually. WireGuard uses its own key and interface model and must be supported by the client and configuration. The name alone is not enough; the client must understand the complete entry, including transport, encryption, authentication, and routing parameters.

Try another server from the same provider before editing advanced fields. A route can be unavailable, congested, misconfigured, or unsuitable for the current access network. If several routes fail in the same way, the issue is more likely local configuration or protocol compatibility. If only one route fails, remove it from the immediate test and continue with a known supported entry.

Subscription updates can also introduce changes. A provider may replace addresses, certificates, ports, or transport parameters while keeping a familiar server name. Refresh the subscription through the client’s normal update function, then check whether the client reports an import or parsing error. Do not paste a subscription link into a browser, a generic text field, or an unsupported client and expect it to produce a usable connection. Treat the link as sensitive account information and do not share it publicly.

When using Clash Verge or sing-box, verify that the configuration’s rule engine, DNS mode, and selected outbound group agree with one another. When using Shadowrocket on iOS, confirm that the imported node format and local routing rules are supported by the current version. With official desktop or mobile clients, begin with the recommended automatic mode, then test documented protocol alternatives. Advanced settings are useful when the default path fails, but they are harder to diagnose if several values are changed together.

Know when to reset and when to seek help

A clean reset is reasonable when the client has stale profiles, duplicate virtual adapters, corrupted local state, or rules left behind by an older configuration. Before resetting, export or record any settings you may need. Remove the unused profile, restart the device, install or open the supported client, and import the configuration again through the normal process. Reinstalling without removing conflicting profiles may leave the original problem untouched.

Do not reset immediately if only one website or one application fails. First test another browser, clear that application’s own proxy and DNS settings, and check whether the service is available without the VPN. Some apps reject connections from particular locations, require their own login flow, or use certificate and network checks that ordinary browsers do not use.

If you contact support, provide useful diagnostic information without exposing credentials. Include the operating system, client name and version, whether other networks were tested, whether the failure occurs with and without the VPN, the selected protocol, and the exact error message. You may also mention whether DNS, global mode, another server, or a fresh subscription update changed the result. Never send a subscription link, password, private key, or full configuration containing account tokens in a public channel.

The most reliable troubleshooting habit is to separate connection status from usable internet access. A green indicator confirms only that one part of the setup completed. DNS, proxy routing, firewall policy, Wi-Fi behavior, protocol support, and application rules must still agree. Work through the five checks in order, make one change at a time, and restore temporary diagnostic settings after the test. In most cases, this turns an apparently mysterious “connected but offline” problem into a specific setting that can be corrected.