How can you tell if your VPN is working? Compare your public IP before and after connecting, check where DNS requests are going, and then test the apps you actually use. A “Connected” status usually means the VPN connection is established—not that every app or domain is using the selected route.
This guide uses repeatable checks that don’t depend on whether a particular website loads, and treats location labels as clues rather than definitive proof. You’ll need your VPN client, a browser, and the app you want to test. Keep the same network throughout; changing networks, servers, and rules at the same time makes it hard to identify what fixed the issue.
Connection status vs. actual traffic
First, work out what the client is routing. Some clients use the system proxy and handle mainly apps that follow its settings. Others use a virtual network adapter or system VPN interface to route traffic according to system rules. The interfaces may look similar, but coverage can differ. If your browser uses the VPN, that doesn’t prove your games, terminal, or other apps do too.
Split tunneling can change the results further. Some domains may connect directly while others use the proxy; app-based rules may send only selected programs through the tunnel. If a test page matches a direct-connection rule, seeing your usual IP may be expected—not a sign that the VPN has failed. Before testing, note the current mode and the rule for the domain you’re checking.
| Check | What it can tell you | What it can’t prove on its own |
|---|---|---|
| Client shows connected | The client reports that a connection has been established | That all app traffic is using the VPN |
| Public IP address changed | This test request used a different exit IP | That other apps and DNS requests use the same route |
| DNS test results | Clues about the resolvers involved in the test | That the resolver’s location is where your browsing traffic exits |
| App connection logs | Which rule matched the request and how it was routed | That the destination platform will allow access from that exit IP |
Judge results against your setup: with full-tunnel routing, check which traffic is covered; with split tunneling, check whether the target app matched the expected rule. Split-tunnel traffic doesn’t have to show the same exit IP for every request.
How to compare your public IP before and after connecting
Your public IP is the source address a website sees when it receives a request. The local address assigned to your device by your home router isn’t the public exit IP you’re checking here. The security icon in your browser’s address bar only indicates an HTTPS connection; it doesn’t prove your traffic is using a VPN.
- Disconnect the VPN client, open our IP check page, and note your public IP, network provider, and displayed location. If the page shows IPv4 and IPv6 separately, record both.
- Connect to the selected route, confirm the routing mode, and reload the test page. Don’t rely on results left over from an earlier check.
- Compare the IP addresses and check the network provider information. Location databases may lag behind, so a city name that doesn’t match isn’t enough to conclude the VPN isn’t working.
- Verify the result with an independent test source. If the results differ, check whether the requests matched different split-tunneling rules or used different IP versions.
- Disconnect and run the test again to see whether the IP returns to its original value. Keep a record of both results so you can reproduce the issue.
If the IP hasn’t changed, first check whether the test request is supposed to use the VPN. If the logs show a direct connection, review your rules. If they show the proxy but the result still looks wrong, check for a browser-specific proxy, extensions, existing connections, and client error messages. Don’t keep switching routes just because the displayed location hasn’t changed.
If your IPv4 exit changes but IPv6 still shows your local network, check IPv6 routing separately. The client may handle only some IP traffic, or a rule may send IPv6 directly. Check the client’s IPv6 support and routing documentation before changing settings; disabling IPv6 isn’t a one-size-fits-all fix.
DNS testing: A different resolver doesn’t automatically mean a leak
DNS translates domain names into network addresses. A DNS test typically asks your browser to look up a test domain, then uses what the test service observes to infer which recursive resolvers were involved. This offers clues about the lookup path; it isn’t a complete record of every program’s DNS traffic on your device.
A DNS leak occurs when lookup requests that are expected to use a particular route actually take a different one. Whether that’s a problem depends on your intended setup. If your browser uses its own encrypted DNS, seeing a different DNS provider may be expected—and the encrypted DNS connection itself may use the VPN. The resolver’s name or country alone can’t tell you which route the traffic took.
- Check the client’s DNS settings. Confirm whether DNS lookups should be resolved remotely and whether domains connecting directly use a separate resolver.
- Review your browser’s Secure DNS setting, which may override system DNS. Check it alongside the client’s DNS policy instead of changing only the system DNS address.
- Keep the network unchanged and compare test results with the VPN disconnected and connected. Seeing a resolver provided by your local network after connecting is a clue worth investigating, but confirm it against the logs and configuration.
- Use a new test domain or run the test again. Cached results may prevent a new lookup, leaving results incomplete or unchanged.
Encrypted DNS protects queries between your device and the resolver; it doesn’t automatically change where your web traffic exits. Likewise, routing web traffic through a proxy doesn’t guarantee that every DNS request uses it. Check “who resolves the domain” separately from “where the connection exits.”
Don’t enter an unfamiliar DNS address just to get a particular test result. Incorrect settings can prevent domains from resolving or disrupt direct connections. Save your original settings before making changes, and check the client’s documentation for supported DNS options.
Test individual apps—not just your browser
A browser test only reflects that browser’s request. To check whether the apps you use are routed correctly, start a fresh network request in the app itself and check the client’s connection list or logs. If the client shows rule names and outbound labels, confirm whether the request used a direct connection or the selected proxy route.
On desktop, system proxy settings in Windows and macOS don’t make every app follow them automatically. Terminal programs may use proxy environment variables—or ignore them entirely. Linux desktop proxy settings aren’t a universal entry point for every process either. Virtual network adapter mode often covers more IP traffic, but routing rules, exclusions, and client capabilities still matter.
iOS and Android clients may route traffic through the system VPN interface, but the exact coverage depends on the configuration. Android clients may let you include or exclude specific apps. Don’t assume the steps for one platform apply to another. If an app maintains a persistent connection, reconnect it after changing routes before testing again.
- ✅ Open the app you want to use and perform a real network action—don’t just check a cached page.
- ✅ Find the corresponding request in the client logs and check its domain, rule, and outbound route.
- ✅ Check whether app-specific proxy settings, browser extensions, and the system proxy are overriding one another.
- ✅ After changing modes, reconnect the app and repeat the test on the same network.
- ❌ Don’t treat one website loading as proof that the VPN covers every device and app.
Some apps don’t show their public IP. In that case, use connection logs, matched rules, and app behavior together, and be clear about what the evidence covers. A destination website may deny access because of account status, regional policies, or the reputation of the exit IP—not necessarily because your local VPN connection isn’t working.
Troubleshooting: connected, but traffic isn’t using the VPN
Start by checking whether the traffic reached the client, then find out where it went. This is more useful than repeatedly refreshing your subscription or switching routes. Change one thing at a time, make a new request, and record the result so you can pinpoint the cause and restore your settings if needed.
- Make sure the configuration is selected. Importing a subscription link only adds a configuration; it doesn’t mean you’ve selected a route or enabled traffic routing. Check the active configuration, selected route, and connection errors. Subscription links contain access credentials, so don’t share them in public screenshots or discussion forums.
- Check the system routing mode. In system proxy mode, make sure the proxy is enabled. In virtual network adapter mode, check permissions and routing status. Other network tools may change these settings, so avoid having multiple tools compete to handle traffic during testing.
- Check which rule matched. If the target domain connects directly, review rule order, app exclusions, and the default outbound route. Temporarily changing modes can help identify the cause, but it’s not a reason to route all traffic through the same path indefinitely.
- Confirm DNS resolution. If the logs show a resolution failure, check the DNS route first. A working public IP check doesn’t mean the target domain will resolve correctly.
- Check that the outbound route works. If the request reaches the proxy but the connection fails, check the route, network, and client compatibility. An error message alone can’t confirm the route topology or a server-side problem.
- Review all the evidence. After making changes, retest the exit IP, DNS, and target app. Don’t ignore an issue that remains just because one check is now passing.
The protocol name alone doesn’t prove that a connection works. Whether Shadowsocks, VMess, Trojan, VLESS, or other configurations can route traffic successfully also depends on client support, transport settings, and server configuration. Labels such as direct, relay, or dedicated line don’t replace checking the IP seen by your device; an IP location label can’t reveal the exact route topology either.
Browser IP exposure: What test results can and can’t tell you
Some test tools also show WebRTC addresses. WebRTC is used for real-time communication, and its connection path may differ from ordinary web requests. Distinguish local network addresses, privacy-protected local addresses, and public addresses. Seeing local address information doesn’t prove that your public traffic is bypassing the VPN.
If a test shows an unexpected public IP, check your browser’s policies, the client’s support for that traffic, and your routing settings. Installing a stack of extensions isn’t a reliable fix: extensions may affect only the browser or conflict with existing proxy settings. Retest with the actual app after making changes.
These checks show the route used at the time of testing; they don’t prove that it will stay the same. It’s worth checking again after changing networks, updating the client, editing rules, or importing a configuration. A changed IP isn’t a privacy guarantee: account logins, website cookies, and app permissions can still reveal information about your identity.
Bottom line: Confirm that the evidence agrees. You can conclude that the VPN is working for a particular use case when test requests that should use the VPN have the expected exit IP, DNS routing matches your configuration, and the target app uses the correct outbound route. If your evidence comes only from a browser, limit your conclusion to that browser rather than assuming all apps are covered.