How can you tell whether your VPN is working? Checking your IP shows the exit used by the current request. A DNS test helps you check whether lookups follow the expected path, and you should also test the apps you actually use. A client showing “Connected” usually means the connection is up, but it doesn't prove that your browser, games, and work apps all use the same route.
In short: A thorough check confirms that your exit IP matches expectations, DNS follows your settings, and the app you're testing uses the intended rule. With split tunneling, some traffic may correctly use your local connection. A changed IP on every website is not the only measure of success.
Check the mode first: a connected status doesn't confirm an app's route
“VPN” can mean a system-wide tunnel or a client that provides a local proxy port. They handle app traffic differently. A system proxy tells compatible software to send requests through the proxy; it doesn't take over every connection on the device. Some games, command-line tools, and background processes may ignore the setting.
Tunnel mode typically uses a virtual network interface to route traffic that matches its routing rules, but app exclusions, direct-connection rules, DNS settings, and IP version handling can still differ. “Global proxy” often means that requests entering the client use the selected proxy route; it doesn't necessarily mean every app is covered. Check separately which requests enter the client and which route they take once there.
A subscription link imports nodes and related settings into a client. Successful import doesn't mean the system proxy or tunnel is enabled. Shadowsocks, VMess, Trojan, and VLESS are proxy protocols or protocol families; their names alone don't tell you which apps on your device are covered. Check the current mode and configuration before troubleshooting the route.
Before testing, note the selected node, proxy mode, and current network. Change only one setting at a time so you can tell which adjustment made a difference.
Check your public IP: compare the results before and after
Choose a reputable public IP lookup site. Note the result while disconnected, then connect to the route you want to test and check again in the same browser. Record the full address and the network provider reported by the lookup site, not just the flag. IP geolocation databases can lag behind, and the city they show may not be where the server is physically located.
- Establish a baseline. Save your public IP while disconnected and note whether you were on home Wi-Fi, an office network, or mobile data.
- Connect and test again. Make sure the node is selected, enable the proxy or tunnel mode you need, and reload the lookup page. If necessary, start a new browser session.
- Check the route used. Review the client's connection logs to see whether the lookup domain used the proxy or connected directly. In rule-based mode, the site may be routed directly.
- Check IP versions. If the lookup tool supports it, check your public IPv4 and IPv6 exits separately so you don't verify only one route.
If your IP stays the same after connecting, the proxy may not be enabled—or the lookup site may simply be going direct. Temporarily routing the lookup domain through the proxy is more useful than repeatedly switching nodes. If the IP changes, that only proves this browser request used a different exit; it doesn't show that other apps are using it too.
If your IPv4 exit changes but your IPv6 address still belongs to your local network, check whether the client routes IPv6 and whether your configuration allows it to connect directly. That's a routing coverage issue, not necessarily a DNS leak. Don't treat permanently disabling an IP version as a universal fix before you know the cause.
Check DNS: follow the lookup path, not just the location
DNS translates domain names into addresses that devices can connect to. A DNS leak usually means that queries expected to use a protected route were sent another way—for example, directly to a resolver on the local network. Routing web traffic through a proxy doesn't automatically route DNS queries the same way. The actual behavior depends on the client, browser, and system settings.
Use a reputable DNS leak test and compare the resolvers it reports before and after connecting, then check those results against your client's DNS policy. Test pages usually trigger lookups through dedicated domains and show the recursive resolver exits they observe. This isn't a complete record of every DNS request made by your device.
A resolver appearing in your local region doesn't by itself prove a leak, and one appearing overseas doesn't guarantee that the client handled DNS. Public DNS services may use anycast, and location databases can be inaccurate. Better evidence includes who initiated the query, which resolver received it, what transport was used, and whether the request followed the expected route.
A browser's Secure DNS setting may bypass the system resolver and use an encrypted DNS service independently. So it's not unusual for browser test results to differ from system tools. Encrypted DNS protects DNS queries in transit; it doesn't automatically hide the public IP used for web requests. Check your routing rules to see whether the DNS connection itself uses the proxy.
What system commands can—and can't—tell you
On Windows, use the command below to check whether the system can resolve a domain. example.com is used here as a documentation example; it isn't a VPN testing service.
Resolve-DnsName example.comOn macOS or Linux, if the relevant tools are installed, use the commands below to inspect the lookup result and the server reported by the tool:
nslookup example.comA successful command only shows that DNS resolution worked at that moment. It doesn't prove the query went through a proxy or that your browser uses the same settings. If the result shows a local forwarder or virtual address, check the client configuration to understand its upstream route before treating it as a problem.
Don't disable security software or reset all network settings just to make a test page turn green. Save your current settings first, identify what the browser's Secure DNS, system resolver, and client DNS each control, and then make reversible changes.
Test apps individually: a working browser doesn't mean every app works
Test with the apps you actually need to use. Browsers, desktop apps, and games may use different network interfaces, proxy settings, or transport protocols. If a website loads but a desktop app fails, first check whether that app is routed through the proxy rather than assuming the node is unavailable.
Open the client's connection log, then trigger a fresh network request in the app you're testing—for example, refresh a remote list or load a page that isn't cached. Check the domain or process, matched rule, selected exit, and any error message. Restarting the app may close existing connections, but save any work in progress first.
- ✅ Browser: Check the system proxy, any separate proxy extensions, and Secure DNS settings to make sure they aren't overriding one another.
- ✅ Desktop apps: Check the app's own proxy settings. If it doesn't support the system proxy, consult the client documentation to see whether tunnel mode is appropriate.
- ✅ Games and real-time communications: Check whether the current configuration handles the required traffic. A browser test can't replace testing these apps directly.
- ✅ iOS and Android: Check the system connection status and the apps covered by the client settings. Also check whether another network tool is taking over the connection.
- ✅ Windows, macOS, and Linux: Confirm which client and configuration are actually running. Platform support doesn't mean every client's default behavior is the same.
Avoid letting multiple proxy tools change system settings at the same time. Browser extensions, the system proxy, and a tunnel can create overlapping routes, so your exit may differ from what you expect. Start with one clear test path, then re-enable other tools one at a time if needed.
Common issues and troubleshooting order
The issues below are organized by observable symptoms. The possible causes are leads to investigate, not definitive diagnoses. Check the connection logs first, adjust the routing scope next, and only then consider switching routes.
| Symptom | Possible cause | Check first |
|---|---|---|
| IP address hasn't changed | The lookup site is going direct, or the browser isn't using the proxy | The rule matched for the lookup domain and the browser's proxy settings |
| Web pages load, but an app fails | The app bypasses the system proxy, or its traffic isn't covered | The app's proxy settings and the client's connection logs |
| DNS test differs from system results | The browser resolves DNS independently, or the system uses a local forwarder | Secure DNS settings and the client's upstream DNS policy |
| Exit location matches, but the platform is still restricted | The platform considers account details, location permissions, or exit IP reputation | The platform's message and account region; don't repeatedly rebuild the configuration |
| Some traffic still uses the local network | Different split-tunneling rules, app exclusions, or IP version coverage | The relevant process, domain, and IPv6 route |
A platform's location restriction doesn't necessarily mean the VPN isn't working. An exit IP is only one factor platforms may consider. Don't mistake browser location permissions for your public IP either: device location and IP geolocation come from different sources. Check the network route and the platform's response separately.
IEPL, relay, and direct connections describe how routes are set up; they don't replace the checks above. Even if the underlying route is working, an app that isn't routed through the proxy won't use it. Switching route types won't automatically fix an incorrect routing rule.
Keep evidence: make your results easy to review
After testing, record your network environment, client version, node name, proxy mode, the rule matched by the lookup site, and what happened in the target app. If you contact support, share a redacted error message and relevant connection logs. These details are more useful for troubleshooting than simply saying “it connects but doesn't work.”
Before taking screenshots, hide subscription links, account credentials, and access tokens. Share your public IP and connection logs only when necessary. Subscription links may contain access credentials; don't submit them to unfamiliar online converters or testing sites. A test site can observe your browser's exit without needing your subscription details.
Bottom line: First check whether the app's traffic enters the client, then confirm that the exit and DNS follow the rules, and finally test the target service. This order helps distinguish configuration and DNS issues from platform restrictions—and keeps normal split tunneling from being mistaken for a failed connection.