How to Check Whether Your VPN Is Really Working: A Complete Guide to Checking Your Exit IP and DNS

To confirm that a VPN is really working, do not rely only on the client's “Connected” status. This usually means the client has completed a handshake with the remote node, but it does not necessarily mean that browser, command-line, and other app traffic has entered the selected route. A reliable check starts by recording your exit IP before connecting, then querying it again after connecting while also checking DNS requests and the actual paths used by different apps.

If your exit IP has changed, at least some network requests are passing through the remote route. If DNS is still handled by the local network, or an app shows the same exit IP, the issue may involve routing rules, the system proxy, tunnel permissions, or the app's own proxy settings. Work through the checks below from simplest to more advanced.

Exit IP is the most direct place to start

Your exit IP is the public address visible to the destination website. Before connecting, requests usually go directly through your current network. Once a route is connected and correctly handling traffic, requests first reach the remote node, which then accesses the destination website. The visible exit address and region will therefore usually change.

Start by opening QvVPN's IP Lookup page and recording the displayed address, network provider, and region. Then connect to your chosen route and refresh the lookup page. To avoid cached results, reopen the page or run the check in a private window. If the results differ and the post-connection region matches the selected route, browser traffic is probably using that route.

Disconnect the route in the client and disable any proxy extension that may be enabled separately in your browser.
Open the IP lookup page and record the current exit address and region.
Connect to the chosen route and wait until the client clearly shows that the connection is complete.
Reopen the lookup page instead of relying on the stale result in the original page.
Compare the exit address, region, and network provider information before and after connecting.

How to interpret the result: A changed exit address proves only that the current lookup request used a different path. It does not by itself prove that DNS, other browsers, background processes, and every app are using the same route.

Why the route is connected but the exit IP has not changed

The most common reason is that the client has configured only the system proxy while the current app does not follow it. Some command-line tools, game launchers, virtual machines, and apps with independent network settings bypass the system proxy. Browser extensions may also override operating-system settings, causing different browsers on the same device to use different paths.

Another possibility is split routing. Rules may send local websites, local network addresses, or specific apps directly. If the lookup site matches a direct-connection rule, the result will not change. Temporarily switch to global mode for diagnosis, then restore split routing and inspect the relevant rules rather than relying on global mode long term.

✅ Use the same lookup page before and after connecting, and refresh the result deliberately.
✅ Check whether the client is using global mode, rule-based routing, or a route limited to selected apps.
✅ Pause browser extensions that modify proxy settings before comparing results.
❌ Do not treat the connection duration shown in the client as proof that traffic is being handled.
❌ Do not determine the exit location solely from webpage language or the region of search results.

Continue by checking whether DNS resolution is using the correct path

Before accessing a domain, a device usually resolves it to a reachable address. DNS handles this process. Even when web traffic uses a remote route, DNS requests may still be sent to a resolver designated by the local network. This is commonly called a DNS leak. It may not prevent websites from loading, but it can reveal queried domains to the local resolver and may produce results inconsistent with the exit region.

During testing, observe which DNS service is actually being used after the route connects, rather than checking only the address entered in system settings. The client may forward DNS through the tunnel or enable encrypted DNS; the browser may also use its own secure DNS setting and bypass the client or operating system. The system, client, and browser layers must therefore all be considered.

What to check	Expected result	Warning sign	Check first
Exit IP	Matches the region of the selected route	Still shows the current local network	Proxy handling, routing rules, browser extensions
DNS service	Handled through the client-defined path or remote route	Still resolved by the local network provider	DNS mode, browser secure DNS, system cache
Different apps	Uses direct access or the route as expected	Works in the browser but not in other apps	System proxy support, tunnel mode, app-specific settings
Recovery after disconnecting	Network returns to its original exit and resolution paths	Domains cannot be resolved after disconnecting	Residual proxy settings, virtual network adapter, DNS configuration

How to interpret DNS test results

The resolver shown by a test page does not necessarily belong to the same network as your exit IP, and that is normal. Public resolvers, encrypted DNS, and forwarding on the remote node can show different organizations. What matters is whether the DNS path changes as expected before and after connecting, and whether the resolver still clearly belongs to the current local network.

If the browser has its own secure DNS enabled, it may send queries directly to the service specified by the browser. That does not necessarily mean the client has failed; it means the browser is controlling the DNS path independently. To test the client's DNS handling, temporarily disable the browser's independent resolver setting, reconnect, and run the test again. After diagnosis, choose the DNS layer that best fits your privacy and compatibility needs.

Why system proxies and tunnel mode produce different results

Many desktop clients offer a system proxy and tunnel mode. A system proxy changes the operating system's proxy entry point, so apps that follow it hand their requests to the client; apps that do not read system proxy settings may continue to connect directly. Tunnel mode typically uses a virtual network interface to handle more traffic, making it more compatible with programs that do not support system proxies. It requires the relevant system permissions, however, and may conflict with other network tools' routing.

This explains a common pattern: the browser shows a changed IP, while command-line downloads, games, or development tools still use the original exit. Browsers generally support system proxies, whereas some tools establish connections directly. Conversely, a browser with its own proxy extension may work independently even when no route is connected at the system level.

The protocol name does not determine traffic coverage

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC describe how data is transmitted between the client and server. They affect handshakes, transport methods, and network adaptability, but they do not automatically determine whether every operating-system app is covered. Coverage depends on how the client sends local traffic into the protocol connection—for example, through a system proxy, virtual network interface, app-level proxy, or routing rules.

A successful protocol handshake therefore does not mean that every request has entered that protocol. During diagnosis, separate the question of whether the remote connection is established from whether local traffic is being directed into it. The first usually fails as an inability to connect to the node; the second more often appears as a normal client status with an unchanged exit IP or only some apps working.

Choosing a mode: If you only need a browser and apps that follow the system proxy, the system proxy is easy to control. If you need to cover apps that ignore proxy settings, check whether the client supports tunnel mode. After switching modes, verify the exit IP and DNS again instead of checking only the connection status.

Verify apps one by one to find where routing works only partially

If the browser check is normal, verify each app involved in your actual workflow. Do not assume that software on the same device shares exactly the same network path. Browsers, terminals, gaming platforms, virtual machines, and containers may each have independent proxy, DNS, or routing environments.

Test your primary browser first: Check the exit IP with the proxy extension disabled, then enable it again and repeat the test to see whether the extension overrides system settings.
Test another browser next: If the results differ, compare their proxy extensions and secure DNS settings first.
Check command-line tools: Find out whether the tool reads the system proxy or has its own proxy environment configured. Do not infer terminal traffic from browser results alone.
Check virtual environments: Virtual machines and containers may use independent gateways. The host system's proxy configuration is not necessarily passed into them.
Test the target app last: Quit it completely and reopen it so that it does not continue using a session created before the route changed.

Long-lived connections can easily distort the diagnosis. Some apps established a connection before the route changed and continue trying to reuse that session afterward. The client may already be handling new requests while the old session has not been rebuilt. Quit the app, disconnect the route, reconnect, and then launch the app to create clearer test conditions.

✅ Record the browser, target app, and DNS results separately instead of treating them as one conclusion.
✅ Fully restart the target app after changing routing rules so that old connections are closed.
✅ Check rule order and make sure a broad direct-connection rule has not matched first.
✅ Verify virtual machines and containers independently within their own network environments.
❌ Do not conclude that the target app is using the route just because the client's traffic counter is increasing.

Common cases where the VPN shows “connected” but is not working

The subscription was imported, but the node configuration was not updated

A subscription link provides node and rule information to the client. A successful import only means that the client read the configuration; it does not guarantee that the current node can connect or that later changes have synced. If node information looks wrong, manually update the subscription, select the route again, and check the exit IP. If you edited the configuration yourself, also check whether the client has overwritten those local changes.

Routing rules send the target domain through a direct connection

Rule-based mode chooses a path based on domains, address ranges, apps, or other conditions. If the target service matches a direct-connection rule, the client can still show a connected status while the request bypasses the remote route. Temporarily use global mode for comparison. If global mode works, the issue is usually in the rule set, rule order, or domain matching rather than the node itself.

A browser proxy extension overrides system settings

An extension can send browser requests through another proxy or set them to connect directly. The browser may therefore produce completely different results from other apps on the system. Disable the extension first and test through the system path, then enable the extension separately. This makes it clear which layer controls browser traffic.

Multiple network tools modify routing at the same time

When two clients enable a system proxy or virtual network interface simultaneously, the later-starting software may overwrite the earlier settings, and route priorities may change. During diagnosis, run only one network tool. Once the exit IP and DNS are working normally, restore the other tools one at a time. This is easier than repeatedly changing nodes and helps identify the source of the conflict.

An old state remains after sleep or a network change

After a device wakes from sleep or switches from one network to another, the client interface may still show a connected status even though the underlying connection has failed. Disconnect and reconnect manually. If nothing changes, quit and reopen the client, then check again whether the system proxy or virtual network interface has been restored.

What to check on different platforms

On Windows, focus on residual system proxy settings and whether the virtual network interface used by tunnel mode is working correctly. After an abnormal client exit, the system proxy may still point to a local port that is no longer running, making websites inaccessible even after disconnecting the route. Reopening the client and disconnecting normally is usually safer than deleting network settings directly.

Different macOS clients may use the system proxy or a network extension. If all required permissions have not been granted, the interface may still allow subscription imports and node selection while handling traffic only partially. Confirm in Network settings that the relevant configuration is enabled, then test browsers separately from apps that do not read the system proxy.

Mobile clients typically establish a tunnel through the VPN interface provided by the operating system. If app-based routing is also enabled, confirm that the target app is included in the rules. After switching networks, reconnect and retest the exit IP and DNS to rule out interference from an old network session.

Linux environments vary considerably. Desktop apps may read proxy settings from the graphical environment, while command-line tools may depend on their own configuration or environment variables. When using a virtual network interface, also check that the client has updated routes and DNS correctly. Even if the browser test succeeds, verify the terminal tools you actually use separately.

Build a repeatable verification process

A reliable check should include a baseline, post-connection results, the DNS path, and app-level results. Record the exit IP while disconnected, then retest after connecting to the chosen route. Next, check whether DNS is still handled by the local network. Finally, open the app you actually need and confirm that it is not bypassing the route through a direct-connection rule or independent setting.

If the exit IP and DNS both match expectations but the target service still does not work, the issue may not be whether the client is working. It may involve the service's own policies, route quality, account region, cache, or app session. Reconnecting repeatedly is unlikely to help; shift the investigation to the target app while keeping the network conditions already confirmed as working.

Bottom line: “VPN working” should mean that the expected app's exit and DNS paths match the current configuration, not merely that the client displays a connected status. The exit IP confirms the public network path, DNS testing confirms the resolution path, and app-by-app checks confirm routing and coverage.