How can you tell whether your VPN is really working? Check your public IP first, then DNS, and finally test each app. A “Connected” status is only the starting point: access is working as intended only when the target app’s requests use the expected route.
When testing, don’t switch nodes, change rules, and tweak browser settings all at once. Record your baseline before connecting, change one setting at a time, and retest the same page in the same app. This makes it easier to distinguish routing issues from split tunneling and cached connections.
Connected, routing traffic, and successful access: what’s the difference?
“Connected” may mean that a tunnel is established or simply that a local proxy is running, depending on the client. Some clients use the system proxy and only handle apps that follow that setting. Others route traffic through a virtual network interface, but their behavior can still depend on routing, exclusion lists, and split-tunneling rules.
Protocol names such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC don’t, by themselves, tell you whether the whole device is routed through the VPN. Check the client’s operating mode, system permissions, and the route taken by the app’s actual requests. In some clients, “Global” means all proxy rules point to the proxy—it doesn’t necessarily mean every app is routed through the client.
| What you see | What it tells you | What to check next |
|---|---|---|
| The client shows “Connected” | The client has entered a connected state | Whether the target request reached the client and connected successfully |
| The browser’s public IP has changed | The public IP used by that browser request has changed | Whether other apps and IPv6 use the same route |
| A DNS test shows a public resolver | The test domain was handled by the corresponding DNS resolver | Whether the DNS request followed the configured route |
| The target app works | The current task can access the service | Whether the expected rule matched, rather than the connection simply succeeding directly |
Public IP: compare before and after connecting
Use a trusted public IP lookup page to record your current IP, noting whether it shows IPv4 and IPv6 separately. You’re checking your public IP, not the local address shown in your device’s network settings. After recording it, connect the client and run the same check in the same browser.
- Disconnect the client and note your current network, the public IP shown on the lookup page, and the network information associated with it. If the page doesn’t show an IPv6 result, record that IPv6 wasn’t detected; don’t assume the device has no IPv6 connectivity.
- Connect to the node you want to test. Make sure the system proxy or virtual interface mode is enabled as described by the client, and grant any required system permissions.
- Reopen the lookup page rather than relying on an old tab. Check the client’s connection log too, to see whether the lookup request matched a proxy or direct-connection rule.
- Compare the addresses, then check the target website. If the lookup request matched a direct-connection rule, an unchanged address may be expected with split tunneling. Try a different test destination or temporarily use the client’s global proxy rules to check again.
IP geolocation is based on databases that may be out of date. A mismatch between the exit city and the node name doesn’t prove the connection has failed. Conversely, page language, search results, and your account’s region aren’t evidence of your exit location; they may depend on account details, location permissions, or past preferences.
A lookup page only shows the route used by that particular request. If a browser extension sets up a separate proxy, the browser’s result won’t represent desktop apps, let alone the whole device.
DNS: check the resolution route, not just the location
DNS translates domain names into IP addresses. DNS test pages typically ask your browser to look up new test domains, then show which recursive resolvers handled the queries. The results usually show the resolvers’ public-facing network information, not the complete route from your device to them.
If all DNS queries are supposed to go through the client but the test shows resolvers from your local network, check for DNS bypass. However, seeing a familiar public DNS provider or a resolver in another country doesn’t automatically mean there’s a leak. Public DNS services may use distributed infrastructure, and clients may use remote resolution, encrypted DNS, or synthetic addresses.
Check browser DNS and system DNS separately
A browser’s Secure DNS setting may work independently of the system’s DNS settings. Encrypted DNS protects the contents of DNS queries in transit, but whether those queries go through the proxy depends on the connection route and rules. Don’t assume “encrypted” means “routed through the intended connection.”
Read the client’s DNS setup guide first, then compare its settings with the browser’s Secure DNS and system settings. Run a new test after making changes. Cached results may prevent a fresh DNS lookup, so use a new test on the diagnostic page instead of repeatedly refreshing an ordinary website. Don’t enter unfamiliar DNS addresses just because a test looks unusual.
Some clients use Fake-IP, temporarily mapping a domain to a synthetic address before handling the connection themselves. In that case, the address shown by system tools may not be the website’s real IP; that alone doesn’t mean DNS has been altered. Check the client logs, matched rules, and final access result together.
IPv6 and WebRTC: check for traffic that may bypass the VPN
Routing IPv4 through a proxy doesn’t mean IPv6 follows the same route. If your network and apps support IPv6 but the client only handles IPv4, some requests may use your regular network instead. Check the test results for each protocol and confirm how the client handles, bypasses, or blocks IPv6. Don’t just look at the most prominent address on the page.
If the IPv6 route isn’t what you expect, first adjust the client’s routing settings according to its documentation. If the client explicitly doesn’t support IPv6, you can temporarily disable IPv6 for the relevant network to compare results, once you understand the impact; then restore it and choose a suitable configuration. Before making a lasting change to system network settings, check that it won’t disrupt normal network services.
WebRTC supports real-time communication in browsers, and WebRTC tests can sometimes reveal a different route from regular web requests. Seeing a local IP address or a masked host identifier doesn’t mean your public IP has been exposed. Look for an unexpected public IP, and consider your browser’s privacy settings and the client’s UDP support.
Don’t disable every real-time communication feature just to make a test page turn “all green.” Changes may disrupt meetings and calls. First identify what the unexpected address represents, then make a targeted adjustment.
Test apps one by one—don’t stop at the browser
Not every app follows the system proxy. On Windows and macOS, browsers and desktop apps may use different network settings, while command-line tools may read their own proxy configuration. VPN permissions on iOS and Android don’t rule out app exclusions or on-demand connection rules. On Linux, pay particular attention to the differences between desktop proxy settings, terminal environment variables, and system routes.
When testing an app, look for its domain, process, or connection entry in the client and check the matched rule and route. Not every client shows process details, and not every mode shows domains. If the logs don’t provide enough detail, check the system settings and the app’s proxy documentation too; a missing log entry doesn’t prove the app connected directly.
- ✅ Browser: Check proxy extensions and Secure DNS, look up your public IP again, then open the site you actually need to access.
- ✅ Email and office apps: Reconnect, test sending, receiving, or syncing, and check whether the relevant connections match the expected rules.
- ✅ Video calls: Test sign-in, joining a meeting, and audio and video separately. A website loading successfully doesn’t prove that the UDP route used for real-time media is working.
- ✅ Command-line tools and background tasks: Check each tool’s own proxy settings. Don’t assume a browser test also applies to terminal programs.
- ❌ Don’t treat a direct connection to websites in mainland China as a failure by default. With rule-based routing, that may be exactly what you configured.
After switching routes, existing long-lived connections may continue using the old route for a while. Save your work, then quit and reopen the target app; sign in again if needed. Test the task you actually need to do, not just whether the app’s home screen loads.
Troubleshooting: narrow down the cause by symptom
The browser works, but other apps behave the same
First check whether you enabled only a browser extension or whether the target app ignores the system proxy. If the client offers a virtual interface mode, enable it according to the official instructions and test again. Also check the app exclusion list. Don’t bypass organization policies on managed work devices; ask your administrator to verify the setup.
Your public IP changed, but the target website still blocks access
That doesn’t necessarily mean the proxy has failed. The service may restrict access based on account region, the reputation of the exit IP, location permissions, or its own rules. First confirm that the target request matched the proxy, then check the website’s error message. A single unavailable service doesn’t prove that all traffic is bypassing the route.
The displayed result doesn’t change after switching nodes
Check whether the lookup page matched a direct-connection rule and whether the browser is reusing an existing connection. Reopen the app and make a new request; if needed, cross-check with another trusted lookup page. Different nodes may share a public exit IP, so seeing the same address isn’t enough to conclude that the connection failed.
Nothing can connect, or the client can’t see any nodes
Disconnect the client first and check that your regular network can access the internet. Then check that the subscription is valid and the node list is up to date. A subscription link is a credential for importing connection settings, not a website to browse directly. Import it into a compatible client and update the configuration. A successful import only means the settings were read; you still need to select a node, connect, and run the checks above.
IEPL, transit, and direct connections describe how a route is set up; they don’t replace checks on your device or automatically ensure that DNS and every app use the expected route. If problems persist, see Troubleshooting or contact Customer Support with a redacted description of what you observed.
Keep test records, and protect your connection credentials
Useful troubleshooting notes include your operating system, client, connection mode, node, target app, matched rule, and what changed between tests. You don’t need to share your full public IP. Before sharing screenshots, hide account details, subscription links, access tokens, and unrelated requests.
Don’t paste your subscription link into unfamiliar online testing or conversion tools. If the link is exposed, use the reset or revoke option in your service dashboard, if available, and reimport the configuration into your client. Deleting a chat message won’t invalidate credentials that have already been copied.
YuanVPN’s privacy policy states that it keeps “no logs.” This is a statement about the service’s policy, not a substitute for checking permissions, DNS, and routing on your device. Service connections, browser behavior, and app settings are separate layers and should be verified separately.