How can you tell if your VPN is really working? Check your public IP first, then review your DNS resolution path, and finally test the apps you actually use. A client showing “Connected” only reports its connection status; it doesn’t prove that every app and domain is using the selected route.
Start by clarifying what you need: should a particular browser reach international websites, or should selected apps on your device follow routing rules? Split tunneling can send some traffic directly, so a site still showing your local IP isn’t necessarily a sign of a problem. Follow the checks below in order, changing one setting at a time so you can isolate browser, client, and app issues.
First, distinguish connection status, public IP, and app routing
The client, operating system, and destination website each show different things. A VPN indicator in the system usually means the network extension or tunnel is enabled. If the client can update its subscription, that only confirms the subscription was retrieved. Neither is direct proof that a specific webpage used the intended exit route.
| What you check | What it can tell you | What it doesn’t prove |
|---|---|---|
| Client shows “Connected” | The client reports that the connection is active or the proxy has started | All apps are routed through the proxy |
| Your public IP changes on a test page | The request from that webpage used a different exit IP | Other apps and DNS requests use the same exit |
| A DNS test identifies a resolver | The recursive resolver observed by the test request | That a leak occurred based only on the resolver’s location |
| The target app can access a service | That the feature worked at that moment | Every app connection uses the selected route |
| A streaming service shows the expected library | The platform’s region and content checks matched expectations at that time | That the route will always work in the future |
A more reliable assessment uses several pieces of evidence: the IP changes as expected, DNS behavior matches your configuration, and the target app’s connection follows the right rule. Meeting expectations matters more than simply getting an all-green result on a test page.
Check your public IP and compare before and after connecting
Your public IP is the address a destination server sees, not the local address your device uses on your home network. Search for “public IP check” in your browser and choose a tool that reports IPv4 and IPv6 separately. The test site will also receive your request, so there’s no need to enter account details or install an unfamiliar extension just to run a check.
- Record a baseline. Disconnect the client, open a test page, and note your public IP, network provider, and reported location. Keep the same network connection throughout; don’t switch between Wi-Fi and mobile data.
- Connect to the intended route. Make sure the node is selected, then check whether the client is using rule mode, a system proxy, or a device-wide tunnel.
- Make a fresh request. Refresh the test page. If it has no option to rerun the test, close and reopen it. If needed, compare the result with another test site.
- Compare the actual addresses. Check whether the IP changed, then review its registered owner and reported location. Don’t rely on a flag icon or treat the city shown on a test page as the physical location of a server.
IP geolocation databases may be out of date, and different test services can report different locations. The selected node’s name, the registration details for its exit IP, and a platform’s own location checks may not match exactly. A changed address is a useful clue, but confirm that it’s the expected exit by checking the provider’s node details and the client’s connection records.
If the test page follows a direct-connection rule, your address may not change after connecting. You can temporarily switch to the client’s global proxy mode to check again, then restore your original rules. However, “global” often refers only to routing choices within the client and doesn’t necessarily cover every app. Apps may also ignore the system proxy.
Check both IPv4 and IPv6. If one still uses an address from your original network, check how the client handles that address family. A changed IPv4 address alone doesn’t mean all network requests are covered.
Check DNS: follow the resolution path, not just the location
DNS translates domain names into addresses used to connect. Routing webpage traffic through a proxy doesn’t guarantee that DNS queries take the same route. In this guide, a DNS leak means a query that should have followed the intended protected path instead used a resolver path that doesn’t match your configuration—for example, a query sent through your local network to your provider’s resolver.
With the intended route connected, open a DNS leak test and run it. These tools typically have your browser request temporary domains, then check with the test operator’s authoritative DNS server which recursive resolvers handled the queries. The result mainly shows the resolver’s exit; it may not be the server your device contacted directly, and it doesn’t reveal the entire DNS transport path.
- Record the result before connecting. Note which DNS resolvers your original network normally uses, then compare after connecting.
- Check what your configuration is set to do. Confirm how the client resolves domains routed through the proxy versus direct, and whether DNS interception is enabled.
- Check browser Secure DNS. A browser may use its own encrypted DNS service, overriding or bypassing the system’s resolver choice. Whether that connection uses the proxy also depends on routing.
- Compare with connection records. If the test still shows a resolver from your original network, check for queries going out directly instead of assuming the test is wrong.
A resolver appearing in another region doesn’t automatically mean there’s a leak; public DNS services may use distributed infrastructure. Conversely, a resolver in the same region as the node doesn’t prove that queries were encrypted or fully routed through the tunnel. If the client uses fake-IP, giving an app a temporary mapped address is normal behavior—not your real public exit IP.
How to interpret the results: A DNS test is a troubleshooting clue, not a privacy certification. Consider the result alongside the client’s DNS settings, browser Secure DNS settings, and connection records. If you can’t confirm the path, save the results and ask support rather than treating a location label as proof.
Test apps one by one: a working browser doesn’t mean everything is covered
System proxies, browser proxy extensions, and device-wide tunnels cover different traffic. Some Windows and macOS apps follow the system proxy, while others use their own network settings. Linux apps may rely on desktop proxy settings or environment variables. Browser extensions usually affect browser traffic only, so they tell you nothing about other software.
On iOS and Android, clients often route traffic through system networking interfaces, but the apps, domains, and exclusions covered still depend on the implementation and settings. Android battery optimization may restrict background activity. After switching networks, check that the connection has recovered. A VPN icon in the system isn’t a substitute for testing.
- ✅ Run a fresh public IP check in the target browser and make sure it doesn’t have another proxy extension enabled.
- ✅ Trigger a new request in the app you’re testing—for example, run a new search or open content that hasn’t been cached—instead of checking a homepage that’s already loaded.
- ✅ If the client provides connection records, check which rule matched, which outbound node was used, and whether there were connection errors for the app or domain.
- ✅ Check what “include” and “exclude” mean in the per-app list, and make sure the target app isn’t set to connect directly.
- ✅ Test again after switching networks or waking the device to see whether the issue occurs only when background activity resumes.
DNS lookups, webpage requests, and app connections in the logs may use different domains. An app may also connect to separate services for sign-in, images, video, and updates. Seeing one domain routed through the proxy only tells you about that connection. Focus on the specific feature you’re troubleshooting and find its corresponding request.
Connected but not routing: troubleshoot by symptom
Subscription imported, but the route doesn’t work
A subscription link provides nodes and configuration; it isn’t the network tunnel itself. After importing it, you still need to select a working node and start the connection. Whether a client can parse a configuration depends on its version and implementation. Protocols such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC aren’t interchangeable, and you shouldn’t assume every client supports them. This section explains compatibility; it doesn’t mean LQVPN offers all of these protocols.
If a subscription update fails, first check that the link is complete and the client is compatible. If a node connection fails, check for authentication, connection, or configuration errors. Don’t post your subscription URL on public testing sites; it may contain access credentials.
Browser exit IP hasn’t changed, but other apps work
First check browser extensions, separate proxy settings, and which rule applies to the test domain. The reverse can happen too: the browser’s exit IP changes, but other apps aren’t routed through the proxy. Common causes include apps that ignore the system proxy or are excluded by per-app rules. Changing nodes repeatedly usually won’t fix a coverage issue.
Web pages work, but calls or other real-time features don’t
These features may use different connection methods from ordinary web pages. A WebRTC test showing a local network address or a hostname hidden by mDNS doesn’t mean your public IP has leaked. If it shows a public IP from your original network, investigate the media connection path. Whether related UDP traffic can use the proxy depends on the client, node, and routing rules.
Exit IP looks right, but streaming still shows the wrong region
A platform may also consider account region, payment details, location permissions, cached data, and the reputation of the exit IP. Reopen the app and check its region-related settings; if needed, follow the platform’s instructions for clearing cached data. IEPL, transit, and direct connections describe how routes are organized. The route type alone can’t prove that DNS won’t leak or that a particular library will always be available.
Keep a record of your checks that you can review later
During troubleshooting, note your device operating system, client name and version, selected node, operating mode, IP changes, and DNS test results. If you enable client logs, reproduce the issue before capturing the relevant entries. Before sharing them, redact usernames, subscription links, access tokens, and unrelated browsing records.
Don’t change DNS, split-tunneling mode, and nodes all at once. Change one setting, then retry in the same app you’re testing. Once the issue is resolved, revert temporary settings you no longer need. If you switched to global proxy mode for diagnosis, check the behavior again after restoring your rules.
Final check: You have stronger evidence that the VPN is working when the target request uses the expected exit, DNS resolution follows your configuration, and the app uses the right outbound route. This only describes the test results in your current environment; it doesn’t verify every app or future connection.
LQVPN users can start with the Getting Started Guide to check client and subscription setup, then review Frequently Asked Questions for settings. If you still can’t identify the issue, submit redacted records through the support ticket portal. That gives the support team more to work with than “it connects, but nothing loads.”