How to Verify That Your VPN Is Really Working: Check Your Public IP and DNS

How can you tell whether a connected VPN is really working? The “Connected” label alone is not enough. It usually means the client has completed a handshake or established a session with the server; it does not prove that browser, download tool, and other app traffic is using the expected route. A reliable check starts by recording the original network state, then verifying the public IP and DNS, and finally testing each app separately.

These checks do not depend on a particular protocol. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC, and system-managed VPN configurations can all show a client online while target traffic stays outside the route because of proxy mode, split-tunneling rules, permissions, or app-level settings. A successful protocol handshake is only the starting point; the traffic path is what matters.

What “Connected” actually proves

A connected client usually means the local client can communicate with the remote node, the authentication details are valid, and a protocol session has been established. Clients do not all define this state the same way: some show a successful connection as soon as the handshake completes, while others wait until the system proxy, virtual adapter, or routing rules have been applied.

Connection status and traffic capture are therefore two separate checkpoints. The first asks whether the client can reach the node; the second asks whether requests from a specific app enter that route. If the system proxy was not applied, virtual adapter permissions did not take effect, split-tunneling rules selected a direct connection, or the app bypassed the system proxy, the status can look normal while the public IP remains unchanged.

Where to look	What it can prove	What it cannot prove on its own
Client connection status	A session between the local client and node has been established	That every app is using the node
Public IP lookup	Which public address the current request leaves from	That other apps use the same route
DNS query results	Which resolvers handle domain lookups	That web content requests definitely use the same route
Target-app testing	That the app can complete a real request under the current rules	That every other app on the system is also captured

When troubleshooting, distinguish a proxy client from a system-level tunnel. A browser proxy usually handles only programs that follow the system proxy settings; virtual-adapter mode captures more traffic at the network layer but can still be affected by routing tables, exclusion rules, and local network protections. A changed public IP in one app does not prove that every connection on the device has changed.

Step 1: Compare your public IP and location

Your public IP is the most direct place to start. Disconnect the route, open a trusted IP lookup page, and record the public IP, network owner, and approximate location. Then connect to the route you want to test, close and reopen the lookup page or force-refresh it, and check whether the result changes.

Disconnect the route in the client and confirm that the network has returned to its normal connection state.
Look up the current public IP and record the address, network owner, and location.
Connect to the node you plan to use and wait for the client to apply the proxy or routing settings.
Run the lookup again; do not rely only on a result that was already loaded in an old tab.
Compare the public addresses before and after connecting, and check whether the new address matches the expected location of the selected route.

✅ The public IP changed and its ownership broadly matches the target route. Continue by checking DNS and the app path.
✅ The IP changed but the location shows a nearby city. Cross-check with another source instead of treating one geolocation database as definitive.
❌ The public IP did not change at all. First check proxy mode, virtual-adapter permissions, system proxy settings, and split-tunneling rules.
❌ The browser’s public IP changed while other apps did not. The current setup may be capturing only the browser or programs that follow the system proxy.

IP geolocation databases can be slow to update, and the same address may show different cities across lookup services. During verification, focus on whether the public address changed, whether the network ownership makes sense, and whether the country or region matches expectations. Do not treat a city-level label as precise location data. If sources disagree, compare their results with the region-specific content returned by the target website.

Conclusion for this step: A changed public IP proves only that the specific request used a different exit. It is necessary evidence, but not sufficient proof that every connection on the device is using the route.

Step 2: Check whether DNS follows the expected path

Before visiting a website, a device usually resolves its domain name to a reachable address. If content requests use the route while DNS is still handled by the original network’s resolver, the local network’s lookup path may be exposed, and access may fail when the DNS result does not match the exit region. This is commonly called a DNS leak.

Run DNS tests both before and after connecting, then compare the resolvers’ network ownership and location. Seeing a resolver commonly associated with the local network after connecting does not immediately prove that content traffic bypassed the route, but it does mean the DNS path needs further review. A more reliable setup lets the client manage DNS as designed and keeps DNS handling consistent with the proxy rules.

DNS results do not need to match the public IP’s exact city. A provider may use public resolvers, anycast resolvers, or remote forwarding, and the displayed organization may differ from the node operator. The warning signs are an unchanged DNS path before and after connecting, resolvers clearly belonging to the original network, or persistent results that conflict with the target region under different rules.

Browser encrypted DNS changes what the test means

Some browsers can use their own encrypted DNS. When enabled, the browser may bypass the operating system’s default resolver settings and send requests directly to the DNS service configured in the browser. A web-based test then shows the browser’s DNS path, which may not represent other apps on the system.

During troubleshooting, first check whether the browser has independent DNS enabled, then choose the test target. To inspect system DNS, use a tool that follows system settings; to inspect the browser’s actual path, keep its current settings. Do not repeatedly switch configurations during the test, or the before-and-after results will no longer be comparable.

Verification order
Disconnect the route → record public IP and DNS
Connect the route → recheck public IP and DNS
Check browser-specific DNS → test the browser again
Check the client’s DNS policy → test other apps again

Step 3: Verify split tunneling rules app by app

After checking the public IP and DNS, return to the apps you actually need to use. Modern proxy clients usually support rule-based routing: local sites connect directly, selected domains or network ranges use the proxy, and local network addresses remain direct. Rule-based mode is not designed to send every request through the same exit, so a website still showing the original exit may reflect an intended rule—or a missing rule.

The clearest test is to temporarily compare global proxy mode with rule-based mode. If the target app changes its exit in global mode but not in rule-based mode, the issue is usually rule matching, rule order, or an app bypass setting. If the exit still does not change in global mode, continue by checking the system proxy, virtual adapter, routing conflicts, and client permissions.

Capture boundaries across platforms

On desktop platforms, the system proxy mainly affects apps that follow the system proxy interface. Some download tools, developer tools, and game platforms have their own proxy settings and may connect directly. Virtual-adapter mode can cover more IP-based connections, but routes must still be applied correctly, with local networks, private addresses, and DNS handled properly.

On Android and iOS, clients typically create a tunnel through the system-provided VPN interface. If per-app routing or app exclusions are enabled, excluded apps continue using the original network. The system also allows only the currently active tunnel configuration to capture the relevant traffic, so after switching clients, confirm the current configuration rather than relying on the previous client’s history.

Browser extensions usually affect web requests in that browser only and cannot represent other programs. Command-line tools may also read their own environment variables, such as HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY. When testing API requests, developers should check the terminal environment, app settings, and client rules together.

✅ Send real requests separately from the browser, target app, and command-line tool, and check the exit for each.
✅ In rule-based mode, confirm that the target domain matched a proxy rule rather than the default direct-connection rule.
✅ In virtual-adapter mode, check system authorization, route installation, and DNS capture status.
❌ Test only with a browser extension and conclude that every program on the device uses the same route.
❌ See traffic from the client and assume that the target app’s requests have been captured.

Conclusion for this step: Whether the setup works must be determined by the target app’s real requests. In a split-tunneling setup, different apps can correctly use different exits, but every difference should be explainable by a rule.

Route type affects where to troubleshoot

With a direct route, the client connects to the target node directly, so the path is relatively simple. If the handshake succeeds but the exit does not change, focus on local proxy mode, routing, and app settings. A relay route connects to an entry point first, then the relay network forwards traffic to the exit node; the client sees the entry session, while the website should see the final exit address.

IEPL is commonly used to describe a route design with dedicated or controlled transport between the entry and exit. Its main distinction from ordinary public-network relaying is the intermediate transport path; it does not make local app routing correct automatically. Whether the setup uses a direct route, relay, or IEPL, verification is the same: check the final exit, DNS path, and target-app requests.

Protocol names cannot replace path verification. Shadowsocks and Trojan are commonly used as proxy protocols; VMess and VLESS depend on the client core and transport settings; Hysteria2 and TUIC use QUIC-style transport and are more sensitive to connection conditions on a given network. Their encapsulation, authentication, and transport differ, but after the client reports a completed handshake, you still need to check whether the system sends target traffic into the corresponding session.

Route or mode	Exit the website should observe	Priority checks
Direct node	The selected node’s public exit	System proxy, virtual adapter, routing, and app settings
Public-network relay	The final exit node, not the relay entry point	Entry reachability, relay forwarding, and exit configuration
IEPL dedicated route	The final exit node	Local capture, entry connection, and exit mapping
Rule-based routing	Determined by the matched rule	Rule order, domain matching, and the default policy

Common cases where a VPN appears connected

The system proxy was not applied successfully

The client is connected to the node, but the system proxy is still empty or has been overwritten by another network tool. Browsers and apps that follow the system proxy will not enter the route. Re-enable the system proxy in the client and check whether the operating system’s network settings change with it.

The rule classified the target request as direct

Domain rules, network-range rules, and default rules have a priority order. If the target domain first matches a direct-connection entry, later proxy rules will not process it. Check the client’s connection log or rule-match details to confirm which rule was actually used, rather than merely checking whether the domain appears somewhere in the rule list.

The app has its own proxy settings

Some apps do not follow the system proxy or retain an old proxy address internally. Others use their own network stack and DNS. If the browser works but a specific program’s exit does not change, check that program’s network options first, then consider switching to virtual-adapter mode.

The subscription was updated, but the current node was not reloaded

A subscription link provides node and routing configuration to the client. After importing or updating a subscription, some clients need you to select the node again and reconnect before using the new configuration. Seeing a newer subscription timestamp does not prove that the current session has switched to the updated exit.

An old session remained after switching networks

When a device switches from one network to another, existing connections may break or wait for recovery. The client interface may not refresh immediately. Disconnect and reconnect manually, then repeat the public IP and DNS checks instead of judging the session by its state before the network switch.

WebRTC results were misread

A browser’s WebRTC test may show local-network candidate addresses, masked candidate names, or public candidate addresses. Seeing a private local address does not mean the public exit stayed the same. Distinguish local-network addresses from public addresses reachable over the internet, and assess WebRTC results alongside a standard public-IP lookup.

A repeatable verification checklist

Use the same sequence after initial setup, switching clients, changing split-tunneling rules, or changing networks. A fixed process helps identify which layer changed instead of repeatedly switching nodes by trial and error.

Disconnect the route and record the original public IP and DNS path.
Connect to the target node and confirm that the client completed the handshake and system capture.
Look up the public IP again and verify the address, network ownership, and expected region.
Run a DNS test and check whether the original network’s resolvers are still clearly in use.
Send separate requests from the browser, target app, and any necessary command-line tools.
When rule-based mode behaves unexpectedly, compare it with global mode and inspect the rule that actually matched.
Repeat the full check after the network environment or configuration changes.

If the exit does not change, start with the system proxy, virtual adapter, and routing. If only some apps remain unchanged, start with app-specific settings and per-app rules. If the exit is correct but domain access is abnormal, start with DNS, browser encrypted DNS, and the rule-based resolution method. Troubleshooting layer by layer is more effective than repeatedly changing protocols.

Final assessment: A connected client indicates only a session state. You can confirm that the current use case is working only when all three checks pass: the public IP matches expectations, the DNS path is explainable, and the target app uses the correct exit under the applicable rules.