Many users see 'Connected' in the client, but when they open a website, the exit IP is still local, or pages load slowly. This isn't magic — 'connection status' and 'traffic routing' are two different things. A green light only means the VPN handshake succeeded. What actually determines whether your traffic goes through the tunnel is the routing table, DNS resolution, and whether each app really hands its data to the proxy process.
This process requires no networking expertise. Follow it and you can pinpoint the problem within five minutes.
Step 1: Check Your Exit IP Location
IP is the most direct indicator. If you selected a Hong Kong server, your exit IP should be in Hong Kong; if you selected Los Angeles, it should be in the US. If the IP location is still your home city, your traffic never entered the tunnel.
Steps:
- Connect to the VPN on your computer or phone.
- Open any IP lookup site (ip.sb, ipinfo.io, ifconfig.me all work).
- Compare the country/region shown with the server region you selected.
If you're a command-line user, one command gives you the result:
curl ifconfig.meThe output is your current exit IP. Use whois or an IP database to look up its location.
Note: IP location is determined by the ISP's address database. City-level accuracy may vary, but country/region level is generally reliable. If the country doesn't match, stop here and fix the routing issue first.
Note: Some servers use a relay + exit structure. The exit IP may be in the relay node's region or the exit node's region, depending on the setup. The criterion is always whether this IP belongs to the target region covered by your subscription plan, not which city it's in.
Step 2: Check DNS Resolution
Your IP may go through the tunnel, but DNS doesn't necessarily. If DNS requests still go to your local ISP, you'll see the strange phenomenon of 'IP in the US but hijacked DNS results' — this is called a DNS leak.
How to verify:
- On the device connected to the VPN, open system network settings and check the current DNS server address.
- Ideal state: the DNS server should be one assigned by your VPN provider, or an encrypted DNS you configured manually.
- If DNS is still 192.168.x.x or your ISP's default address, DNS isn't going through the tunnel.
From the command line, use dig or nslookup to query a test domain and observe the returned DNS server:
nslookup example.comA more rigorous approach is to visit a DNS leak test page, which checks DNS resolution paths over both IPv4 and IPv6 and lists all DNS request sources it receives. If your local ISP's name appears in the list, you have a leak.
Step 3: Verify App by App
Global proxy ≠ all apps use the proxy. This is the most common misconception.
Many apps ignore system proxy settings and use their own network stack. Typical examples:
- Game clients (especially online games with mainland China servers)
- Voice call apps (use UDP)
- Some mainland China video apps (direct connection is actually faster)
Verification steps:
- First, identify which app you want to 'accelerate'.
- In the VPN client, find the 'per-app proxy' or 'split tunneling' settings.
- Add the target app to the proxy list and unwanted apps to the direct list.
- Restart the app and check its exit IP again.
If you're using a client imported via a subscription link, the split tunneling rules are usually in the subscription config. Rule syntax varies by client, but the basic logic is 'domain/IP range → proxy or direct'. Remember to save and reconnect after changes.
Four Typical Cases of 'Connected but Not Working'
Here are the four most common cases of 'light on but not going through', with corresponding troubleshooting directions:
| Symptom | Cause | Troubleshooting |
|---|---|---|
| Browser IP changed, but an app still shows local IP | The app doesn't use the system proxy | Add the app to per-app proxy in the client |
| IP check is fine, but pages load slowly | Exit IP is flagged as a data center by CDN | Switch to another server in the same region |
| Only some sites are accessible | Split tunneling rules put the target domain in direct | Check the rules and change that domain to proxy |
| IP check in browser is fine, but WebRTC reveals real IP | WebRTC bypasses the proxy and sends UDP directly | Disable WebRTC in the browser or install a protection extension |
After troubleshooting, use this checklist to quickly verify:
- ✅ Exit IP location matches the selected server region
- ✅ DNS server address comes from the tunnel, not your local ISP
- ✅ Target app has been added to the per-app proxy list
- ✅ IPv6 is disabled, or IPv6 also goes through the tunnel
- ✅ Browser WebRTC check doesn't reveal your real IP
Verification Priorities by Scenario
Different scenarios have different verification priorities. Here's a table of common scenarios and corresponding actions:
| Scenario | Primary check | Secondary check |
|---|---|---|
| Accessing international sites | Exit IP location | DNS leak check |
| Using AI tools like ChatGPT | Exit IP in target region | Risk control (page says region unavailable) |
| Streaming | Exit IP in the right region | CDN detection (can you see region-specific content) |
| Game acceleration | Latency and packet loss | UDP through the tunnel |
| Remote work connections | Exit IP stability | Per-app proxy omissions |
Conclusion: To verify whether your VPN is working, follow the three steps: exit IP → DNS → per-app. First confirm the IP location matches the target region, then confirm DNS isn't leaking, and finally confirm each target app actually uses the proxy. Only when all three pass is it truly 'working'. If any step fails, your connection status and traffic routing don't match — go back to that step and troubleshoot.