To check whether your VPN is working, compare your public IP before and after connecting, then check your DNS resolution path and test the apps you actually use. A “Connected” status only confirms that a connection state is active; it doesn’t prove that your browser, terminal, and other apps are all using the VPN as expected.
The test isn’t whether every check shows the same location. It’s whether your actual traffic follows the route set by your configuration. Split tunneling can send some sites directly, and a system proxy may not cover every app. Decide which app and site you want to test first, then review the evidence to avoid mistaking normal split tunneling for a failed connection.
Connection Status vs. Actual Traffic Routing
VPN clients define “connected” in different ways. Some indicate that the proxy core is running; others show that a virtual network interface is enabled, and some also check whether the selected server is reachable. Even when the status looks normal, rules may route a site directly, or an app may ignore the system proxy.
A system proxy provides settings to apps that support it. TUN or system VPN mode usually routes more traffic through a virtual interface, but routing rules, excluded apps, and the client’s implementation still matter. “Global proxy” in a client doesn’t necessarily mean it handles all traffic on the device: it may simply send requests that have already reached the proxy core to the selected server.
| Check | Can confirm | Cannot confirm on its own |
|---|---|---|
| Client shows “Connected” | The client reports that a connection or traffic-capture mode is active | That all apps are using the selected server |
| A website shows a different public IP | The outgoing IP changed for that website’s request | That other apps and DNS use the same route |
| DNS test results | Details about the recursive resolver used for the test query | Every DNS route used by the device |
| Client connection logs | Which rules and outbound routes matched requests handled by the client | Where traffic that never reached the client went |
For a useful diagnosis, compare website test results with the client’s local connection logs. If a request doesn’t appear in the logs, that doesn’t necessarily mean the server is at fault—the app may never have sent the traffic to the client.
Public IP: Compare Before and After Connecting
Your public IP is the address a website sees, not your device’s address on a local network. Use a trusted public IP lookup site, and check with the same browser and page each time. Note the address, network provider, and approximate location. The lookup site will receive your public IP for that request; don’t submit subscription links or account credentials.
- Disconnect the client and make sure the lookup page loads in your browser. Record your current public IP as the direct-connection baseline.
- Connect to the server you want to test, then check the client mode and active rules. Reload the lookup page, or close and reopen it, to reduce the effects of cached data and existing connections.
- Check whether the IP changed and which rule matched the request in the client. If the lookup domain is set to connect directly, adjust the test conditions before concluding that the server isn’t working.
- Disconnect again and see whether the result returns to the direct-connection route. Comparing both directions is more useful than relying on a location label from a single test.
IP geolocation comes from databases that may not be up to date. A mismatch between a server label and the city shown by a lookup site doesn’t prove the connection failed. Cross-check the network provider, the actual IP change, and client logs. An IP change also doesn’t make you anonymous: account logins, cookies, and other app data can still link activity.
DNS Checks: Resolvers and Query Routes
DNS translates domain names into addresses that devices can connect to. Common DNS test sites ask your browser to access test domains, then identify the recursive resolvers involved. The results usually show the resolvers’ outgoing network information—not your device’s public IP or the server’s location.
Use the same test site before and after connecting. Note the resolver providers and any changes, then compare them with the client’s DNS settings. If your configuration is meant to route DNS queries through the proxy but the results still show resolvers from your local network, check system DNS, DNS handling in the client, and browser settings. If your rules intentionally use local resolvers for local sites, that result may be expected.
Browser Secure DNS vs. System DNS
Browsers may use DNS over HTTPS (DoH), which can bypass the system’s default resolver. So a browser test doesn’t tell you how other apps resolve domains. DoH also doesn’t automatically mean DNS is going through the VPN: whether its connection uses the proxy depends on the app’s proxy settings and routing rules.
When troubleshooting, note the browser’s Secure DNS setting and check it against the client documentation. If you understand the impact, you can temporarily turn it off for comparison, then restore the original setting. Avoid changing browser DNS, client mode, and server settings all at once, or it’ll be hard to tell what changed the result.
A browser DNS test is not the same as a WebRTC check. WebRTC involves real-time communications and candidate address discovery. A test page showing a local address or a masked hostname is a different issue from DNS routing. Check each behavior based on the browser and client you use; don’t label every address shown as a leak.
Test Apps Individually: Browser, Terminal, and Client
A website loading in your browser doesn’t mean command-line tools can connect too. Terminal programs may need their own proxy settings or environment variables; desktop apps may have separate HTTP or SOCKS proxy options; and containers or virtual machines may use separate networks. Test from the environment you actually use, not just from a browser.
- ✅ Browser: Check for separate proxy extensions and Secure DNS, then see whether the request appears in the client’s connection logs.
- ✅ Terminal tools: Check the tool’s documentation and current proxy environment variables, such as
HTTP_PROXY,HTTPS_PROXY,ALL_PROXY, andNO_PROXY. Make sure the destination isn’t excluded by a bypass list. - ✅ Desktop apps: Check whether the app uses the system proxy or its own proxy settings. Restart it after making changes so it doesn’t reuse an old connection.
- ✅ Mobile apps: Check the system VPN status, client routing rules, and app exclusions. Then test the feature you need in the app itself.
- ✅ Containers and virtual machines: Check their internal network and DNS settings. Don’t assume the host’s test results apply to them.
On Windows and macOS, setting a system proxy and enabling a virtual interface are different ways to route traffic. On iOS, clients typically use a system network extension, but actual routing still depends on the client configuration. Android clients that support per-app routing may exclude certain apps. On Linux, check proxy environment variables for the current session and your routing settings.
If a tool uses a SOCKS proxy, also check whether it resolves domain names locally or sends them to the proxy for resolution. Tools may handle proxy address formats differently, so don’t copy settings from another app without checking. For subscription setup, see the connection guide. For proxy behavior, refer to the documentation for your client and tool.
Why a VPN Can Look Connected but Not Work
The Subscription Is Imported, but No Working Configuration Is Selected
A subscription link provides configurations such as servers and routing rules; it doesn’t turn on traffic routing by itself. After importing, check that the configuration is enabled and the intended server is selected in the relevant policy group. Updating a subscription can change server names or policy selections, so check them again. Subscription links contain access credentials—don’t post them publicly when asking for help.
A Routing Rule Sends Traffic Directly
The destination may match a direct-connection rule, an app exclusion, or a bypass list. Open the client’s connection logs, find the domain, and check the final routing policy. If needed, temporarily switch rule modes for comparison, then restore the original settings. Changing rules can help identify the issue, but it shouldn’t become a substitute for understanding the configuration.
Old Connections or Conflicts Between Network Tools
Browsers, messaging apps, and development tools may keep existing connections open. After switching servers, new requests and old connections may briefly use different routes. Quit and reopen the app you’re testing. Running multiple proxy or VPN clients at once can also cause system proxy overrides, virtual interface routing conflicts, or DNS setting conflicts. For troubleshooting, leave only the client you’re testing active.
A Service Restriction Can Look Like a Connection Failure
Your public IP may have changed, yet a service may still deny access because of your account region, login status, service policies, or the reputation of the outgoing IP. A site loading without a particular feature working doesn’t necessarily point to a bandwidth issue either. Confirm the traffic route first, then investigate service-side restrictions instead of repeatedly switching servers.
Route Types Don’t Prove a Connection Is Working
IEPL private lines, relay routes, and direct connections describe different ways traffic can be routed; they don’t prove that a connection is working. A private line is generally used for dedicated transport over a specific segment; a relay route forwards traffic through an intermediate entry point; and a direct connection usually means the client connects straight to the exit server. Check the route details provided for each service. Whatever the route type, verify the public IP and test your apps.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols or protocol families. Their names alone don’t tell you whether DNS is being routed through the VPN. Actual behavior depends on whether the client supports the subscribed protocol, the right configuration is enabled, where domains are resolved, and how traffic is routed.
For details about VPNEP routes, visit the servers page. Even after selecting a route, compare your connection before and after. Don’t treat a route name, client status, or website location label as proof on its own.
Checks and Troubleshooting Details
If the issue persists, save the test results from before and after connecting. Note your operating system, client name, current mode, server name, and target app. Say whether the issue happens during connection, DNS resolution, page loading, or sign-in. That’s more useful for troubleshooting than simply saying it doesn’t work.
When sending details through the support page, redact subscription links, passwords, access tokens, and private domains. Local diagnostic records in a client are not the same thing as server log policies. VPNEP’s no-logs policy is a privacy commitment; it doesn’t replace checking device settings or mean third-party test sites won’t process request data.
Keep a configuration that works as a fallback. Change only one setting at a time, then restore any temporary changes after testing. This makes it easier to check again if a server change, DNS setting, or app update causes an issue, instead of guessing from the connection icon.