How can you tell whether your VPN is working? Compare your public IP before and after connecting, check DNS, then test the apps you actually use. A client showing “Connected” usually means the connection is up or a local proxy is running. It doesn’t mean your browser, meeting app, and terminal are all using the same route. To verify the connection, match each request to its route and result.
Connection Status and Your Exit IP: Check Where Requests Go
Your exit IP is the public address a website sees when you visit. When your device accesses a site through a proxy or tunnel, the site will usually see the route’s exit address rather than your network’s original public IP. The simplest check is to use the same IP lookup page before and after connecting, then compare the results—not just the client’s status icon.
- Disconnect the client, open the IP lookup page, and note your public IP, the displayed location, and whether the page reports IPv4 and IPv6 separately.
- Connect to the route you want to test. Confirm it’s selected in your subscription and that its configuration is enabled. Run the test again; don’t rely on results left over from the previous check.
- Compare the addresses, then check the client’s connection log or rule match to confirm the lookup request went through the proxy rather than directly to the internet.
- Switch back to your usual routing mode and test again. Passing the test with temporary global proxying doesn’t prove your everyday rules cover the app you want to use.
A changed address is strong evidence that this request used a different exit. If it hasn’t changed, check the applicable rules: if the lookup site is set to connect directly, an unchanged result may be expected. Conversely, seeing the route’s exit IP on a lookup site doesn’t prove every app is using the proxy.
System Proxy vs. Tunnel Mode: Check What’s Covered
A VPN client may use the system VPN interface or simply configure a system proxy. A system proxy works mainly with programs that honor those settings. TUN mode routes traffic through a virtual network interface and usually covers more, but routing, exclusion lists, and split-tunneling rules still apply. Similar labels don’t mean the modes cover the same traffic.
| Current method | What it usually affects | What else to check |
|---|---|---|
| System proxy | Browsers and apps that follow the system proxy settings | Whether the app ignores the proxy or has its own proxy settings enabled |
| Browser proxy extension | Requests in that browser covered by the extension’s rules | Other browsers, desktop apps, and terminal tools aren’t automatically covered |
| TUN or system VPN interface | Traffic routed into the tunnel by the routing and configuration rules | App exclusions, IPv6 routing, DNS settings, and UDP support |
| In-app proxy | Connections the app explicitly sends through the proxy | Whether the proxy address, authentication, and DNS resolution method match |
“Global mode” can also be misleading. In some clients, global mode sends all requests that reach the proxy core through the proxy; it doesn’t make every program use the core. If a program doesn’t read the system proxy settings, changing rule mode may not help. Check the client’s instructions for TUN or in-app proxy settings instead of repeatedly switching routes.
A subscription link provides routes and configuration; it doesn’t turn traffic routing on. After importing it, select a valid configuration and start the connection. Protocol names such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC don’t prove what traffic is covered. The client version, protocol support, and routing configuration all need to match. Don’t paste a subscription link into a public testing site: it may contain access credentials.
DNS Checks: Is Name Resolution Following the Expected Route?
DNS translates domain names into IP addresses. Web traffic going through a route doesn’t automatically mean DNS queries follow the same path. System DNS, a client’s built-in resolver, a browser’s Secure DNS, and encrypted DNS requested by an app may all be involved. The goal is to confirm that actual DNS resolution matches your configuration—not to assume something is wrong just because you see an unfamiliar provider.
Use a trusted DNS leak test to query a new domain and see which recursive resolvers it reports, then compare them with the client’s DNS settings. These pages usually show the resolvers that queried the test domain; they can’t fully map every step between your device and those resolvers. Public DNS services may also use distributed exit points, so the resolver’s location doesn’t have to match the route’s exit location.
If international domains are expected to resolve through the tunnel but you keep seeing resolvers from your local internet provider, check whether the client handles DNS, whether the browser has its own Secure DNS setting, and whether the system has leftover manual settings. If your rules allow local DNS for domestic domains, seeing a local resolver doesn’t by itself mean there’s a leak. What matters is which domains are sent where, and whether that matches your policy.
The nslookup and dig commands can help you inspect DNS results, but they may not behave like a browser using Secure DNS. Getting the same address for a domain doesn’t mean the same resolver was used; different addresses may simply reflect normal content delivery network routing.
Test Apps Individually: A Working Browser Doesn’t Prove Everything Works
Test with the apps you actually plan to use. Browsers, command-line tools, meeting apps, and games may use different networking stacks. A browser may connect through a proxy while a desktop app connects directly. If the client provides connection logs, check the target domain or process, the matched rule, and the final outbound route. Labels vary by software, so go by what the setting actually does.
- ✅ Browser: Check whether a proxy extension overrides the system settings, run a fresh IP lookup, and inspect the connection log for the test domain.
- ✅ Desktop app: Quit and reopen it, perform an action that requires a network connection, then check whether its process or target domain uses the expected outbound route.
- ✅ Terminal: Check the program’s own proxy settings and proxy environment variables. Command-line tools may not use the desktop’s system proxy settings.
- ✅ Meeting and real-time apps: Test sign-in, joining a meeting, audio, and video separately. A working sign-in page doesn’t mean media traffic is routed properly.
- ❌ Don’t assume every app is covered just because the taskbar icon is on, one webpage loads, or the client shows a route latency result.
On Windows and macOS, check system proxy settings and tunnel permissions separately. On Android, check per-app inclusion and exclusion lists, and make sure battery-saving settings aren’t stopping the client in the background. On iOS, review routing and exclusion rules in the client configuration too. A VPN icon only indicates the interface status; it doesn’t replace testing the apps you use.
If an app shows the source address for the current session, you can use it as supporting evidence, but sign-in history may take time to update. Don’t enter account credentials on unfamiliar sites just to test a connection. Don’t share debug logs containing subscription URLs, access tokens, or personal session details.
Connected but Not Working? Narrow It Down by Symptom
The browser works, but other apps connect directly
First check whether the browser is using a proxy extension on its own, then see if the desktop app supports the system proxy. If you need broader coverage, follow the setup guide to enable a tunnel mode supported by the client and grant the required permissions. Restart the app after switching modes so it doesn’t keep using an existing connection.
The exit address changed, but the website still shows the wrong location
A website may consider your account region, billing details, location permissions, cookies, and IP databases. A fresh browsing session can help rule out cached data, but it won’t change the region associated with your account. Check the exit address first, then investigate how the service determines your location. What a site displays alone doesn’t prove the route isn’t working.
Some requests bypass the route, or only real-time features fail
Check IPv4 and IPv6 separately. If the client doesn’t handle IPv6 and an app prefers it, traffic may use a different exit. A WebRTC test showing a local network address or mDNS name doesn’t mean your public IP has leaked. Check whether it exposes your network’s original public IP and whether that traffic is within the intended coverage.
Real-time features may also use UDP. Loading a webpage only shows that the relevant web connection works; it doesn’t prove real-time media will work. Check UDP support in the client, route, and current configuration, as well as the target app’s fallback behavior. Don’t assume every failure is caused by DNS.
The results didn’t change after switching routes
Check whether an old connection is still being reused, whether the switch actually took effect, and whether a rule is forcing the test domain to connect directly. Other proxies, VPNs, or security software running at the same time may also compete for routing or DNS. Keep the tools you need for testing, note your settings, and rule things out one at a time so you can identify the cause.
Takeaway: Match Evidence to the Specific Request
A useful troubleshooting record includes your network environment, client mode, selected route, target app, IP lookup results, and matched rules. If you need help, share this information—with sensitive details removed—through the Help Center. Simply saying “it says connected, but nothing loads” usually isn’t enough to distinguish DNS, routing, and server-side restrictions.
You can consider a setup working for a particular scenario when the target request uses the expected exit, DNS resolution follows the configured policy, and the app’s connection logs or functional tests confirm the result. This applies to the app and configuration you tested; it isn’t a permanent guarantee for all traffic on the device.
Verifying a connection isn’t the same as auditing privacy. VPNIz’s privacy messaging centers on “anonymous, no-logs” service. A changed exit address doesn’t verify logging practices or prevent identification through website accounts, browser cookies, or device permissions. The route determines how traffic is carried; account and app privacy settings need to be managed separately.