VPN Not Working? First, distinguish connection from traffic routing
If your VPN connects but isn’t working, check your public IP first, then DNS, and finally the specific app. “Connected” usually means only that the tunnel or proxy service has started—not that your browser, games, and command-line tools are all using it.
Troubleshooting means separating a few steps: which service the app sends requests to, how the client handles them, which resolver looks up the domain, and which public IP the destination site sees. If any step differs from what you expect, you may see a connected icon but still be unable to open a website. Don’t start by reinstalling the client or changing every setting at once.
System proxies, virtual network interfaces, and browser extensions cover different traffic. A system proxy works only when an app follows the proxy settings. TUN mode routes traffic that matches its rules through a virtual network interface, but exclusions, permissions, and routing rules still apply. Browser extensions usually affect only that browser. A connection icon alone can’t tell you which method is working.
Public IP: Compare Before and After Connecting
Open the IP lookup page and note the public IP, ISP, and location it shows. Then connect to your chosen route and run the check again in the same browser. Location databases may take time to update, so compare the IP address itself rather than relying only on the map label.
- Record a baseline. Disconnect the client you’re testing, make sure no other proxy extension or networking client is routing your browser, and note the lookup results.
- Choose a location and connect. Note the route name and connection mode. Don’t switch between them while testing.
- Send a fresh request. Reload the lookup page. If the result might be cached, close the old tab and open the page in a new window.
- Check the routing rule. If the lookup page is set to connect directly, an unchanged IP may be expected. Temporarily route that site through the proxy, check again, then restore the original rule.
- Test the target app. A changed browser IP shows only that the browser request took a different route. Check other apps separately.
Different routes may share the same public IP, so an unchanged IP after switching routes doesn’t necessarily mean the switch failed. Conversely, a changed IP doesn’t prove that every protocol is being routed. If the lookup service shows both IPv4 and IPv6 results, compare them separately rather than drawing a conclusion from just one address.
A browser’s private window isolates some local sessions and storage, but it doesn’t automatically bypass the system proxy or create a separate network route. It can help rule out login-state and cache issues, but it can’t confirm the traffic path for the entire device.
DNS Checks: The Resolver’s Location Isn’t Your Public IP’s Location
DNS translates domain names into IP addresses. Web traffic may go through a proxy while DNS queries still use your local network. Or DNS may be handled by the browser’s Secure DNS, the client’s built-in resolver, or a remote proxy. An IP check and a DNS check examine different parts of the connection.
When using a trusted DNS leak test, note that it shows the addresses and locations of DNS resolvers, not the public IP used for your web traffic. Test pages typically trigger lookups with special domains and observe the recursive resolvers. Public DNS providers may use distributed infrastructure, so a displayed location that differs from your chosen route doesn’t by itself prove a leak.
The key question is whether domains you expect to be resolved remotely are instead being sent to your local network’s DNS resolver. First check which resolvers the client uses for proxied and direct domains, then see whether the browser has its own Secure DNS setting enabled. Encrypted DNS can protect part of the DNS request in transit, but “encrypted” doesn’t mean “sent through the current proxy route.”
What You Can Check from the Command Line
On Windows, run the command below in a terminal to see the default DNS server and its response for a domain. The example domain is for DNS testing only; it isn’t a CPUVPN node or service endpoint.
nslookup example.comOn macOS and Linux, you can use the same command if the relevant tools are installed; dig example.com is another option. These tools typically don’t follow a browser’s HTTP proxy settings. TUN mode, DNS interception, or system resolver settings may change the route, so command output doesn’t necessarily show which resolver your browser actually uses.
After changing DNS settings, run a new lookup and, if needed, clear the relevant system or app DNS cache. An old cached response doesn’t mean new requests are still going to the old resolver. Don’t replace every DNS setting just to make a test page “look consistent”—that could disrupt local sites and internal network domains.
Find the Cause by Symptom: Check Rules, Then Apps
Use the table below to find where to start based on what you see. It isn’t a definitive diagnosis: the same symptom can have several causes, so change one setting at a time and test again to narrow it down.
| Symptom | Possible cause | Check first |
|---|---|---|
| Browser’s public IP hasn’t changed | System proxy is off, an extension overrides the settings, or the lookup site is set to connect directly | Check the proxy entry point and the rule applied to that domain |
| Browser works, desktop app doesn’t | The app doesn’t follow the system proxy or uses its own network settings | Check the app’s proxy settings and the virtual interface’s routing scope |
| Public IP changed, but the target site still denies access | Account region, platform policies, IP reputation, or a server-side issue | First determine whether it’s a denial page or a network connection error |
| Some domains fail while other sites work | DNS resolution, routing rules, or an issue with the destination service | Compare DNS results, matched rules, and error types |
| IPv4 matches expectations, but IPv6 still uses the original network | The current mode doesn’t cover IPv6, or a rule is routing it around the proxy | Check the client’s IPv6 support and the actual route |
| Stops working only after switching networks | An existing connection, route, or DNS state hasn’t updated | Reconnect, then check the system proxy and send a fresh request |
Record “domain can’t be resolved,” “connection timed out,” and “access explicitly denied” as separate errors. Check DNS first for the first case. A timeout may involve routing, the route, or the destination service; a denial may also relate to account permissions or regional policies. One error page alone doesn’t prove that the client isn’t working.
How to Check Routing Rules and Platform Access
With rule-based routing, it’s normal for some traffic to connect directly while other traffic uses a proxy. In the client’s connection list or diagnostics, check which rule matched the destination domain and which route was selected. If the client doesn’t show that information, cross-check the target app’s behavior against a public IP lookup. Don’t guess at menu names that may not exist.
In many clients, “Global” mode sends requests that have already entered the proxy core through one route; it doesn’t automatically route traffic from every app. It can help identify a routing-rule issue, but only if the request actually reaches the client. Once testing is complete, restore rules suited to everyday use so local services aren’t routed unnecessarily.
- ✅ Windows: Check that the system proxy settings match the client’s status. If you need virtual interface routing, verify its permissions and that it’s running. Some programs use their own proxy settings and may not follow the system configuration.
- ✅ macOS: Check the VPN configuration, network extension, or proxy permissions required by your client. Permission requirements vary by implementation, so you don’t need to look for every type of authorization setting.
- ✅ Android: Check VPN permission and per-app routing lists. An excluded app may still connect directly even when the status bar shows an active connection.
- ✅ iOS: Check the system VPN status and the client’s rules. Test apps beyond the browser individually; one website lookup can’t tell you how the whole system is routed.
- ✅ Linux: Check desktop proxy settings, terminal environment variables, and virtual interface routes separately. Terminal apps may not read the proxy settings configured in your desktop environment.
Running multiple proxy clients or browser extensions at once can make it unclear which settings are in effect. For testing, keep the client you’re checking and temporarily disable other tools that could change the proxy or DNS route. If your device is managed by your organization, don’t change managed network policies without authorization.
IPv6, WebRTC, and Subscription Configuration Limits
Check IPv6 as a separate route. If the target app uses IPv6 but the current proxy mode covers only IPv4, some requests may take an unexpected route. Prefer the client’s IPv6 routing or compatibility settings. If you temporarily disable system IPv6 to troubleshoot, note the original setting and restore it afterward; this isn’t a general-purpose fix.
WebRTC tests may show a local address, a privacy-masked hostname, or a public candidate address. Seeing a local address doesn’t mean web traffic has bypassed the proxy. If an unexpected public candidate address appears, investigate browser policies, UDP support, and the actual route. Don’t install extensions from unknown sources just to remove a test warning.
A subscription link provides nodes and related configuration; it doesn’t necessarily import every routing and DNS rule. That depends on the subscription format and client implementation. After updating the subscription, confirm that the selected configuration is enabled. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are names of distinct protocols or solutions; their presence alone doesn’t prove that system traffic is being routed through the client.
Subscription links may contain access credentials. Don’t post the full link, QR code, or screenshots containing tokens in public forums. Before sharing an error with support, hide credentials, account details, and any address information that isn’t needed.
A route type doesn’t determine which apps are routed through it. IEPL, transit, and direct connections describe different ways traffic is carried. Even with a dedicated route selected, an app won’t use it unless its traffic enters the client. Check the request path first, then compare route performance—not the other way around.
Keep Results You Can Review After Testing
A useful troubleshooting record includes the operating system and client name, current mode, selected location, test app, public IP before and after connecting, DNS observations, and the exact error. Change one setting at a time, then retry the same action. That’s how you tell whether the cause was a rule change, a DNS change, or the destination site recovering on its own.
If only the target site fails while the public IP and rules look right, check the site’s service notices, account permissions, and regional restrictions. A working network route doesn’t guarantee that a platform will allow access, and it doesn’t change content licensing. Following the service’s rules is more useful for troubleshooting than repeatedly switching locations.
To review the client setup process, see our Guides. To troubleshoot connection errors, visit Frequently Asked Questions. Keeping the comparison results above can save you from repeating tests when you contact support.