To check whether your VPN is working, compare your public IP before and after connecting, check the DNS resolution path, then test the apps you actually use. A client’s “Connected” status is only a starting point: it may mean the configuration is enabled, a proxy is listening, or a tunnel is established. It doesn’t prove that all traffic is being routed as expected.
Start by defining what you want to test. If you only need your browser to access international websites, check the browser’s traffic path. If you want other apps to use international routes too, check which traffic the system hands off. The steps below aren’t tied to a specific client and can help you keep a clear record when troubleshooting.
First, distinguish connection status, public IP, and access results
These describe different stages. Connection status tells you what the local client is doing. Your public IP is the source address a test website sees. Whether a site loads also depends on the site, your account, regional policies, and your local network. Being able to open a site doesn’t prove the proxy is working; a site that won’t load doesn’t automatically mean the route is down.
| Check | What it tells you | What it can’t prove on its own |
|---|---|---|
| Client shows Connected | The client has entered a connected or traffic-routing state | That all apps use this route |
| Public IP has changed | The network exit used by this test request has changed | That other sites, apps, or address families use the same exit |
| DNS test result | Which recursive resolver handled the test domain lookup | The resolution path for every domain or the path taken by web traffic |
| The app you tested works | The current action in that app can be completed | That background requests and all other apps use the proxy |
So, frame your conclusion as “this type of request from this app used the expected exit,” not “the whole device is fully covered.” A clearly defined scope gives you a sound basis for changing rules later.
Compare your public IP before and after connecting
Disconnect the client, then open the IP check page in the browser you plan to test. Note the public IP, network provider, and location shown. Connect to the route you want to test, reload the same page, and compare the results. Keep the device, local network, and browser the same where possible, so a network change doesn’t look like a VPN effect.
- Record a baseline before connecting. If your browser has a proxy extension, check whether it’s active; otherwise, your baseline may already be using a different proxy.
- Reload the test page after connecting. If it doesn’t run a fresh check, close it and open it again. Don’t rely on results left over in an old tab.
- Compare the full IP address and network provider, not just the location label. Different databases may assign different location labels to the same address.
- If you use rule-based routing, check whether the test site is set to use the proxy or connect directly. If needed, temporarily change the rule so the test request clearly uses the route you’re checking, then restore your usual settings.
A changed public IP and an expected network provider are strong evidence that this browser request was routed through the VPN. But if the test page matches a direct-connection rule, an unchanged address may be normal split routing, not a connection failure. Check the client’s connection log or rule-match details before drawing a conclusion.
Check DNS: focus on the resolution path, not just the location
DNS translates domain names into network addresses. Routing web requests through a proxy doesn’t guarantee that DNS lookups take the same path. The system resolver, a client’s built-in DNS, and a browser’s Secure DNS setting may all play a role. A DNS leak generally means lookup requests bypass the protected path you intended to use and reach an unexpected resolver.
A DNS test page typically requests a set of temporary domains, then uses queries observed by the authoritative servers to show information about the recursive resolvers involved. The results aren’t a complete record of every DNS lookup on your device, and they may not directly show the addresses configured on your router or in your client.
Save a result while disconnected, then connect and run the test again. If it still shows a resolver provided by your local network, and you want those lookups to use the proxy too, check the client’s DNS handling, remote resolution, and domain-routing settings. If your browser has its own encrypted DNS enabled, it may bypass the system resolver; interpret the results alongside the browser’s settings.
A DNS resolver showing a different location from your VPN exit isn’t enough on its own to prove a leak. Public resolvers may use distributed servers, and geolocation databases can be inaccurate. Conversely, seeing an overseas resolver doesn’t prove that the lookup itself was encrypted. Check who resolved the domain, which path the query took, and whether that matches your settings—not just the country name.
Test apps individually: browser coverage doesn’t mean the whole device is covered
A system proxy usually affects only apps that follow the system proxy settings. Some apps have their own network settings, and some connection types don’t automatically use a standard HTTP proxy. Browser extensions typically cover an even narrower scope, so they can’t tell you whether desktop apps are routed too.
Clients that support TUN or a virtual network interface can route more traffic at the network layer, but the actual scope still depends on routes, exclusion rules, permissions, and protocol support. “Global mode” doesn’t necessarily mean the whole device is covered: it may simply send all traffic that reaches the client through one route.
What to check on desktop and mobile
On Windows and macOS, first check whether the client uses the system proxy or traffic routing through a virtual interface. On Linux, desktop proxy settings, environment variables, and individual app proxy options may all be separate. It’s not unusual for terminal tools to use a different route from your browser. Don’t assume that settings have the same names across platforms.
On Android, check whether the client has an app include or exclude list. On iOS, use the client’s rules and network extension settings to confirm which traffic is covered. A network indicator in the system status bar is only a status hint, not a substitute for testing the apps themselves.
- ✅ Browser: Check the public IP and confirm whether Secure DNS or a proxy extension has changed the DNS or traffic route.
- ✅ Desktop or mobile app: Perform a real network action, then check the client for the relevant domain, connection, or rule-match log.
- ✅ Command-line tool: Check whether it uses the system proxy, environment variables, or its own settings, then test its network path.
- ❌ Don’t use one successful browser test as a substitute for checking other apps.
If you can’t check an app’s exit directly, use the client’s connection log as a secondary check. A record showing the target connection on the expected route is more useful than a toggle shown as enabled. Troubleshooting screenshots may contain domains, account details, or subscription URLs; redact sensitive information before sharing them with support.
Why your VPN may appear not to be working
IP unchanged? Check routing rules, then traffic coverage
The test site may be set to connect directly, the app may be excluded, or the system proxy may be off—all of which can leave your original exit in place. First check whether the request reached the client. If it didn’t, check the traffic-routing mode; if it did, check which rule it matched. This is usually more effective than repeatedly switching locations.
Your IP changed, but the website still shows your original location
A site may determine your location from account details, cookies, past sessions, or device location permissions—not just your IP. A private window can help rule out some stored site data, but it won’t change what your account indicates or automatically disable location access. Differences in how quickly IP geolocation databases update can also explain a mismatch.
Connected, but pages keep loading
Possible causes include DNS resolution failures, an unreachable upstream server, restrictions on the destination site, or conflicting rules. First check whether all sites fail or only a particular app or destination. If only certain features are affected, consider whether they use UDP traffic that the client isn’t routing. A homepage that loads doesn’t rule out problems with other network paths.
You changed routes, but the results haven’t changed yet
An app may reuse an existing long-lived connection, while the client may route only new connections through the new route. Save your work, restart the app you’re testing, and check a newly created request. If needed, rebuild the connection as described in the client’s documentation. Updating a subscription only fetches the configuration; also check which route and configuration group are currently selected.
Protocol names such as Shadowsocks, VMess, Trojan, and VLESS don’t prove that all device traffic is being routed. A protocol describes how a connection works; the client configuration determines which requests use it. Likewise, whether a route is direct, relayed, or a dedicated line doesn’t replace checks of the exit IP and individual apps.
Draw a conclusion: keep a record you can check again
Keep the before-and-after exit results, the current client mode, DNS settings, and the results of testing the target app. Change one setting at a time and repeat the same steps. If you switch routes, browsers, and local networks all at once, it’ll be difficult to tell which change fixed the problem.
A practical test for whether a VPN is working: The request reaches the client, matches the expected rule, and uses an exit consistent with your route selection; the DNS path matches your privacy goals; and the app you actually use passes its own test. Keep your conclusion within the scope you tested—don’t treat it as a guarantee for the entire device.
If the issue persists, visit the Help Center for troubleshooting options, or submit a question through the dashboard. Include your device platform, client mode, affected app, and checks you’ve already tried. Don’t share your subscription URL publicly; it often contains credentials needed to access your subscription configuration.
Finally, a changed exit IP doesn’t make you anonymous, and a correctly routed DNS query doesn’t stop a website from recognizing an account you’re signed into. VPN83’s privacy policy is “no logs.” Browser storage, app permissions, and how websites handle data are separate concerns that still need to be managed.