How can you tell whether your VPN is really working? Check your public IP first, then DNS, and finally verify the route in the apps you actually use. A status icon only means the system or client has established some kind of connection; it doesn’t mean every request is using the selected route. The goal isn’t to make every result show a different country, but to confirm that traffic follows your routing rules.
First, distinguish connection status from traffic routing
When a client says “Connected,” it may mean the system tunnel is running—or simply that a local proxy is listening. Successfully importing a subscription only confirms that the configuration was read; it doesn’t confirm node authentication, DNS resolution, or the remote connection. The interface can turn green without the network cooperating.
System proxies generally rely on apps honoring the proxy settings. TUN mode uses a virtual network interface to route traffic that matches its rules. It usually covers more traffic, but exclusions, app rules, and system restrictions still apply. A VPN icon on a mobile device doesn’t mean every destination uses the same exit.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols or protocol suites. Their names don’t prove what traffic they cover, and they’re no substitute for testing. IEPL, transit, and direct connections describe how routes are organized; they don’t prove that every app is using the VPN.
| What to check | What it can confirm | What it doesn’t prove |
|---|---|---|
| Connection icon | The tunnel or local service is running | That the target request passed through a remote node |
| Public IP | The source address a website sees for this request | That other apps use the same exit |
| DNS test | The recursive resolver used for the test domain lookup | That a leak occurred based only on the resolver’s location |
| App connection logs | The matching rule, selected outbound route, and connection result | That other destinations or later connections behave the same way |
Public IP: compare before and after, not just the location
Open the IP lookup page and note your public IP and network provider before connecting. Then connect to your chosen route and run the check again in the same browser. Keep your network unchanged during the test so a Wi-Fi switch doesn’t look like a route change.
- Check your current mode and whether the lookup site matches a proxy or direct-connection rule.
- Refresh the lookup page after connecting. If the result looks cached, check again in a new private browsing window.
- Compare the IP address, network provider, and expected exit—not just the city name.
- Open the site you actually need, then check its outbound route in the client’s connection logs.
Geolocation databases can lag, and a node name may not match the city listed for its IP address. If the IP changed and its network provider matches your expectations, a different city alone doesn’t mean the connection failed. Conversely, a change in page language or search results doesn’t prove your exit changed; account region, location permissions, and past preferences can all affect what you see.
If your IP hasn’t changed, first check whether the lookup site is set to connect directly. That may be expected in rule mode. If you understand the impact, you can temporarily route that domain through the proxy and test again, then restore the original setting. Don’t permanently disable all your routing rules just to change one lookup result.
DNS: check the resolver path, not the flag
DNS translates domain names into addresses your device can connect to. A changed public IP only confirms that the webpage request used a different exit; domain lookups may still go through your local network. A DNS leak generally means a lookup bypassed the resolver path you expected—not simply that a test showed a particular country.
Before using a DNS test page, read how it works and confirm that it triggers fresh lookups for test domains. Check which resolver handled them and compare that with your client’s DNS settings. Large DNS providers may use distributed servers, so the resolver address, its physical location, and your browser’s exit don’t have to match.
Your browser’s Secure DNS, the system’s encrypted DNS, and the client’s built-in resolver may all work differently. If encrypted DNS is enabled in your browser, lookups may use the browser’s own HTTPS connection. Whether that connection uses the proxy depends on its route. So “encrypted DNS” and “DNS always follows the tunnel” aren’t the same thing.
After changing DNS settings, old connections and cached results may still affect the test. Close the relevant pages, reconnect, and test again. If the client uses Fake-IP, an app may see a synthetic mapped address; that isn’t the real server address. Change one setting at a time so you can identify what made a difference.
IPv6 and WebRTC: check beyond the browser
Some networks provide both IPv4 and IPv6. If the client routes only IPv4, an app may connect directly over IPv6. Check the exit for each address family separately. If a lookup page doesn’t show IPv6, it only means the test didn’t return an IPv6 result; it doesn’t prove your device can’t use IPv6.
If your IPv6 route isn’t what you expect, first check whether the client supports routing IPv6 and whether the relevant routes are enabled in your configuration. You can temporarily disable IPv6 for a comparison test if you understand the impact, but that’s a troubleshooting step—not a solution for every network.
Browsers use WebRTC for real-time communication, and it may reveal network candidate addresses that differ from those used for regular web requests. A private local address or a masked local hostname isn’t the same as a public IP leak. Focus on whether WebRTC reveals a public address on your local network that should be hidden, and whether media traffic follows the expected route.
Browser extensions usually affect only some browser connections, depending on how they work. If you also need to route meeting software and desktop apps, don’t treat a browser extension’s test results as proof that the whole device is covered.
Test apps individually: a working website doesn’t mean your work apps are covered
On Windows and macOS, some apps use the system proxy, some have their own proxy settings, and others connect directly. On Linux, environment variables affect only processes that support them; they don’t automatically change every app’s routing. A successful command-line request doesn’t replace testing desktop apps.
On iOS and Android, clients typically use the system’s network extension or VPN interface. But per-app exclusions, on-demand connections, and routing rules can still change what’s covered. Interfaces vary by client, so the VPN icon at the top of the screen can’t tell you how a specific app’s traffic is routed.
- ✅ Open the target app and perform a real task—load a document, sync content, or join a test meeting—instead of stopping at the sign-in screen.
- ✅ Check the client’s connection logs at the same time. Confirm the destination domain, matching rule, and actual outbound route.
- ✅ After changing rules, quit and reopen the app so it creates new connections instead of reusing an existing session.
- ❌ Don’t assume that because a website opens in your browser, video calls, file sync, and command-line tools are also using the VPN.
Meeting apps may use different domains for sign-in, messaging, and media, and may use different transport methods. If the web app lets you sign in but media doesn’t work, check the relevant connections and UDP support separately rather than blaming DNS straight away. When sharing troubleshooting details, provide only the necessary error and rule information, and redact account identifiers and subscription details.
Connected but not working? Narrow down the cause by symptom
The browser works, but other apps still use your regular network
First check whether the app ignores the system proxy, has an exclusion rule, or needs TUN mode to route its traffic. If your device is managed by your organization, don’t override its network policies; ask your administrator which configurations are allowed.
The client is online, but nothing loads
Check whether the subscription is up to date, the node is available, the authentication details are valid, and the client supports the subscription’s protocols and configuration fields. A subscription link isn’t a webpage or a node. Even after importing it, you still need to select a node and enable traffic routing. For setup steps, see Quick Start.
The exit looks right, but a site still reports a region or access restriction
This doesn’t necessarily mean the connection failed. A site may consider your account region, IP reputation, location data, and existing sessions. Check the route used by the request first, then review the site’s message. A region restriction isn’t proof that the entire route is broken.
An app still works after disconnecting
That’s expected if the destination allows direct connections. Cached pages and content that was already loaded can also affect your results. If you want to block direct connections when the tunnel drops, check whether your client offers a kill switch and understand what it covers. Test in a controlled environment, not during a work session you can’t risk interrupting.
Wrap up: match each piece of evidence to what it covers
After testing, note your network, client mode, node, target app, and results. If you switch networks or update your rules, focus on retesting routes that previously had problems. Don’t share your full subscription link: it usually contains credentials that can be used to access your subscription. If it’s exposed, reset it using the option in your account panel.
A reliable conclusion is: “This destination followed the expected route under the current settings.” A public IP comparison checks webpage traffic, a DNS test checks resolver behavior, and connection logs plus real app activity help verify app routing. These checks complement one another, but none proves that every connection on the device is covered.
When using VPNIdea, follow the same steps to verify your connection. The service’s no-logs privacy policy doesn’t replace checks of your client’s routing, DNS, and split-tunneling settings.