If your VPN connects but doesn't seem to work, start by checking your public IP and DNS, then test the app you want to use. A client's “Connected” status confirms the connection state; it doesn't mean every app is using the VPN. Your browser's public IP, DNS lookup path, and the region a website detects are separate things.
“Connected” vs. traffic being routed
The client may have established a connection to a server without enabling the system proxy. Or only requests that match certain rules may go through the server, while other traffic connects directly. Some clients' latency tests check only whether the server is reachable—they don't prove that your browser or desktop apps are using it.
Don't rely on the status icon alone. First check where your requests are going, then which resolver handles your domains, and finally whether the target app works as expected. In rule-based mode, regular websites in mainland China may continue to connect directly. That can be the intended behavior, not a failed connection.
| What you check | What it can tell you | What it can't prove on its own |
|---|---|---|
| Client connection status | The connection status reported by the client | That all apps are using the VPN |
| Browser public IP | The public source address for that web request | That other apps use the same public IP |
| DNS test | Which resolvers handle the test domains | That all requests go through the tunnel |
| Using the target app | Whether a specific feature works right now | That it will work on other platforms |
Exit IP Check: Record a Baseline, Then Connect
Choose a test page that shows your public IP, network provider, and IP address type. Use the same browser and page before and after connecting to keep the results comparable. If you can't disconnect temporarily, avoid sensitive activity or run the test in an environment without personal data.
- Record your disconnected status. Note your public IP, network provider, and whether the page lists IPv4 and IPv6 separately. Keep the details for your own comparison; there's no need to share your full address.
- Connect to the route you want to test. Check the selected server and proxy mode, wait for the client to confirm the connection, then reopen the test page.
- Compare the actual addresses. Don't rely on the flag alone. A change in IP address and network provider is more informative than a region label by itself.
- Check your rules and logs. If the address hasn't changed, see whether your rules send the test site directly, then confirm that your browser is using the system proxy.
IP geolocation comes from databases that may be out of date or may not match the route name exactly. A different city doesn't mean the connection failed. Likewise, a matching region label doesn't prove that every app's traffic is going through the VPN.
DNS Check: Trace the Resolution Path, Not Just the Location
DNS translates domain names into network addresses. A DNS leak generally means queries that should use an expected protected path are instead sent to a resolver over an unintended route. A changed public IP doesn't automatically mean DNS queries are using the same route.
Common DNS test sites generate test domains and observe which recursive resolvers query them. The results show the resolvers observed during the test, not a packet capture of the full path between your device and those resolvers. A resolver associated with your local provider is worth investigating, but its location alone isn't enough to draw a conclusion.
A browser's Secure DNS feature, which encrypts lookups using HTTPS or similar methods, may use a separate service. In that case, the browser's public IP and the DNS resolver may be associated with different networks; that doesn't necessarily indicate a leak. Whether queries go through the proxy still depends on what the client routes and the browser's actual connection path.
- ✅ Compare DNS test results before and after connecting, and note whether Secure DNS is enabled in your browser.
- ✅ Check the client's DNS settings and logs for fallback behavior or direct-connection rules.
- ✅ If you change DNS settings, reconnect and test again. Change one setting at a time.
- ❌ Don't assume there's a leak or connection failure just because a resolver is in a different region.
Flushing the DNS cache prompts the system to look up domains again; it won't fix incorrect routing. It may not affect apps that resolve domains themselves, either. First find out which resolver the app actually uses, then decide whether any changes are needed.
Browser works, but other apps don't
The system proxy provides an entry point for apps that follow system settings; it doesn't route every network connection on your device. Some desktop apps have their own proxy settings, some read system settings only at startup, and others don't use the system proxy at all.
TUN or virtual network adapter mode can usually route more traffic, but routing rules, exclusions, permissions, and the client implementation still matter. “Global mode” also depends on how the client defines it: it may route all requests that reach the proxy core without automatically capturing apps that bypass the core.
On Windows and macOS, check for conflicts between the system proxy, in-app proxy settings, and other network tools. Mobile VPN settings may also include per-app exclusions. Restarting the target app can make it use the current settings for new connections, but don't delete unfamiliar system network settings.
Test in the app itself: open the target page in your browser, perform a normal online action in the desktop app, then check the client logs for the relevant domain and matching rule. A successful browser test proves only that the specific browser request worked.
How IPv6, caches, and persistent connections can affect results
Your device may have both IPv4 and IPv6 connectivity. If the proxy handles only one address type, an app may prefer a route that isn't being captured. A test page that shows only IPv4 can miss this difference. Check each address type separately and confirm whether your client supports and routes IPv6.
Don't permanently disable IPv6 as soon as you spot a problem. Check the client's documentation to confirm what it supports first. If you need to change a setting temporarily, note its original value and restore it after testing. The goal is to route the intended traffic correctly, not hide a configuration issue behind a system-wide switch.
After switching routes, an app may keep using an existing persistent connection. Closing and reopening the app often helps establish a new connection more than repeatedly refreshing the same page. Browser cache, website cookies, and account region are separate state; changing your public IP won't reset them.
IP changed, but the site still shows a region restriction
Websites may determine your region using a combination of your public IP, account region, payment details, location permissions, and session history. A changed IP is just one factor. Being able to open a test page doesn't mean the target platform allows that IP to access specific content.
First check whether the target domain is actually routed through the proxy. A page, its sign-in API, and its content delivery domains may follow different rules, so it's not unusual for the page to load while a video or sign-in fails. Then check whether the error is a region restriction, an account permission issue, or a regular connection timeout. Don't lump them all together as “the VPN isn't working.”
IEPL, relay, and direct connections describe characteristics of part of the traffic path, not whether a target platform grants access. Changing the transport method doesn't necessarily change your public IP. When checking a route, verify the entry path, final exit, and result on the specific platform separately.
Troubleshoot by Symptom Instead of Reinstalling
Start by looking at how widely the problem occurs. If it's limited to one browser, check extensions, separate proxy settings, and Secure DNS. If one desktop app is affected, check its settings. If all apps are affected, check the client, system routing, and current network.
If the client can't connect to a server, check that your subscription is valid, the right server is selected, and the configuration is up to date. Subscription links contain access credentials, so don't share them on public test sites. Support for Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC varies by client. A successful import doesn't guarantee that the current core supports every server parameter.
Don't change the server, protocol, DNS, and proxy mode all at once. Even if the problem goes away, you won't know which change fixed it. Note the symptoms, change one thing at a time, and repeat the same tests and target action.
To verify that a connection is working, build a chain of evidence. Your public IP identifies the source of web requests, a DNS test helps check the lookup path, and testing the target app confirms whether it works in practice. These checks complement each other; none can replace the other two.
What to include when you submit a support ticket
If you can't identify the problem after troubleshooting, submit a support ticket through the dashboard. Include your device OS, client name and version, selected route, proxy mode, when the issue occurred, and whether it affects one app or the entire device. Before-and-after test results and redacted logs make the issue easier to reproduce than simply saying “it won't open.”
In screenshots, hide your username, subscription link, tokens, and other access credentials. Logs may also contain target domains and local file paths, so review them before sharing. Don't publish your full browsing history or complete configuration just to make the report seem thorough.
Use the VPNAct guides to check the connection steps, or consult the complete troubleshooting guide for a more systematic review. For personal assistance, submit a support ticket through the dashboard with the details above.