A VPN showing as connected doesn’t necessarily mean it’s working as intended. Your public IP shows where a particular request exits, a DNS check reveals how a domain is resolved, and per-app testing confirms whether the software you actually want to use follows the expected route. Taken together, these checks help distinguish normal split tunneling from a setup that isn’t routing traffic.
Connection status and actual traffic are not the same thing
In a client, “Connected” might mean a tunnel has been established, or simply that the proxy service is running and a node is selected. The exact meaning depends on the client. Successfully importing a subscription only confirms that the configuration can be read. A successful node test usually confirms just that a particular check passed—not that every app will use that node.
In many proxy clients, a system proxy makes the proxy address available to apps that honor that setting. Browsers usually do, but other software may use its own network settings. TUN or system VPN mode routes traffic that matches the routing rules through a virtual network interface. It generally covers more traffic, but exclusions, routing rules, and DNS settings still matter.
Also distinguish “global proxy” from “all traffic.” In some clients, global mode only changes how requests already handled by the proxy core are routed. It won’t automatically send apps that bypass the proxy into the core. When troubleshooting, check the traffic capture method, operating mode, and app settings separately; similar-looking options aren’t necessarily the same switch.
| Check | What you can observe | What you can’t conclude from it alone |
|---|---|---|
| Client connection status | Whether the tunnel or local proxy service is running | That every app uses this connection |
| Public IP shown by a website | The public IP detected for that website request | That other apps or domains use the same exit |
| DNS check | Clues about the recursive resolver used for the test domain | That the resolver’s location is where your traffic exits |
| Client connection logs | Rules, policies, and exit choices for logged requests | That traffic outside the logs is also being routed |
| Testing the app you want to use | How the feature performs on your current network | That every network path works as expected just because the feature does |
First, compare your public IP before and after
Start by defining what you want to test: should a particular international website use the proxy, or should the entire app use the system tunnel? Choose a reputable public IP check site and note the address, time, network, and client mode. The site will receive your request; you don’t need to share a subscription link, account details, or client configuration just to check your connection.
- Record a direct-connection baseline. If it’s safe to test without a proxy, disconnect and open an IP check site. Note the public IP address and address family. If your current activity can’t risk exposing a direct connection, skip this step—don’t disable necessary protection just to run a test.
- Connect and check the mode. Select the route you want to test and confirm that the system proxy or tunnel is enabled as intended. In rule-based mode, check which rule applies to the IP check site’s domain.
- Send a fresh request. Reload the check page, or close the old tab and open a new one if needed. Note the new IP address and check whether the client logs a corresponding connection.
- Cross-check the result. Verify it with another reputable check service and compare the IP’s registration details. Location labels may differ between databases, so a city shown on a map alone doesn’t mean the connection failed.
If the address hasn’t changed, first check whether the site is set to connect directly by a rule, then see if your browser uses a separate proxy or extension. If it has changed, that only confirms the exit changed for this web request. Check IPv4 and IPv6 too: the site may show only one, while the app you care about may prefer the other.
DNS checks: trace the resolution path, not just the country
DNS translates domain names into network addresses. Routing web traffic through a proxy doesn’t automatically mean DNS requests are handled remotely; conversely, using remote DNS doesn’t prove that web traffic goes through the proxy. A client may use local DNS, remote DNS, or route DNS queries by rule. Browsers can also have their own encrypted DNS settings.
Common DNS check sites ask your browser to look up specially generated test domains, then show which recursive resolvers handled the queries. The IP addresses in the results usually belong to DNS services, not your web traffic’s exit. Public resolvers may use anycast and distributed servers, so seeing a local or unfamiliar country doesn’t by itself prove a DNS leak.
A better approach is to start with the intended configuration: which domains should use local DNS, which should resolve on the proxy side, and what route the encrypted DNS connection itself takes. Then run a check, compare the resolvers with your expectations, and review the client’s DNS logs. Investigate further if domains that should always resolve remotely repeatedly show an unexpected local resolution path.
On Windows, use the PowerShell command below to view DNS settings for your network adapters. This gives you configuration clues, not definitive proof of the path in use: browser encrypted DNS, a client’s built-in resolver, or tunnel redirection may change what actually happens.
Get-DnsClientServerAddressCheck the browser’s secure DNS settings and the client’s DNS settings separately. Change just one setting at a time and test again, so you can compare results. Clearing the cache can trigger a fresh lookup, but it won’t fix incorrect routing. Existing connections may also reuse an old address, so reopen the app you’re testing and check again.
Test each app individually—don’t stop when the browser passes
List the apps you actually use and pick a repeatable network action for each, such as opening a specific page, refreshing remote content, or connecting to a service. For every test, note the app, time, destination domain, and any matching client log entry. If logs don’t show the process name, use the time and domain to help match the request—but don’t treat timing alone as definitive proof.
- ✅ Browser: Check system proxy, proxy extensions, and encrypted DNS settings to see which configuration the browser you’re testing uses.
- ✅ Desktop apps: Check the app’s own proxy settings. If it should use the system tunnel, confirm it hasn’t been excluded.
- ✅ Command-line tools: Check environment variables and the tool’s own proxy options. Don’t use a terminal test as a substitute for testing your browser.
- ✅ Mobile apps: Confirm the system VPN connection is still active and check whether the client has per-app routing enabled.
- ✅ The feature you need: Test actual actions such as signing in and loading content. Keep in mind that they may connect to different domains.
On Windows, the WinHTTP proxy and the system proxy shown in user settings are separate configurations. You can use the command below to view the WinHTTP settings, but a direct-connection result doesn’t mean your browser is connecting directly. Don’t change the settings blindly just to make the output match.
netsh winhttp show proxyOn macOS, check network service proxies, in-app proxy settings, and tunnel configuration separately. Linux desktop proxy settings may not apply to terminal programs, which can also use proxy environment variables. Per-app settings on Android and routing options in iOS clients depend on the specific implementation; don’t assume every platform has the same menus or behavior.
Online games, voice calls, and some real-time apps may use UDP. A webpage loading normally doesn’t prove these connections are being routed too. Check whether the client and current configuration support the traffic you need, then test the feature itself. A protocol name alone can’t tell you whether a particular app will work.
Common reasons a connection may look active
The check site connects directly, but the target website uses the proxy
This is usually a difference in routing rules, not a contradiction. Check which rules and policy groups apply to each domain. A rule name is only a label, so expand the policy group and confirm which exit is ultimately selected. A subscription distributes configuration; it doesn’t guarantee that existing local rule priorities match your needs.
The browser’s exit changes, but other apps still use the original network
Start by checking which traffic is captured. A system proxy only works for apps that honor it, and an app may use its own proxy, keep an existing connection, or be excluded from the tunnel. Fully quit the app and reopen it to check a new connection. If it still doesn’t behave as expected, adjust the capture method as described by the client—don’t uninstall system networking components as a first step.
The IP changed, but the service still shows your original region
A service may determine your region from your account, previous sessions, location permissions, cached data, or its own IP database. Track network exit checks separately from the service’s region detection. Clearing site data or opening a fresh browser session may help rule out cached data, but changing your exit IP doesn’t guarantee that the service will show a different region or offer the same content.
DNS looks right, but the website won’t load
A successful DNS lookup only means an address was returned. Routing, certificates, restrictions imposed by the service, or a failed connection can still prevent the page from loading. Check your system clock and the browser’s error message, then review the client logs. Don’t ignore certificate warnings to claim a test passed, and don’t enter account details on a page unless you’ve verified it’s legitimate.
Turn troubleshooting into a reproducible record
When something goes wrong, change just one variable per test: switch the routing mode, choose a different route, or adjust one app’s proxy settings. Repeat the same action and establish a fresh connection to see what changed the result. Changing the network, client, and configuration all at once makes occasional fixes hard to explain.
When contacting support, include your operating system, client name, test time, traffic capture mode, destination domain, error message, and relevant logs with sensitive details removed. Your public IP is sensitive too; share it only when needed. Subscription URLs may contain access credentials, so don’t post them in public forums. Hide the full subscription link and account tokens in screenshots.
For help getting started with MHZVPN, see the client guides. To compare routes, browse the server directory. The number of routes and regions covered gives you options; it doesn’t prove that a particular app will work. Test your setup using the steps in this guide.