How to Check If Your VPN Is Working: Test Your Public IP, DNS, and App Traffic

First, distinguish a successful connection from an active route

Tools commonly called VPNs don’t all handle network traffic the same way. A system-level tunnel can take over routed traffic. A local proxy, on the other hand, often relies on apps following the system proxy settings or on the client’s virtual network adapter mode. With system proxy enabled alone, apps that ignore that setting may still connect directly.

Rule-based modes also route requests differently: some domains use the proxy, while local networks and certain websites connect directly. So “every website shows a different public IP” isn’t a universal measure of success. Start by defining what you want to test: a particular international website, a desktop app, or all supported traffic on the device? The scope of the test determines what the result means.

Check your public IP before and after connecting

A public IP is the address a website sees as the source of your request—not your device’s local address on a home network. The local address shown in your system’s network settings usually can’t tell you whether a proxy is working. Use a trusted public IP lookup page and compare results before and after connecting, in the same browser.

1. Record a baseline. If it’s safe to disconnect temporarily, check your current public IP, network provider, and address type. Use this step only to check your connection; don’t handle sensitive activity during the baseline test.
2. Connect and note the mode. Choose a server and record whether the client uses rule-based mode, global proxy mode, or virtual network adapter mode. Make sure the system proxy or relevant traffic-routing option is enabled.
3. Send a fresh request. Reload the lookup page. If needed, fully quit and reopen your browser to reduce the chance of reusing an existing connection. A private window may help limit the effect of site data, but it won’t bypass your system’s network settings.
4. Compare the client logs. If the client provides a connection list, look for the lookup page’s domain, the matching rule, and the outbound route. The evidence is more conclusive when the page result matches the client log.

If your IP hasn’t changed, first check whether a rule sends the lookup site directly; don’t assume the server has failed. If it has changed, don’t rely on the map location alone to judge the route. Geolocation databases can lag, and lookup services may label the same address differently. The network provider, address change, and outbound connection logs are more useful than a city name on a map.

If the lookup service reports IPv4 and IPv6 separately, check both. Some requests may use the proxy while traffic over the other address type still uses your local network. Whether that’s a problem depends on the client’s capabilities and the traffic it handles. Don’t check just one result and conclude that the entire device is covered.

Check DNS: look at the resolver and the route

DNS translates domain names into addresses your device can connect to. Your public IP may have changed while domain lookups still use the network’s original DNS settings. If you expect these queries to follow a specific route, unexpected traffic is worth investigating. But a DNS provider being in a different region from your server doesn’t, by itself, prove a leak.

Common DNS test pages trigger lookups for special domains, then show which recursive resolvers handled them. They typically reveal where the resolver made its outward queries—not exactly where your device sent the request. Public resolvers may use distributed infrastructure, so a location label alone doesn’t prove your device took another route.

Check browser Secure DNS separately from system DNS

Browsers’ Secure DNS features typically use encrypted DNS, such as DoH. This can operate independently of system DNS, but whether the encrypted request uses a proxy or connects directly still depends on the app, routing, and client rules. A passing browser test doesn’t mean other apps behave the same way, and seeing a public DNS provider doesn’t automatically mean something is wrong.

First note the browser’s Secure DNS setting, system DNS, and client DNS mode; don’t change them all at once. If the client logs DNS queries, make a fresh request to the domain you’re testing and check its resolver path and matching rule. Cached results may prevent a new lookup. If needed, clear the relevant cache as described by your operating system or client, then test again.

A proxy protocol doesn’t determine DNS behavior. Protocol names such as Shadowsocks, VMess, Trojan, and VLESS don’t tell you whether DNS is handled locally or remotely; that also depends on the client core, configuration, and routing rules. In Fake-IP mode, a client may return a virtual address for internal mapping. That alone isn’t evidence of DNS tampering.

Verify by app : a working browser isn’t enough

Test the apps you actually need instead of repeatedly opening the same speed-test page. Websites, desktop clients, and real-time communication features may use different network libraries and transport methods. Even one app can use different routes for different tasks.

• ✅ Browser: Open the target site, check that the page works as expected, and match its domain and outbound route against the client’s connection log.
• ✅ Desktop apps: Quit the app completely and reopen it. Try a real task, such as refreshing content or syncing files, and check for the corresponding connection.
• ✅ Meetings and calls: Test sign-in, joining a session, and audio/video separately. Signing in successfully doesn’t confirm that media traffic is routed correctly.
• ✅ Developer tools: Check the tool’s own proxy settings and the proxy variables in your terminal environment. They may differ from the system proxy settings.
• ✅ Local resources: Check that printing, local network sharing, and work intranet access still work as expected. Don’t disrupt legitimate direct connections just to capture more traffic.

On Windows and macOS, some apps follow the system proxy while others use their own settings. A VPN icon on a mobile device indicates a related network connection is active, but per-app exclusions, routing rules, and client permissions can still affect which traffic is covered. After switching platforms, check how traffic is handled again; don’t assume results from another device still apply.

Real-time media and some web requests use UDP. A system HTTP proxy doesn’t automatically handle all UDP traffic, and virtual network adapter mode depends on client, protocol, and server support. If web browsing works but calls fail, check whether the relevant traffic is being captured instead of simply changing DNS.

WebRTC tests in a browser also need context. A local network address or an mDNS-obfuscated local identifier doesn’t mean a site can see your real public IP. If the test reveals a public IP you didn’t expect, check browser permissions, the UDP route, and client logs before drawing a conclusion.

Connected but not using the route? Troubleshoot by symptom

Browser works, but other apps still connect directly

First check the system proxy’s scope, app-specific proxy settings, and exclusion rules. If you need broader traffic coverage, consider virtual network adapter mode as described in the client’s documentation. But don’t assume “global proxy” in a client automatically captures all device traffic: in some tools, “global” only means that requests already handled by the proxy core use the same outbound route.

Changing servers doesn’t seem to change the result

Check whether a browser proxy extension overrides system settings, whether another proxy tool is running, and whether a fixed rule sends the target domain through a different route. Then restart the app to rule out a reused connection. Different servers may also show the same public IP if they share an exit, so check which outbound route the client actually selected.

Public IP changed, but the service is still unavailable

That doesn’t necessarily mean the proxy isn’t working. A service may make decisions based on account region, license terms, cookies, or risk controls—or the service itself may be down. First test basic requests in a browser and the app, then distinguish a connection timeout, DNS failure, certificate error, or access denial. Don’t disable certificate verification to get around a certificate error.

Server is available, but the connection keeps failing

Successfully importing a subscription only means the client received its configuration; it doesn’t mean the server is currently reachable. Update the subscription as instructed by the provider, and check the system clock, client compatibility, and error logs. Subscription links contain access credentials: don’t paste them into public testing sites or show them in full in support screenshots.

IEPL, relay, and direct connections describe how routes are set up; they don’t confirm that an app’s traffic is being captured. Whatever route you choose, its benefits won’t apply to a request that never enters the proxy. Check the route first, then compare performance—that’s the way to find the right fit.

Retest and get help: keep evidence you can explain

When troubleshooting, keep the device, network, and target the same. Change one setting at a time, then repeat the same action. If you switch servers, change DNS and mode, and clear the cache all at once, even a successful result won’t tell you what fixed the problem. The next time it happens, you’ll be guessing again.

When asking for help, include when it happened, your operating system, client name, routing mode, target domain, error message, and steps you’ve already tried. Share only the relevant log excerpts, and hide account details, full subscription URLs, tokens, and any public IP addresses that aren’t needed. For further steps, see the troubleshooting guide or submit a question through the support ticket page.

Assess privacy separately. A VPN check verifies the route requests take; it doesn’t audit every aspect of a service’s privacy practices. VPNSweet’s no-logs policy is a statement of service policy, not an absolute guarantee you can derive from a single IP or DNS test.