A VPN can show “Connected” while every browser tab, app, or system service remains offline. This usually means that the encrypted session was established, but traffic is being blocked, misrouted, or sent to a DNS or proxy setting that cannot complete the request. The client status alone is not enough to prove that internet access is working.

This guide presents seven quick checks for Windows, macOS, Android, iOS, and Linux. The order matters: begin with the simplest distinction, then inspect the client, system proxy, DNS, permissions, routing mode, and server choice. Change one setting at a time so that you can identify which adjustment actually fixes the problem.

Check 1: Confirm the client and subscription are actually ready

A connected label can describe several different states. Some clients complete the server handshake but do not enable the system proxy. Others connect to a profile whose server address is no longer valid, or load an empty configuration after a subscription update. Before changing operating-system settings, inspect the client itself.

Open the route or profile list and confirm that at least one usable profile is present. If you imported a subscription link, look for an explicit update result, the last update time, and the number of profiles received. A subscription link is a configuration source rather than a normal webpage address. If the client reports a parsing error, authorization failure, expired access, or an empty result, reconnecting repeatedly will not solve the underlying issue.

Check whether the selected profile includes the expected protocol and connection parameters. Common proxy protocols include Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC; system-level tunnel options may include WireGuard. These are not interchangeable labels. A client must support the protocol used by the profile, and a profile designed for one client may not import correctly into another.

On Windows and macOS, make sure the client is not merely open in the background while its system proxy or tunnel function remains disabled. On Android and iOS, check whether the operating system displays an active VPN indicator and whether the client has permission to create a VPN connection. On Linux, verify that the selected client is running under the expected user session and that its local proxy or TUN interface was created successfully.

7

quick checks

5

major platforms

90+

countries available

200+

routes available

If the subscription appears incomplete, update it once and wait for the client to finish parsing. Do not paste the link into a public document or screenshot: subscription URLs can contain access credentials. If an update continues to fail, test another compatible client only after confirming that the account and subscription are valid.

Check 2: Test the local network before blaming the VPN

A VPN cannot repair a network that has not completed its own login or authorization process. Public Wi-Fi in hotels, airports, offices, schools, and cafés may require a browser-based captive portal. Until you accept the terms or sign in, a VPN handshake may fail, or the VPN may connect while ordinary traffic is blocked.

Disconnect the VPN and open a simple website that does not require your account. If a sign-in page appears, complete it first. Mobile devices sometimes keep the Wi-Fi symbol visible even though the network has no usable internet route. Toggle Wi-Fi off and on, or temporarily test the same client over mobile data. Comparing two access networks is useful because it separates a local Wi-Fi restriction from a client or route problem.

Also check whether the router has filtering, parental controls, custom DNS, or a device limit that affects this particular computer or phone. A recently changed router setting may block UDP traffic, unknown DNS servers, or long-lived encrypted connections. You do not need to disable every security feature immediately; record the current state, test one controlled change, and restore it after the test.

When moving between home broadband, office Wi-Fi, and mobile data, allow the client to reconnect rather than assuming that the previous session is still usable. The network interface, gateway, and DNS resolver may all change. A stale connection can display as active even though the route behind it is no longer reachable.

Key takeaway: A VPN connection is only one layer of connectivity. Confirm that the underlying network has internet access and has passed any captive-portal login before investigating advanced settings.

Check 3: Inspect system proxy, TUN mode, and routing rules

One of the most common causes of “connected but no internet” is a mismatch between the way the client receives traffic and the way applications send traffic. A local proxy may be running on the device, but the browser may not be configured to use it. Conversely, the system may still point to a local proxy port left behind by a closed or crashed client.

Review the client’s current operating mode. Rule mode normally sends selected domains or applications through the proxy and leaves other traffic direct. Global mode sends a broader range of traffic through the selected route and can be useful for isolating a routing-rule problem. TUN mode creates a virtual network interface and can capture traffic from applications that do not honor ordinary HTTP or SOCKS proxy settings.

For a quick diagnosis, use the least complicated mode that matches your goal. If a browser works in global mode but not in rule mode, the route itself may be fine and the rule set may be incomplete or outdated. If the browser works through a manually configured proxy but not through TUN mode, inspect permissions, the virtual interface, and conflicts with another network filter. If nothing works in any mode, continue to DNS and server checks instead of repeatedly switching modes.

Look for stale proxy values in the operating system. On Windows, review the system proxy page and any automatic configuration script. On macOS, check the active network service under its proxy settings. On Linux, inspect desktop proxy variables and shell variables such as HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY when command-line tools are affected. On Android and iOS, review the Wi-Fi network’s proxy option and the VPN profile list.

Close duplicate clients before testing. Clash Verge, sing-box, Shadowrocket, official desktop clients, and other compatible tools may each create a local listener, system proxy, or TUN interface. Running two at once can produce port conflicts, competing routes, or a proxy setting that points to a process no longer handling traffic.

Disconnect the VPN
→ Clear or disable stale system proxy settings
→ Close other proxy clients
→ Open one client only
→ Select one known-good profile
→ Enable one routing mode
→ Test a normal website
→ Test an IP lookup separately

Do not enable every capture feature at once. A clear test with one client, one profile, and one routing mode produces more useful evidence than a complicated configuration with several simultaneous tunnels.

Check 4: Diagnose DNS and name resolution

DNS converts a domain name into an IP address. A VPN may successfully establish an encrypted session while DNS requests continue using an unavailable local resolver, a blocked resolver, or a resolver that conflicts with the selected route. In that situation, some applications may appear completely offline even though the tunnel itself is healthy.

Compare a domain test with an IP-based test where appropriate. If an application can reach a known IP address but cannot open the corresponding domain, DNS is a strong suspect. If both fail, the issue is more likely routing, permissions, the selected profile, or the remote server. Browser DNS-over-HTTPS can make this comparison less obvious because the browser may use its own resolver instead of the system resolver.

Review DNS-related options in the client, operating system, browser, and mobile network. Features may be called “remote DNS,” “fake IP,” “enhanced mode,” “private DNS,” or “DNS over HTTPS.” Their behavior differs by client. A fake-IP mode can work well when the client’s DNS component and rule set are compatible, but it can also confuse applications that expect ordinary address results.

As a controlled test, temporarily use the client’s recommended DNS mode or switch from a custom system resolver to automatic resolution. On Android, Private DNS can override assumptions made by the VPN client. On iOS, a content filter or DNS profile may continue operating alongside the VPN. On desktop systems, flush the local DNS cache after changing the configuration, then restart the affected application.

Linux users should also inspect the resolver manager in use, such as NetworkManager, systemd-resolved, or a desktop environment’s own network service. A VPN client that modifies DNS without integrating correctly with the active resolver can leave the system pointing at a local address that no longer answers.

  • ✅ Test whether the failure affects domains, IP addresses, or both
  • ✅ Check the client, browser, and operating system DNS settings together
  • ✅ Temporarily disable conflicting Private DNS or DNS-over-HTTPS settings for comparison
  • ❌ Do not change several DNS providers at once and assume the fastest one is the correct fix
  • ❌ Do not publish a subscription link while asking others to diagnose DNS behavior

Check 5: Review permissions, firewall, and security software

VPN clients often need permission to create a virtual interface, install a network extension, modify the system proxy, or add a VPN profile. If that permission was denied, revoked after an operating-system update, or blocked by an administrator, the interface may look present without carrying usable traffic.

On Windows, inspect the client’s permission status and firewall rules. Security software may classify the local proxy listener or tunnel driver as a new network component. On macOS, approve the requested network extension or VPN configuration in System Settings when prompted. On Android and iOS, remove obsolete VPN profiles only when you know which profile belongs to the affected client, then allow the client to create a fresh profile.

Linux environments can involve both a desktop firewall and command-line rules managed by another service. A TUN interface may be created successfully while forwarding or DNS traffic is blocked. If the device belongs to an organization, endpoint security policies may prevent users from creating tunnels or changing routes. In that case, repeatedly reinstalling the client is unlikely to help.

Use a temporary, reversible test rather than permanently disabling protection. Pause one third-party firewall feature if your security policy allows it, test one profile, and restore the feature immediately. If the VPN works only while protection is disabled, create a narrow exception for the trusted client and its required components instead of leaving the entire firewall off.

A practical seven-step recovery procedure

The following sequence is designed for a quick, repeatable test. It applies whether you use an official VncVPN client or a compatible client such as Clash Verge, sing-box, or Shadowrocket. The exact menu names differ, but the diagnostic logic remains the same.

  1. Disconnect and compare: Test the same website with the VPN off and on. Write down whether the failure affects every application or only one browser or app.
  2. Confirm the local network: Complete any captive-portal login, reconnect Wi-Fi, and compare another access network such as mobile data when available.
  3. Refresh the configuration: Update the subscription once, verify that profiles were received, and select a compatible profile rather than an empty or outdated entry.
  4. Use one client: Close other VPN, proxy, TUN, DNS, and traffic-filter applications. Restart the remaining client so it can rebuild its listener or virtual interface.
  5. Change only the routing mode: Compare rule mode with global mode, or compare ordinary system proxy operation with TUN mode. Record which test changes the result.
  6. Check DNS: Compare domain resolution with IP connectivity, then review Private DNS, DNS-over-HTTPS, fake-IP behavior, and the client’s DNS mode.
  7. Try another profile or route: Select a different available region or route type. If every profile fails, collect logs before making more changes and contact support with the exact client, platform, mode, and error message.

After each step, test more than one type of traffic: a normal webpage, an application that previously failed, and an IP-check page if available. This prevents a partial fix from being mistaken for a complete recovery. For example, a browser may work through an HTTP proxy while a terminal tool still lacks proxy variables, or a website may load while DNS-dependent background services remain blocked.

If you need to import a subscription into a compatible client, use the client’s subscription-import function rather than manually copying individual fields. Official clients are usually simpler for users who want an integrated experience across Windows, macOS, Android, iOS, or Linux. Compatible clients provide more control over rules, protocols, and TUN behavior, but they also expose more settings that can conflict.

Check 6 and 7: Test another route and verify protocol compatibility

A server can accept the initial handshake and still fail to provide a useful path to the destination. The selected route may be congested, temporarily unavailable, blocked by the local network, or unsuitable for the protocol transport it uses. This is why a second profile is an important diagnostic step, not merely a speed comparison.

Try another route in the same region first. If that does not help, compare a different region or route category. Some providers describe route types with terms such as BGP, CN2, or IEPL. These labels describe network paths and carrier arrangements; they do not automatically guarantee that every application will work better. Judge the result by the actual task, including browsing, meetings, downloads, or access to a particular service.

Confirm that the client supports the profile’s protocol and transport. Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard use different configuration models and have different dependencies. A profile may import into a client but fail during connection because a required transport, TLS option, certificate setting, or UDP capability is unsupported. Use the provider’s recommended client when the profile contains advanced fields that a third-party client cannot interpret.

Read the connection log without exposing credentials. Useful clues include DNS failure, timeout during handshake, certificate errors, permission denial, address already in use, route installation failure, and repeated reconnects. Remove subscription tokens, usernames, passwords, and private addresses before sharing logs. A precise error message is more valuable than a screenshot showing only “Connected.”

When a fallback route works, keep the original profile for later comparison instead of deleting it immediately. The first route may recover after a network or server-side change. If no route works across more than one access network and the subscription updates correctly, the issue may require provider-side investigation rather than more local configuration changes.

Final diagnosis rule: If another profile works, focus on the original route or protocol. If no profile works but the local network is healthy, focus on permissions, DNS, routing mode, or subscription validity.

When the quick fixes do not work

Do not reset every network setting as the first response. A full reset can remove useful evidence, erase custom routes, delete VPN profiles, and make it harder to identify the original cause. Instead, preserve a short record of what changed: platform, client name and version, selected protocol, routing mode, network type, whether the VPN indicator appeared, and the exact point at which internet access stopped.

Restore the simplest known state before another test: one client, one profile, one routing mode, automatic system proxy unless the client requires otherwise, and no duplicate DNS or traffic-filter application. Restart the client after changing a virtual interface or network extension. Some operating systems do not apply a route or DNS change completely until the affected network service is restarted.

Contact support when the subscription cannot update, all profiles fail consistently, or the log shows an account, authorization, certificate, or server-side error. Include the time of the test, the platform, the client, the protocol, and a redacted error message. Do not include the full subscription URL. If you are testing on several devices, say whether the failure is limited to one device or follows the same profile everywhere.

  • ✅ Keep a known-good baseline before changing advanced settings
  • ✅ Change one variable at a time and record the result
  • ✅ Use an IP-check page to verify the effective route after reconnection
  • ✅ Prefer the official client when third-party parsing or TUN behavior is uncertain
  • ❌ Do not run multiple VPN clients simultaneously
  • ❌ Do not share credentials, full subscription links, or unredacted logs

A reliable troubleshooting habit is to separate the problem into layers: local internet access, subscription retrieval, profile parsing, handshake, system traffic capture, DNS resolution, routing, and destination access. “Connected” confirms only part of that chain. Once each layer is tested independently, the fix is usually much more direct: correct the proxy mode, repair DNS, grant the missing permission, refresh the subscription, or choose a compatible route.