First, distinguish connection status from actual traffic routing
How can you tell if your VPN is working? Check your public IP first, then DNS, and finally the app you want to use. A connected status only means a connection or network configuration has been established; it doesn’t prove that every app is routing traffic through the selected route.
The VPN indicator in your operating system has similar limits. Some clients use a virtual network interface to capture traffic, then route it directly or through a proxy according to rules. Some desktop clients only configure the system proxy, which means only apps that honor that setting use the route. So, seeing the VPN icon doesn’t mean it’s working for every app.
Before testing, define what you expect: should international websites use the VPN while local sites connect directly, or should a specific app use the VPN? With split tunneling, some requests may be expected to use your local network. Without this context, it’s easy to mistake normal routing behavior for a problem based on a single test screenshot.
| What to check | What it tells you | What it doesn’t prove on its own |
|---|---|---|
| Client connection status | The client has enabled a connection or traffic-routing configuration | That every app is using the VPN |
| Public IP address | The public IP used by the request you tested | That other apps or address families use the same route |
| DNS test | Clues about the recursive resolvers used for the test domain | That every domain is resolved through the same route |
| App rules and connection logs | The rule and outbound route used by a specific request | That the platform will provide content for the target region |
Public IP: compare before and after connecting
Your public IP is the address a website sees when it receives your request. It isn’t your device’s address on the local network. Choose a reputable public IP lookup page, note the result before connecting, then enable the VPN and reload the same page. Don’t rely only on the country shown—the first thing to check is whether the IP address changed.
- Pause other proxies or network tunnels, leaving only the client you’re testing. Note your current network, the public IP shown on the test page, and the client’s routing mode.
- Make sure your plan is active, refresh the subscription, and select a route that’s actually available in the dashboard. Enable the system proxy or virtual network interface required by your client; selecting a route doesn’t mean traffic capture is enabled.
- Reload the lookup page. If the address changes, check whether the client logged the request and whether it used the expected outbound route.
- If the address hasn’t changed, check whether a direct-connection rule applies to the lookup page. You can briefly switch to the client’s global proxy mode for comparison, then restore your usual split-tunneling settings.
Global proxy mode generally sends requests captured by the client through the proxy. It doesn’t necessarily capture all traffic on your device. With system proxy enabled, apps that ignore that setting may still connect directly. A virtual network interface can capture more traffic, but exclusions and supported traffic types still matter.
Check IPv4 and IPv6 separately, too. If a test page shows only one type of address, you can’t assume the other is routed the same way. If the client captures only one address family, other requests may take a different path. Check the relevant client settings first; disabling IPv6 isn’t a universal fix.
DNS leaks: check your DNS routing
DNS translates domain names into IP addresses. Web traffic and DNS queries can take different routes: a page may load through the proxy while domain lookups are still handled by your local network’s resolver. If you expect those lookups to use a particular route, this mismatch is what to investigate as a possible DNS leak.
Browser-based DNS tests usually visit test domains and report which recursive resolvers handled the lookups. They typically show the resolvers’ visible outbound addresses, not every DNS packet sent by your device. Seeing a local ISP resolver is an important clue, but its listed country alone isn’t enough to draw a conclusion.
Start by checking the client’s DNS mode: who resolves proxied domains and direct-connection domains, whether DNS interception is enabled, and whether the client uses its own mapping mechanism. Terms vary by client, so check its documentation for how the settings work. Using local DNS for local domains in a split-tunnel setup doesn’t automatically mean international traffic is misrouted.
Your browser’s Secure DNS setting may send queries through an encrypted DNS service, and some apps have their own resolvers. Encryption protects queries in transit, but doesn’t guarantee they’re routed through the proxy. To see whether the setup matches your goal, check the outbound route for that encrypted connection.
- ✅ Record the resolver names, network affiliations, and client mode before and after connecting.
- ✅ Compare the client’s DNS settings with the browser’s Secure DNS settings to identify which DNS route your test covers.
- ✅ After changing settings, reopen the app and test again. If needed, clear the DNS cache using your operating system’s instructions.
- ❌ Don’t treat a match between the resolver’s region and the VPN route’s region as proof that every app is using the VPN.
Caching can affect test results. Cached DNS records may prevent new lookups, and existing connections may continue using their original route. After changing DNS or outbound rules, start a new request and check the client’s logs. Don’t judge a new configuration using an existing connection.
App-by-app testing: check beyond your browser
A new public IP in your browser only proves that this browser request used the new outbound IP. Chat apps, media players, games, and command-line tools may use different proxy settings—or a connection type the client hasn’t captured. Test the apps you actually need to use.
On desktop systems, the system proxy is an application-level setting, not a way to capture every connection. Command-line tools may use their own proxy environment variables, while some apps ignore the system proxy altogether. Virtual network interface mode usually covers more traffic, but routes, app exclusions, and client implementation still affect what’s captured.
Mobile clients typically use the operating system’s VPN interface, but the icon doesn’t tell you whether app exclusions, domain-based routing, or DNS settings are configured correctly. iOS and Android differ in configuration, permissions, and client capabilities. Don’t assume desktop instructions apply to mobile.
- Close and reopen the app you’re testing, then repeat a consistent action—for example, load the same page or refresh the same content list. This reduces the effect of existing connections and cached data.
- Open the client’s connection logs and look for the relevant request by domain or process. Check which rule matched, whether the request used a direct or proxy route, and whether any connection errors appear.
- If the request isn’t in the logs, check whether the app bypasses the system proxy, is excluded, or isn’t covered by the current traffic-capture mode. A missing log entry may also mean logging is disabled; it doesn’t prove the request went direct.
- If the request matched a direct-connection rule, check the domain rules, process rules, and rule order. Temporarily change the outbound route to compare results, then restore the settings that suit your everyday use.
- If the request used the proxy but still failed, check for platform restrictions, account region, app cache, or a specific connection error. Avoid repeatedly changing settings unrelated to the problem.
An app may connect to different domains for sign-in, content delivery, media, and telemetry. Seeing the main site use the proxy doesn’t prove that playback requests follow the same route. Focus on the connection related to the failed action rather than treating any proxy log entry as proof the test passed.
Common reasons a VPN appears connected but isn’t working
The subscription imported, but the connection wasn’t enabled
A subscription link provides route configurations to your client; it doesn’t establish a connection automatically. After importing it, check that the route is available, the client is running, and the system proxy or traffic-capture mode is enabled. Download a client from the user dashboard, and see the quick-start guide for setup instructions.
Same protocol name, different client support
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols or solutions. Their names alone can’t tell you whether your device’s traffic is using the VPN. Your client needs to support the protocols and transport settings used by the subscription. Seeing a route in the list doesn’t guarantee that your current client version can handle all its connection parameters. Check the specific error and avoid manually assembling unknown parameters.
Split tunneling, proxy chains, or existing connections can affect results
A browser proxy extension, another network tunnel, and the system proxy may all be active at once, sending your traffic somewhere unexpected. For troubleshooting, reduce the number of active configurations, change one setting at a time, and record each result. If a test page shows your local IP again after you restore split tunneling, check the rules before assuming the VPN disconnected.
The platform still reports a regional restriction
Platforms may use your public IP, account region, payment details, location permissions, and session history to determine what content you can access. A working VPN and platform access are separate things. IEPL, transit, and direct connections describe how a route is set up; they don’t prove an app is using it or guarantee that platform content will be available.
How to determine whether your VPN is working
A reliable assessment combines several checks: the test request uses the expected outbound IP, DNS follows the configured route, and the target app’s request matches the right rule. Record the test network, client mode, route name, and the action that failed. That makes it easier to tell whether a later test reflects a configuration change or a different network environment.
Bottom line: the connection icon is just a starting point; the target request’s route is what matters. Check your browser’s outbound IP first, then DNS, and finally the target app. If only one app has a problem, start with traffic-capture coverage and routing rules. If the IP, DNS, and app logs all match expectations but the platform still blocks access, check the platform and account requirements.
A no-logs policy is a service privacy measure; it doesn’t replace device-side checks or mean that the sites you visit can’t identify your account or IP. For everyday use, also review client permissions, account security, and app settings. If you need help with a connection issue, submit a support ticket through the user dashboard with redacted error details and your test steps.