How can you tell if your VPN is working? Check your public IP, DNS, and the app you want to use—not just the connection icon in your client. That icon usually means a connection or local proxy has started. Whether your browser, desktop apps, and background processes use the selected route also depends on proxy mode, routing rules, and each app’s network settings.
The most practical approach is to compare results before and after connecting, then check the client’s connection logs for the relevant requests. This guide covers general verification steps, not speed test results. Being able to open a website doesn’t prove that all your traffic is routed through the VPN. Menu names vary between clients, so refer to the interface and documentation for yours.
What the connection icon, public IP, and app access each tell you
“Connected” describes the client’s status. Your public IP shows where a particular request exits the network. An app test shows the route that app actually uses. These checks complement one another; none replaces the others. In rule-based mode, some sites may connect directly while others use the proxy—that may be exactly what your configuration is designed to do.
| Check | What it can confirm | What it can’t confirm on its own |
|---|---|---|
| Client connection status | The configuration is enabled, or the client reports that a tunnel is established | Whether every app’s requests use that tunnel |
| Browser public IP | The public IP used by requests to the test page | Whether other apps or domains use the same route |
| DNS test | The recursive resolver seen handling lookups for the test domain | The actual route for all DNS traffic or the privacy policy in effect |
| Target app and connection logs | The rule matched, outbound route selected, and any errors for a specific request | Whether every subsequent request will have the same result |
Compare your public IP before and after connecting
Start with the client disconnected, if it’s safe and convenient to do so. Use a trusted public IP lookup site to note your current public IP and its reported location. Then connect the client, select the route you want to test, and reload the same page. Check the public address reported by the site—not the local address shown in your device’s network settings.
- Note the public IP while disconnected, your network environment, and whether the lookup page reports IPv4 and IPv6 separately.
- Connect to the route you want to test and check whether the client is using rule-based mode, global proxy mode, or TUN.
- Refresh the lookup page and compare the addresses. Also check the client’s connection logs to see which outbound route was selected for the domain.
- If the address hasn’t changed, first check whether a rule sends the test domain directly, then check whether your browser has its own proxy settings.
- If only one address type changes, check whether the other is also routed through the VPN. Don’t assume all traffic is covered.
A changed public IP shows that this lookup request used a different public exit. That alone doesn’t prove it used the route you selected. A browser extension, built-in proxy, or another network tool may also have changed the route, so check the client’s logs. Conversely, if a rule sends the test page directly, an unchanged IP doesn’t necessarily mean the client has failed.
A location label isn’t the final word on where an IP address is registered. Databases can report different locations for the same address, and they may update at different rates. If the IP changed but the location looks wrong, compare other trusted lookup sources and your client’s route information. Don’t keep switching routes to guess, and don’t assume an exit location determines a website account’s regional eligibility.
DNS leak tests: check the resolver path, not just the country label
DNS translates domain names into addresses that apps can connect to. Routing an app’s connection through a proxy doesn’t mean its DNS queries take the same route. The system resolver, a browser’s encrypted DNS, and the client’s built-in resolver may all be involved. If a result is cached, the current visit may not trigger a new external DNS query at all.
Reputable DNS test sites typically use temporary test domains and check which recursive resolvers contact their authoritative servers. The results show information about those resolvers; they aren’t a packet capture of all traffic from your device. A difference between the resolver’s location and the exit country doesn’t, by itself, prove a leak. Distributed public DNS services can also affect location labels.
The more useful question is whether DNS behavior matches your configuration. If certain domains are meant to use a specified remote resolver, but tests repeatedly show a local ISP resolver and the connection logs show direct DNS requests, investigate further. If your rules are designed to resolve local domains locally, that result isn’t necessarily a problem.
- Check the client’s DNS mode, domain-routing rules, and whether it intercepts system DNS requests.
- Check whether your browser uses custom encrypted DNS. This may bypass the system resolver, but not necessarily the proxy’s outbound route.
- After changing settings, run a fresh test and review the new results. If needed, restart the relevant apps so they don’t keep using old results.
- Compare DNS query logs with connection logs. If the client doesn’t provide the relevant details, be clear about what you can’t confirm.
A DNS leak test checks whether DNS queries follow the expected route. Encrypted DNS doesn’t guarantee trustworthy results, that every app is routed through the VPN, or that your activity can’t be identified.
Test apps individually: a working browser doesn’t mean desktop apps are routed too
Apps that respect the system proxy usually use it automatically. Others may use their own networking libraries and ignore it. Command-line tools may read proxy environment variables or rely on their own settings. TUN and other virtual network adapter modes can route more traffic, but coverage still depends on routes, exclusions, address types, and how the client is implemented. Don’t assume they capture every connection.
Before testing, decide what you need: should a particular app access a service in a selected region, or should all supported traffic use a specified exit? The right rules depend on your goal. Don’t route services that should connect directly through a proxy just to make a test page show an overseas address.
How to check browsers and desktop apps
- Check your public IP in a browser. Also look for proxy extensions or separate proxy settings that could override one another.
- Open the target app and trigger a clear network request, such as refreshing content or reloading an account page. Don’t rely on a cached home screen.
- Look for the relevant process or domain in the client’s connection logs. Check the matched rule, actual outbound route, and any connection errors.
- If the app is reusing an old connection, quit it completely and reopen it before testing again. Switching windows usually won’t make an existing connection choose a new route.
- If the app works only in a specific mode, note the mode and rule differences, then adjust settings according to the client’s documentation. Don’t change everything at once.
The VPN icon on a mobile device is just one system status indicator. Android clients may let you include or exclude specific apps; on iOS, coverage depends on the client and system configuration. On Windows, macOS, and Linux, check for other proxy apps, virtual network adapters, and routes that may also be active. The same platform doesn’t mean every client supports the same features.
Why a VPN can look connected while traffic takes a different route
The subscription was imported, but the route isn’t working
A subscription link provides configuration; importing it successfully doesn’t prove that a remote connection works. Some clients show a running status once the local proxy service starts, even if the selected node can’t connect. First check whether the subscription needs updating and whether the right node is selected. Then look for authentication, handshake, or timeout errors. Don’t share subscription links, access tokens, or full configurations containing credentials.
Rule-based mode sends the test page or target domain directly
Rules select a route based on conditions such as domain, address, or process, depending on what the client supports. The test page may connect directly while the target app uses the proxy. Check which rule actually matched. If you temporarily switch modes to compare results, restore your original settings afterward. Global proxy mode doesn’t necessarily route every kind of traffic at the system level.
The exit has changed, but the app still shows the old region
An app may also consider your account region, payment details, device location permissions, cached data, or its own access policies. Your public IP is only one signal. Check the request route first, then consult the app’s official regional rules. A location label that hasn’t changed doesn’t automatically mean the VPN isn’t working. Don’t assume a particular route will guarantee access to specific content.
Web pages load, but voice, games, or background connections fail
Web browsing and real-time communication may use different transport methods. Differences in UDP support, client rules, and the target service’s requirements can all affect the result. The protocol name—Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or TUIC—can’t tell you whether an entire app will work. Check the actual configuration, client support, and error logs.
Similarly, IEPL, relaying, and direct connections describe network architecture or traffic routes; they don’t determine whether the client routes traffic from your device. The route type alone can’t prove that DNS is being resolved as expected or that an app has selected the correct outbound route.
A repeatable verification checklist
Change only one relevant setting at a time, and note your network environment, client mode, and target app. This makes it easier to tell whether a change came from the route, a rule, or the app itself. Don’t treat faster page loads as your only evidence: caching, content size, and the destination server can all affect perceived speed.
- ✅ Recorded the public IP before and after connecting and checked the available address types.
- ✅ Confirmed which rule and outbound route handled the test request, rather than relying only on the location label.
- ✅ Checked whether DNS results match the resolver policy and considered the browser’s separate settings.
- ✅ Triggered a new request in the target app and checked the connection logs or app error messages.
- ✅ Distinguished routing issues from account-region settings, location permissions, and content policies.
- ❌ Didn’t treat a connection icon, one test page, or a successful visit as proof that every app is covered.
Bottom line: To confirm your VPN is working as intended, build an evidence trail: the public IP matches expectations, DNS follows the configured policy, and the target app uses the correct outbound route. If you can only test the browser, draw conclusions only about the browser. If logs are unavailable, be clear about what remains unverified.
When using Y6VPN, start by checking your setup with the client guides, then run the tests above. If you still can’t identify the issue, submit a support ticket with your client and operating system, network environment, error message, and the checks you’ve already tried. Before sharing screenshots, hide usernames, subscription credentials, and any address details you don’t want to disclose. Include details that help troubleshoot the specific request.