First, identify where the “not working” issue occurs
VPN connected but not working? Don’t reinstall the client just yet. Check your public IP, DNS resolution, and app access in that order to find out whether traffic is bypassing the VPN, DNS is failing, or the website is blocking access.
A VPN icon in your system tray usually means a network extension or tunnel is connected. But a client showing “Connected” doesn’t mean every request from every app is going through the remote exit. Split-tunneling rules, browser-specific proxies, cached app connections, and conflicts with network extensions can all make the icon tell a different story from what’s actually happening.
Note the current server, connection mode, and affected app. Disconnect, then open VPNBand’s What’s my IP page in the same browser and record the public IP and location it shows. Connect to the server, refresh the page, and compare the results. Avoid switching local networks during the test, since that can also change your exit IP and skew the comparison.
Check your public IP: compare before and after connecting
Select a server in the client, wait for the connection to stabilize, then reload the IP lookup page. If your browser still shows the old result, try a fresh private window to reduce interference from cached pages and extensions. Private browsing doesn’t necessarily disable every extension or change system routing, so treat it as one troubleshooting step—not a definitive test.
Seeing the same public IP before and after connecting doesn’t necessarily mean the client has failed completely. In rule-based mode, the lookup site may be set to connect directly while the site you’re testing uses the proxy. Check which rule matches the lookup domain. If needed, temporarily switch to the client’s global proxy mode and confirm it covers your browser, then test again. Restore your usual rules when you’re done.
| What you see | Possible cause | Next step |
|---|---|---|
| Exit IP is unchanged | The lookup domain connects directly, or the browser isn’t using the proxy | Check matching rules, system proxy settings, and browser extensions |
| Exit IP changed, but the site won’t open | DNS issue, restricted exit IP, or an outage at the destination | Check DNS, then test another destination and server |
| Browser works, but an app doesn’t | The app ignores the system proxy or has its own connection settings | Check the app settings and how the client routes traffic |
| Displayed location doesn’t match the server name | The IP database may be outdated, or the server’s entry and exit points differ | Check the full IP and share the lookup results with support |
IP geolocation databases can show different results for the same address, and city-level locations are especially unreliable as evidence of server quality. A server name may not describe where its entry point is located. If your exit IP changes but the displayed location doesn’t match, save the address and test time. Don’t assume the connection failed based on a map label alone.
Check DNS: look at the lookup result and route separately
DNS translates domain names into addresses your device can connect to. Your exit IP can change while DNS requests are handled differently than expected, leading to slow loading, failed lookups, or connections to the wrong address. Conversely, seeing a resolver in a particular region doesn’t prove that your web traffic exits from there.
If you use a DNS test that shows resolver details, first run it with the VPN disconnected and save the baseline. Connect, run it again, and check whether the resolvers changed, whether your local network’s resolvers still appear, and whether the results match the client’s DNS policy. The test sends requests for test domains, so use a tool you trust and never submit a private subscription link to a testing site.
A DNS leak is about whether requests take the path you expect. If you expect DNS requests to use a protected route but they’re still handled directly by your local network, investigate further. A resolver belonging to a public provider—or an address in a different country from your server—isn’t proof of a leak. Public DNS services may use nearby locations, and the location shown by a test may be inaccurate.
Secure DNS in your browser can affect test results
Your browser may use DNS over HTTPS (DoH), selecting its own DNS service instead of relying entirely on your system settings. Whether those connections use the VPN still depends on your routing and proxy configuration. Before troubleshooting, note the browser’s Secure DNS setting and compare it with the client’s documentation. If you change it temporarily, test again and restore the original setting afterward. Avoid changing multiple DNS options at once.
The nslookup command can help you see DNS responses under your system’s current settings, but it doesn’t prove that your browser uses the same DNS route. Some clients also use Fake-IP, mapping domain names to synthetic addresses for internal forwarding. Seeing these results doesn’t automatically mean DNS is broken. Check the client’s mode and logs, and don’t treat these addresses as the website’s actual public IP.
Check each app: review system proxy and routing rules
If web lookups work but a chat app, desktop app, or terminal can’t connect, focus on whether that app is using the same route—not on the lookup page’s IP. A system proxy is a setting apps can choose to use, not a guarantee that all traffic is routed through it. Some apps ignore it or use their own proxy settings.
TUN or system network extension mode can route traffic at the network layer, but coverage still depends on routing, exclusions, DNS settings, and the client’s implementation. Turning on TUN isn’t a universal fix. Confirm that system permissions are granted, and check for other VPNs, filtering software, or network extensions that may also be handling traffic.
- Start with one test destination. Complete a real action in your browser, then try the same service in the affected app. This helps avoid mistaking differences between websites for differences between clients.
- Check the app’s own proxy settings. Make sure it isn’t still set to an outdated local proxy address. If it uses the system proxy, confirm that the app supports this and that the option is enabled.
- Check which rule matches. In the client’s connection logs, see whether the destination domain is set to connect directly, use the proxy, or get blocked. Apps may contact several domains, so changing the rule for the home page alone may not be enough.
- Quit the app and try again. Existing long-lived connections may keep using the old route. Fully quit and reopen the app to check a rule change; refreshing the interface alone may not be enough.
- Undo temporary changes one at a time. Once you find the cause, keep only the settings you need and restore any temporary global mode or test DNS settings. This avoids leaving behind a hard-to-trace mix of configurations.
On Windows and macOS, distinguish between system proxy settings and network-level routing. On iOS and Android, check that the VPN configuration is active and whether the client supports excluding specific apps. Linux desktop proxy settings may not affect terminal programs. Don’t assume that a working browser means other types of apps will work too, and don’t overwrite system environment variables in bulk without recording their original values.
Why a changed exit IP doesn’t guarantee the service will work
A website may decide whether to allow access based on the exit IP’s reputation, account region, existing session, or its own risk checks. Changing your exit IP doesn’t change your account’s region or guarantee that every service will accept the address. A request to verify your account or a stale region notice is a different issue from a network connection that cannot be established at all.
First, identify the type of error. If the domain won’t resolve, check DNS. If the connection times out, check the server, routing rules, and destination availability. If the page loads and displays an account or location notice, review the destination service’s requirements. If you see a certificate error, stop before entering sensitive information and check your system clock, the destination domain, and your network environment.
Switching servers can help isolate an issue with a particular exit, but keep the test app, destination, and connection mode the same. If one server fails and another works, record the comparison; don’t assume the whole network is fixed. Terms such as relay, direct connection, and IEPL describe how a route is organized. They don’t replace checks of the exit IP and app, or guarantee that a particular service will work.
Update your subscription only when there’s a reason to. A subscription link lets the client fetch configuration; it isn’t an IP lookup address, and importing it once doesn’t mean the configuration stays current. If the server details in your account panel have changed, use the client’s update feature and confirm which configuration is selected. Don’t paste subscription contents into unfamiliar websites or reinstall repeatedly instead of checking connection logs.
Gather your findings before contacting support
If these basic checks don’t identify the cause, visit the support page to find out what to do next. A useful report explains what happened at each step, not just that the connection failed. Before-and-after details help support distinguish between a server issue, a client setting, and a restriction imposed by the target app.
- ✅ Note your operating system and client versions, server name, current routing mode, and the type of local network you were using when the issue occurred.
- ✅ Say whether your exit IP changed after connecting, whether the DNS test showed anything unusual, and which apps worked or failed.
- ✅ Save the exact error and test time. Before sharing a screenshot, hide account details, the full subscription link, access tokens, and other sensitive information.
- ❌ Don’t send passwords or unredacted full logs. Avoid changing several settings at once and keeping only the final result.
Test access once more with the VPN disconnected to confirm your local network is working. If lookups or connections still fail broadly, restore your system network, proxy, and DNS settings before comparing again. Issues that occur only while connected and go away after disconnecting help narrow the cause to the client’s route or server configuration.