How can you tell if your VPN is really working? Don’t rely on the status icon—check the route used by the app you want to use. Compare your public IP before and after connecting, check how DNS queries are handled, then test the app itself. With split tunneling, local sites may normally use your local connection. Investigate only if traffic that should use an international route is still going direct.
Understand your routing rules before testing
A client showing “Connected” usually means its configuration is enabled or a system network interface is up. It doesn’t prove that every app is using the selected route. System proxies, app-specific proxies, and virtual network interfaces cover different traffic. A browser may use the system proxy while other apps ignore it. Virtual-interface modes usually cover more traffic, but exclusions can still apply.
VPNLJ uses split-tunneling rules to route traffic: commonly used local sites stay on the local network, while requests that need an international route use the corresponding route. So seeing a local IP on an IP-checking site doesn’t by itself mean the connection has failed. First check which rule matched the site’s domain, then interpret the result.
Before testing, note the client, selected route, operating mode, and target app. Don’t change regions, DNS settings, and configurations all at once. If you regain access, you won’t know which change fixed the issue.
Compare your public IP before and after connecting
Your public IP is the address a website sees when it receives your request. It’s different from your device’s local network address and doesn’t have to match the server address in your client’s node configuration. Some routes connect through an intermediate entry point and reach the site from a different exit. An entry and exit in different locations isn’t a fault by itself.
- Record your baseline before connecting. Pause the client, open My IP, and note your public address and the network it’s associated with. Make sure no other proxy tools are still running, or your baseline may not reflect your local connection.
- Connect and check the rules. Enable the route you want to test and review the client’s rule-match or connection logs. If the IP-checking site is routed directly, its result only confirms the direct route—it can’t show that the international route is failing.
- Run the check over the same route. If your client supports it, temporarily route the test domain through the route you want to check, or briefly switch to a mode that sends all traffic through it. Reload the IP-checking site and see whether the address changes.
- Restore your usual settings. When the test is done, switch back to split tunneling and check the app you actually need to use. There’s no need to keep temporary test settings as your everyday configuration.
Geolocation databases can lag behind, and the city shown may not exactly match the exit location. Assess address changes, network ownership, and client logs together rather than relying on a flag shown on the page. Dynamic exits may also change after reconnecting. The key is that the route behaves as expected, not that every check shows the same address.
Also account for IP version differences. A browser may prefer IPv6 while another app uses IPv4. If the client only handles one type of traffic, the results may differ. Check the client’s IPv6 support and routing settings; a single test doesn’t prove that all traffic is covered.
Check DNS, but don’t judge a leak by location alone
DNS translates domain names into addresses that devices can connect to. Routing web traffic through a VPN doesn’t guarantee that DNS queries take the same route. A DNS leak generally means that queries expected to follow a particular tunnel or resolver policy are instead sent to the local network or another unintended resolver.
Run a test on a trusted DNS leak testing site to see which recursive resolvers handle the queries. These sites usually show the resolver addresses that query their authoritative servers; they don’t reveal the full path between your device and the resolver. A resolver may use a public service, forward queries through other resolvers, or serve users from a nearby location, so its displayed region may not show where your request left the device.
- ✅ Check whether the client offers remote DNS, direct DNS, or rule-based resolver selection, and confirm which option the current configuration actually uses.
- ✅ Check your browser’s Secure DNS or encrypted DNS settings. Browser-managed DNS may bypass the client’s expected resolver policy, though whether those queries go direct also depends on how they’re routed afterward.
- ✅ Compare the resolvers before and after connecting, and check the client logs. Don’t treat the resolver’s brand or displayed location as conclusive evidence.
- ❌ Don’t assume that local DNS for local domains is a problem. Split tunneling may intentionally use local DNS for direct traffic to match its local route.
Caching can affect what you see. The operating system, browser, and apps may all retain DNS results, and existing connections may continue to be reused after settings change. Prefer a newly generated test domain from the DNS test site, and fully quit and reopen the target app if needed. Don’t blindly delete existing DNS rules just to make the results look consistent.
Test apps individually; a browser result doesn’t cover all device traffic
On Windows, macOS, and Linux, distinguish between system proxy and virtual network interface modes. A system proxy is mainly used by apps that read that setting; command-line tools, background services, and some desktop apps may use their own proxy configuration. A website loading in your browser doesn’t mean API requests from a terminal use the same exit.
On iOS and Android, the VPN icon indicates that the network configuration is enabled, but you still need to check the client’s rules. Android clients may let you include or exclude specific apps; on iOS, traffic coverage depends on the client configuration and system capabilities. Don’t assume that a desktop setting has the same name or behavior on mobile.
When testing, open the service in a browser first, then try the relevant action in its app. For AI tools, check whether a request completes; for collaboration tools, check sync; for meeting apps, test audio and video. Loading the sign-in page is only one part of the connection: background APIs, media domains, or UDP traffic may take different routes.
Browser extensions, in-app proxies, and other networking tools can also affect the results. If the browser and app behave differently, first rule out these extra factors. Pages that test WebRTC may show candidate network addresses. A local network address or privacy-masked hostname isn’t necessarily a public IP leak; check whether a public candidate address is actually exposed.
How to troubleshoot common cases where a VPN appears to be connected
| What you see | Possible cause | Check first |
|---|---|---|
| IP check still shows a local exit | The test domain is routed directly, or the app isn’t covered | Rule match for the test domain, operating mode, and app proxy settings |
| Browser works, but desktop app doesn’t | The app ignores the system proxy or is excluded by an app rule | In-app proxy, virtual network interface mode, and exclusion list |
| Web page loads, but audio or video fails | Media traffic takes a different route, or UDP forwarding isn’t available | UDP support in the client and route, media domain rules, and app logs |
| Exit changes, but the platform still denies access | Account region, content licensing, exit reputation, or platform risk controls | The platform’s error message and account status—not just the IP location |
| Results don’t change after switching routes | Reused connections, cached pages, or a separate proxy in the app | Reconnect, then check for other networking tools |
| Different test sites show different results | Different domain rules, IP versions, or geolocation databases | IPv4 and IPv6 results from each site, and the actual rule logs |
If the client has no usable routes, first sign in to the dashboard to check your plan status, then update the subscription and review the import results. A subscription link provides configuration data; it isn’t a browser-based way to access international websites. The client must also support the protocols and configuration formats actually used in the subscription. Importing a profile name doesn’t guarantee that every configuration can connect.
An IEPL label doesn’t replace these checks. IEPL describes how a route is carried; transit and direct describe how a connection is routed. Neither determines whether an app is being proxied. Even if the route itself is reachable, split-tunneling rules and device settings may still send the target app direct.
Wrap up with a checklist
A short troubleshooting log is more useful than repeatedly switching nodes. Note your device platform, client version, selected route, operating mode, target app, exact error message, and the results of your IP and DNS checks. When contacting support, share rule-match details only after removing sensitive information. Don’t send a full subscription link, password, or screenshot containing access tokens.
Repeat the same checks after changing networks, updating your subscription, or adjusting split-tunneling rules: establish a baseline, verify your exit and DNS, then test the app itself. See the service selection guide for VPNLJ’s routing information, or follow the beginner’s guide to get set up. In everyday use, check only routes you’re unsure about; there’s no need to disable split tunneling just to make every test site show the same result.