A VPN can show “Connected” while webpages time out, apps remain offline, or only some destinations load. That status usually confirms that the client established a tunnel; it does not prove that DNS, routing, the device’s proxy settings, or the upstream network is working correctly. Start with a simple comparison: disconnect the VPN and test the same app or website, then reconnect and test again. This helps separate a problem with your regular internet connection from one introduced by the VPN route. Work through the checks below in order, changing one thing at a time so you can tell which step made a difference.
Separate the local network from the VPN
First confirm that the device has a working connection before troubleshooting the tunnel. Disconnect the VPN, turn off any other proxy, and open a familiar website or use an app that normally works. If the same services fail without the VPN, the VPN is unlikely to be the primary cause. Check whether Wi-Fi is connected to the internet, whether a captive portal is waiting for sign-in, and whether another device on the same network can browse. On public Wi-Fi, open a plain HTTP page or the network’s sign-in screen if available; some networks block all other traffic until you accept their terms.
If ordinary access works without the VPN but stops as soon as the client connects, note the scope of the failure. Does every browser and app fail, or only one browser? Do local devices such as a printer or router page still open? Does a messaging app work while websites do not? These clues matter. A browser-only problem can point to a browser proxy or secure-DNS setting, while a system-wide failure is more consistent with a route, DNS, firewall, or kill-switch issue.
Before making changes, record the client name, selected profile or server, connection mode, and the exact error shown. If the client has a diagnostics or connection-log view, note the time of the failed test and any clear error message. Avoid posting logs publicly without reviewing them: they can contain account identifiers, server addresses, or other connection details. A controlled test with one browser and one known-working app is more useful than repeatedly changing servers and settings at once.
- ✅ Test the same app with the VPN disconnected and connected.
- ✅ Check for a Wi-Fi sign-in page or an outage affecting the local network.
- ✅ Confirm whether the failure affects one app, one browser, or the whole device.
- ❌ Don’t leave two VPN clients or system proxies active at the same time.
Refresh the connection and check DNS
A stale session or an interrupted network change can leave the client reporting a connection even though traffic is no longer moving. Disconnect from the selected server, wait briefly, and connect again. If you recently moved between Wi-Fi and mobile data, enabled airplane mode, resumed a laptop from sleep, or changed a router, fully quit and reopen the VPN client. On a phone, verify that the VPN icon and the client’s own connection status agree. If they do not, disconnect from the client before trying to reconnect rather than toggling several system settings at once.
DNS is the system that looks up a domain name and returns an address. When the tunnel is active but DNS requests are sent to an unavailable resolver, a website may appear offline even if a connection to its address could work. A useful clue is whether a page fails by its domain name while other services or previously opened pages still respond. Do not assume every name-resolution error is a DNS problem, however: a blocked destination, an incorrect device clock, an application issue, or a broken route can look similar.
As a safe first test, switch to a different server or profile supplied by the service, then try the same website again. This checks whether the issue is tied to one route without changing the operating system’s DNS configuration. If your client has a documented DNS mode, restore it to the default or recommended setting and reconnect. Avoid copying an unfamiliar resolver address from a forum or forcing public DNS while the VPN is supposed to manage DNS; that can bypass the client’s intended routing, create inconsistent results, or expose queries outside the tunnel.
Browsers may also use their own secure-DNS feature independently of the operating system. If only one browser fails, temporarily compare its secure-DNS setting with another browser, or return that setting to the browser’s default for a controlled test. Clear the browser’s DNS cache only if the browser offers a clear, built-in option and you have a reason to suspect stale lookups. A full device restart is not the first step; first test a reconnect and a second route so that the result remains informative.
For a user who wants a single place to review service and setup information, VPNYK Free VPN for China is the home page; a product page cannot establish whether a particular device, local network, or destination is currently reachable. Keep the troubleshooting decision based on the connection tests on your own device, not on a route label alone.
Review proxy settings and routing mode
VPN clients can work in different modes. A system-level VPN typically installs a virtual network interface or a system tunnel, while some proxy clients route only applications that use a configured local proxy. In a rule-based client, traffic may be sent through a proxy, connected directly, or rejected according to the active rules. A profile can therefore be connected while the browser or application you are testing is using a direct route, an unreachable local proxy, or a rule that does not match the destination.
If you use Clash Verge, sing-box, Shadowrocket, or another compatible client, check that the intended profile is selected and that the client’s system-proxy or routing mode matches how you expect traffic to flow. Menu names vary by version, so use the client’s own documentation for the exact controls. In rule mode, test a destination that should match the proxy rules and check the client’s connection or traffic view to see which outbound route was selected. If the client provides a global or equivalent test mode, use it only briefly to compare behavior, then return to your normal routing policy. A temporary test can help isolate rules, but it is not a substitute for correcting them.
On Windows and macOS, also inspect the operating system’s proxy settings if a browser or app seems to be using a different path from the VPN client. A manual proxy left behind by another tool can point to a local address where no proxy is listening. Turn off only the unexpected proxy entry, reconnect, and test again. Do not remove a proxy setting merely because it exists: some clients manage that setting while they are running. If it returns after a restart, check which application is setting it rather than repeatedly deleting it.
For browser extensions, developer tools, and command-line programs, remember that proxy behavior can be application-specific. A browser may follow the system proxy, while a terminal utility or development environment may use its own proxy variables or configuration file. Test with a second application and check that the failing program is configured to use the route you intended. If you recently imported a subscription or profile, update it through the client’s supported method and confirm that the current profile is active; importing settings does not necessarily switch the client to them.
When changing modes, avoid stacking layers. Running two VPN applications, a system proxy, a browser proxy extension, and a third-party DNS tool together makes it difficult to identify which component is responsible. Disconnect the other tools, test with one client, and restore additional tools one at a time only when the basic connection works.
Check the kill switch, firewall, and device settings
A kill switch is designed to block traffic when the VPN tunnel is unavailable or does not meet the client’s safety conditions. If the client’s tunnel is shown as connected but the operating system has not completed a route change, the kill switch can make the device appear completely offline. In the VPN client, inspect whether a kill switch or “block connections without VPN” option is enabled. If you choose to disable it for diagnosis, do so only for a brief test on a network you trust, avoid sensitive activity, and turn it back on if you rely on it. A kill switch is a privacy control, not a speed setting.
Firewalls and security suites can also interfere with the virtual network interface or the client’s network process, especially after an operating-system update or a change to the client. First look for a notification that the app was blocked. If the firewall provides application-specific permissions, verify that the VPN client is allowed on the current network profile. Prefer the operating system’s normal permission controls over turning off the entire firewall. If a work or school device is managed by an administrator, do not bypass its network policy; ask the administrator whether VPN use is permitted.
Check the device clock and date if secure websites fail with certificate errors. TLS certificates are validated against time, so a badly incorrect clock can prevent connections even when the network is available. Use the operating system’s automatic time setting where appropriate, then retry. Also check whether a recently installed security app, content filter, parental-control tool, or DNS filtering profile is still active. Such tools can apply policies before or after a VPN connection, and their behavior may vary by device and network.
IPv6 settings can be another factor when a client or network handles IPv4 and IPv6 differently. Do not disable IPv6 as a blanket fix: doing so can break local services or conceal a routing issue. If the client offers a documented option for IPv6 handling, compare its recommended setting with the current configuration. On a managed device, leave network-adapter settings unchanged unless you understand the consequences or have administrator guidance.
Platform-specific troubleshooting and next steps
Windows and macOS
On Windows, check that the VPN client is still running and that the network icon shows the expected Wi-Fi or Ethernet connection. If the client reports connected but all applications fail, disconnect and reconnect, then test a second supplied route. Review Windows proxy settings for a manual entry that may have been left by another tool, and check whether the firewall displayed a permission prompt. If the issue began after sleep or a network change, fully quit the client before reopening it. Avoid deleting network adapters or resetting all networking as an early step; those actions can remove settings used by other software and make the original cause harder to identify.
On macOS, verify the active network service and inspect the system’s proxy controls for unexpected manual entries. A VPN profile or network extension may need permission after an update, so check for a system prompt or client notice. Disconnect the VPN before changing Wi-Fi networks, then reconnect after the new network is stable. If only one browser is affected, compare it with another browser and examine browser-level proxy or secure-DNS settings before changing the system tunnel.
iOS and Android
On iOS, confirm that the VPN status is visible in system settings as well as in the client. If the device has changed networks, disconnect and reconnect from the client, and check whether a content-filtering or DNS profile is installed. Do not remove a managed configuration from a work or school device without permission. On Android, check that the VPN is the active connection in system settings and review “always-on VPN” or “block connections without VPN” only if you understand the effect. Battery optimization can pause some apps in the background, but it is less likely to explain a failure that persists while the client is actively connected; test foreground browsing first.
For either mobile platform, compare Wi-Fi with mobile data if your service plan and local rules allow it. If the VPN works on one access network but not the other, the difference points toward the router, captive portal, or network policy rather than a general account problem. Return to the original network after the test and do not keep switching settings without recording what changed.
Linux and compatible clients
On Linux, establish whether the client created the expected tunnel interface and whether the system route changed when the connection came up. The precise commands and interface names depend on the distribution and client, so use the client’s documentation rather than copying commands intended for another setup. If you use a desktop proxy client, confirm that the desktop environment and the application both honor its proxy mode. With a command-line application, inspect its own proxy configuration separately from the browser. A connected tunnel does not automatically configure every program to use it.
Across platforms, keep a simple test sequence: verify access with the VPN disconnected, reconnect once, test one browser and one separate app, then compare a second supplied route. If the problem persists, note the operating system version, client version, connection mode, network type, whether the failure affects all apps, and any non-sensitive error text. Share that information through the service’s official support channel, but never send a password or publish an active subscription link. If the connection still fails, disconnect the VPN to restore ordinary access when appropriate, leave security settings in their intended state, and wait for support guidance before making disruptive network changes.
- ✅ Change one setting at a time and repeat the same test after each change.
- ✅ Compare Wi-Fi and mobile data to identify whether the access network matters.
- ✅ Keep logs and diagnostic details private, and redact account or authorization information.
- ❌ Don’t repeatedly reinstall clients, reset network settings, or disable protections without evidence.