How can you tell if your VPN is working? Check your public IP first, then DNS, and finally the apps you actually use. A client showing “Connected” usually confirms only that the connection is up; it does not prove that all traffic is using the intended route. Check connection status, traffic paths, and routing rules separately.
Connection status and traffic routing
A client may use the system proxy or route traffic through a virtual network interface. The system proxy is available mainly to apps that honor that setting; apps that ignore it may still connect directly. Virtual interfaces are common with VPN or TUN modes, but which traffic they capture still depends on routes, app exclusions, and routing rules. The mode name alone does not tell you what is covered.
“Global” mode also depends on what the client means by it. In some clients, it only sends requests handled by the proxy core through the selected proxy; it does not automatically capture traffic from every app on the device. Rule-based modes route traffic according to factors such as domain, destination address, or app, so some direct connections may be intentional.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC refer to different proxy protocols and transport mechanisms—not to how much device traffic is captured. Successfully importing a subscription only means the client has received its configuration. Check separately which route is selected and whether system proxy or tunnel mode is enabled.
Public IP: establish a baseline
- Check your connection without the VPN. Disconnect the client, open a trusted public IP lookup page in your browser, and note the public IP address, network provider, and location. Do not mistake a local network address shown in system settings for your public IP.
- Check again after connecting. Select a route and make sure the required proxy or tunnel setting is enabled, then reload the same lookup page. If needed, open a fresh browser window so you do not mistake cached content for a new result.
- Check how the lookup request is routed. If the IP has not changed, review the client’s connection logs to see whether the lookup domain uses a direct or proxied connection. If the site is set to connect directly by a rule, it shows only your direct IP—not how other sites are routed.
- Cross-check with the app you actually use. Make a new request to the target site and compare it with the client’s connection details. If the client shows the matched rule and exit route, use those details to understand the traffic path rather than relying on the displayed location alone.
A changed IP means the public exit used for that request has changed; it does not mean the entire device is covered. IP locations are inferred from databases and may be out of date. The route’s entry point, exit point, and database listing may use different place names. If the displayed location does not match, check the actual exit IP and route details before assuming the connection has failed.
Check IPv4 and IPv6 as well. If the lookup page tests them separately, review both results. One type of traffic may use the VPN while the other takes a local route, causing results to vary. Whether that is a problem depends on the client’s support for each address family and your intended routing policy. Avoid disabling system features without understanding your network setup.
DNS: check how queries are routed
DNS translates domain names into network addresses, and DNS queries do not necessarily follow the same route as webpage traffic. Your browser may use encrypted DNS, the client may handle DNS queries, or your system may continue using a resolver provided by your local network. A correct public IP does not by itself confirm that DNS is routed as intended.
After connecting, use a trusted DNS test page in your browser and review the recursive resolvers and network providers it reports. Compare the results with the client’s DNS settings and your browser’s Secure DNS settings. If all queries are supposed to use the tunnel but the test still shows a local network resolver, investigate whether some queries are bypassing it.
Do not judge a DNS leak solely by the country where a resolver appears to be located. Public DNS services may use nearby access points and distributed exits, and test pages may rely on IP location databases. Conversely, a resolver that appears to be in the expected region does not prove that the query path is secure. What matters is which service makes the query, how it is transmitted, and whether that matches your configuration.
Command-line DNS lookup results can help you understand system resolver settings, but may not reflect how your browser or proxy client resolves domains. For example, an app may resolve domains remotely through a proxy or use its own DNS service. The system resolver list is a useful clue, not definitive proof of a DNS leak.
Test individual apps—not just your browser
Once the browser test passes, try a fresh network request in the app you actually want to use—for example, refresh a remote document, reconnect to a work service, or load the target page. Existing connections may keep using the route they had before you switched. After changing settings, close and reopen the app if needed, then check its new connections.
- ✅ Browser: Check for conflicts between proxy extensions, Secure DNS, and the system proxy. Private browsing can reduce some cache-related issues, but it does not change your routes automatically.
- ✅ Desktop apps: Check whether the app needs its own proxy settings and whether the client can route this type of traffic. If the browser works but a desktop app does not, start by checking which traffic the client captures.
- ✅ Mobile apps: Confirm that the system VPN connection is still active. Check for per-app routing or exclusions in the client, and test again after switching networks.
- ✅ Command-line tools: Check whether the tool uses proxy environment variables or its own settings. A terminal does not necessarily use the same exit as a browser that is already using a proxy.
- ❌ Client latency alone: A successful connection test only shows that the test destination is reachable. It does not replace checks of your target app, DNS, or public IP.
System proxies on Windows and macOS are not used by every app. On iOS and Android, the client implementation and system settings determine which traffic is captured. On Linux, check that desktop proxy settings, terminal environment variables, and routes are consistent. Follow the instructions for your client rather than applying steps from one platform to another.
Common results and what to check
| What you see | Possible cause | What to check next |
|---|---|---|
| Shows as connected, but the IP lookup is unchanged | The lookup domain connects directly, or the app is not covered | Check matched rules, system proxy settings, and tunnel mode |
| Browser uses the expected exit, but other apps fail | The app ignores the system proxy or has separate settings | Check the app’s proxy settings, exclusions, and new connection logs |
| Web traffic uses the expected exit, but DNS results do not | DNS is handled separately by the system, browser, or app | Check DNS routing and Secure DNS settings one by one |
| The reported exit location does not match | The location database differs, or a different exit is in use | Check the selected route, connection logs, and other lookup sources |
| Some sites work, but the target service returns an error | Target-specific routing rules, account permissions, or the service’s own restrictions | Note the error message and distinguish network failures from service-side rejections |
| Problems start after switching networks | An existing connection has dropped, or routes and DNS have not recovered | Reconnect the client, reconnect the app, and test again |
If you need to temporarily broaden proxy coverage to isolate the issue, note your original settings and restore them afterward. Change one thing at a time—for example, adjust the traffic capture mode first, then check DNS. Changing routes, browser settings, and rules all at once makes the results hard to compare.
A region or account error from a target site does not necessarily mean the VPN is not working. A service may make decisions based on your account region, sign-in status, payment details, and its own policies. An IP check tells you where a request appears to come from; it does not guarantee access to a service.
What these checks can—and cannot—tell you
Public IP and DNS checks verify traffic paths; they are not a complete privacy audit. They cannot show how a service handles data or prove that direct traffic will be blocked if the connection drops. VPNSound’s privacy statement says “no logs,” but that is a statement of service policy, not something a single browser test can verify or an absolute guarantee of anonymity.
If your client offers connection protection, you can test it separately after understanding how it works: disconnect the route deliberately and check whether apps that should use the tunnel stop connecting. Save your work first to avoid interrupting anything in progress. Unless you have confirmed that this feature is available, do not assume the client will block every request that falls back to your local network.
When sharing troubleshooting details, include your platform, client version, connection mode, route name, target app, and error message. Subscription links may contain access credentials, so do not post them on public test sites. Before sharing a screenshot, hide your subscription URL, username, and full public IP address. For help, describe how to reproduce the issue in a support ticket in the user panel.