Is Your VPN Really Working? A Beginner’s Guide to Checking Your IP and DNS

Check Whether Your VPN Works: Test Requests, Not Just the Connection Icon

Is your VPN actually working? Your public IP and DNS are good places to start, but a single test page won’t tell you everything. When a client says “Connected,” it usually means the local connection or tunnel is up. Whether your browser, chat app, or command-line tool uses it also depends on system proxy settings, tunnel routes, app settings, and routing rules.

Start by defining what you need: should a particular website use the proxy, or should most network requests from your device go through the tunnel? Rule-based mode may allow some sites to connect directly—that may be exactly what you want. Treating every request using a different exit IP as the only sign of success can make normal split tunneling look like a problem.

A thorough check answers three questions: where does the request go out, which resolver handles the domain, and does the app you’re using follow the same route? Follow the steps below to record a baseline, compare results after connecting, and troubleshoot each part. There’s no need to guess based on download speed.

Public IP: Record a Baseline, Then Compare After Connecting

Choose a trustworthy public IP lookup page. Check that it shows your visitor IP, not the website’s server address. The test site receives your request, so don’t submit subscription links, account credentials, or client configuration. IP geolocation databases can lag behind; a city name, in particular, is not precise proof of a route’s physical location.

1. Record your direct connection. In a test environment where briefly connecting directly is acceptable, disconnect the client and open the lookup page. Note your public IP, network provider, and whether the page reports results separately for different address families.
2. Note your proxy settings. Connect to your chosen node and record whether you’re using rule-based or global mode, and whether system proxy or TUN is enabled. Keep the same network throughout the test so a Wi-Fi change doesn’t affect your baseline.
3. Run the lookup again. Refresh the results or reopen the page if needed. Compare the address with your baseline, then check whether the client logged this request.
4. Cross-check your results. Repeat the test on another trustworthy lookup page. If the results differ, first check whether the two test domains match different rules—don’t assume one result is wrong.

If the address changes after connecting, the exit route for that request changed. If it stays the same, check whether the test domain is set to connect directly, the browser is bypassing the system proxy, or the client connected to a node without routing traffic through it. An IP change alone can’t tell you whether a service keeps logs, and the region shown on a webpage doesn’t necessarily match what every app sees.

DNS Leaks: Separate Resolver Location from Traffic Routing

DNS translates domain names into addresses your device can connect to. DNS test pages typically generate test domains and observe which recursive resolvers look them up. The page may show a public DNS provider or its exit location—not necessarily the server your device connects to directly, or a location shared with your proxy node.

So a difference between the DNS resolver’s region and your public IP’s region does not, by itself, prove a leak. The key question is whether queries that should follow a protected route under your current settings are instead going to your local network or ISP’s DNS resolver. Rule-based mode may intentionally resolve direct-connection domains locally, so consider the rules and their intended behavior.

1. Run a trustworthy DNS test before and after connecting. Note the resolver names and network providers, rather than relying only on the country or region shown on a map.
2. Check the client’s DNS settings. Confirm which resolution policies apply to direct and proxied domains, and whether DNS interception is enabled.
3. Check browser options such as “Secure DNS.” A browser may use encrypted DNS independently of your operating system’s resolver settings; whether those queries go through the tunnel still depends on routing.
4. Use connection logs to check the route taken to reach the resolver. If you find unexpected local resolution, adjust the configuration and test again with a fresh query instead of relying on cached results.

On Windows, the command below can show which server the command-line resolver contacts by default. Treat it as a clue, not a complete DNS leak test: your browser may use its own resolver, and a proxy may resolve domains remotely.

nslookup example.com

Some clients use Fake-IP: they return a synthetic address to the app, associate it with the original domain, then choose an outbound route. That means system tools may not show the target site’s real address. Don’t change DNS manually just because you see a synthetic result; check the documentation for your client first.

Why Your Browser Works While Other Apps Still Connect Directly

“System proxy” settings generally tell apps that honor them to use a local proxy port; they don’t force all device traffic through the proxy. A browser may follow the setting while a game, command-line tool, or app with its own network stack may not. Browser extensions can also affect only browser traffic, so they don’t indicate the connection status at the system level.

TUN mode routes traffic through a virtual network interface and typically covers more connections, but it still depends on permissions, route exclusions, DNS settings, and the client’s implementation. In many proxy clients, “global mode” means that requests already captured by the client all use the proxy outbound route. It does not mean every app is automatically routed through the client.

• ✅ Browser: Check proxy extensions, system proxy settings, and Secure DNS to make sure they aren’t overriding one another.
• ✅ Desktop apps: Look for app-specific proxy settings, then check the client’s connection list for requests from the app.
• ✅ Command-line tools: Check the tool’s own proxy options and proxy environment variables. Don’t assume browser results apply to your terminal.
• ✅ Games and calling apps: Check whether their traffic can be captured, especially UDP traffic and app-specific routing settings.
• ❌ Don’t assume every app is protected just because the client’s traffic counter is increasing; background requests alone may account for the activity.

On Windows and macOS, system proxy and TUN are often separate settings. Mobile platforms typically use the system’s VPN interface, but may still support per-app routing or exclusions. On Linux, desktop proxy settings and terminal environment variables don’t necessarily stay in sync. Menu names vary by client, so check what each setting does instead of looking for a button with a particular label.

Use Connection Logs to Check Rules and Nodes

Open the client’s connection list or diagnostic logs, then visit the target website. First check the requested domain, matched rule, outbound route, and connection result. If the request went direct, review domain rules, process rules, and the final fallback rule. If it used the proxy but still failed, check node reachability, the remote response, or restrictions on the target service.

A webpage often makes additional requests for sign-in, images, video, and APIs. The main page loading doesn’t mean those requests succeeded. If you see text on the page but can’t sign in, check which new connections appeared when the sign-in failed. That’s more useful than repeatedly switching the homepage. Browser developer tools can help identify failed domains, but the remote address shown may belong to a local proxy or an intermediate connection—not the final public exit IP.

To distinguish a rule issue from a node issue, temporarily switch traffic already captured by the client to global proxy mode and try again. If the feature works, focus on missing split-tunneling rules. If it still fails, check the client’s capture scope, node connection, and the target service itself. Restore your original routing policy when you’re done testing.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols or transport options. The client must support the configurations actually included in your subscription. A protocol name alone doesn’t prove that DNS is protected. IEPL, transit, and direct connections mainly describe how a route is organized; they don’t replace traffic capture and routing rules on your device.

Address Families, WebRTC, and Checks After a Disconnect

Your network may support both IPv4 and IPv6. If your configuration captures only one, websites that support the other may use a different exit route. If a lookup page shows only one result, don’t assume the other address family is protected too. Use a tool that tests both separately, and check the client’s routing support.

Browsers use WebRTC for real-time communication, and it may take a different network path from regular web requests. A local private address or an obfuscated local host identifier in a test is not the same as a direct public IP. Focus on whether an unexpected public address is exposed. Even if you find no issue, that doesn’t prove all traffic on your device is being captured.

Test what happens after a disconnect, too. When the remote connection drops, your computer wakes from sleep, or you switch networks, apps may reconnect or fall back to a direct connection. Test these cases only in an environment where a brief direct connection is acceptable, and check whether the client offers a connection interruption safeguard and whether it’s enabled correctly. Don’t assume the software will block network requests after a disconnect just because it’s called a VPN.

What to Do When Test Results Don’t Match

First check whether traffic is being captured, then where it goes after capture, and finally whether the remote service is available. This order helps you avoid mistaking an app that isn’t using the proxy for a node failure—and avoids changing DNS to fix a problem actually caused by restrictions on the target website.

• IP unchanged: Check whether the test domain connects directly, whether the browser uses a separate proxy, and whether system proxy or TUN is actually enabled.
• IP changed, but DNS still appears local: Check the resolver’s network, browser-specific DNS, the client’s DNS rules, and connection logs. Don’t judge by location alone.
• Browser works, app doesn’t: Check whether the app follows the system proxy, has its own proxy settings, and sends its traffic through TUN.
• Switching to global mode fixes it: Check the rules for the failed request and related domains. You don’t need to turn off all split tunneling permanently.
• No records for the target in the client: First check the client’s traffic capture scope. If logging is disabled, enable or verify it before drawing conclusions.

If you need help, share your operating system, client name, current mode, steps to reproduce the issue, and redacted connection logs. Don’t share a full subscription link, authentication token, or configuration containing credentials. Subscription links may grant access to your configuration; if one is exposed, update it using the service provider’s management options.

Find Z7VPN clients in the user panel. Sign in to access subscription and client details. After importing your configuration, verify how traffic flows on your device using this guide. For setup instructions, see Guides; for configuration questions, use the contact page.