VPN Connected but Not Working? Check Your IP Address, DNS, and App Routing

First, understand what a connected status actually tells you

Some clients show a running status as soon as the proxy core starts. Others verify a handshake with a remote server, while system VPNs typically create a tunnel interface. Each status confirms a different stage, but none tells you by itself which route a particular app is using. The system proxy, routing table, app settings, and traffic rules determine the final route.

Being able to open a webpage and having all traffic follow the expected route are not the same thing. First decide what you need: route only selected websites through the VPN, or send supported app traffic through the tunnel. The right test depends on your goal.

Public IP: Compare results in the same browser

1. Record a baseline. Disconnect the client and check your public IP in a browser. Note the address, network provider, and approximate location. Test pages may reveal network information, so avoid sharing full results publicly.
2. Run the test again while connected. Select a server, confirm that the client has enabled the intended system proxy or tunnel mode, then reload the test page. Don’t rely on an old result that’s still displayed.
3. Check the rules. If your IP hasn’t changed, look for the test domain in the client’s connection list and check whether it was routed directly or through the proxy. If a direct-connection rule matched the test site, its result says nothing about how other sites are routed.
4. Check both IP versions. If your device has IPv4 and IPv6, test them separately. A change in one exit IP doesn’t mean traffic using the other address family is routed through the VPN.
5. Cross-check your results. Compare your address across more than one test service. Geolocation databases can be out of date. If country or city labels differ, compare the actual IP and network provider instead of relying on a map to decide whether the VPN is working.

If you use a browser proxy extension, disable conflicting extensions while testing the system client, and make a note of your original settings. Corporate networks, other VPNs, and security software can also change routing. During troubleshooting, limit changes to the network tools you’re testing, and don’t disable security measures required by your organization.

DNS: Tell normal resolution from an unexpected leak

DNS resolves domain names to the addresses needed to connect. Routing webpage content through a proxy doesn’t necessarily route DNS queries through it too. Apps may use system DNS, a browser’s secure DNS, or a DNS service provided by the client. Some connection methods send domain names to a remote resolver; others resolve them locally first.

Whether a DNS leak has occurred depends on your intended policy. If you expect certain domains to resolve through the tunnel but queries unexpectedly go to a resolver on your local network, check your configuration. On the other hand, if your rules intentionally resolve local sites locally, seeing a local resolver doesn’t by itself indicate a problem.

• ✅ Check the client’s DNS mode, upstream resolvers, and whether it intercepts DNS queries. Settings may be labeled DNS hijacking, DNS routing, or something similar.
• ✅ Trigger fresh queries on a DNS test page, compare the results with those from before connecting, and check whether the client logged the corresponding DNS requests.
• ✅ Check your browser’s secure DNS settings. Encrypted DNS protects queries in transit, but doesn’t by itself prove they went through the VPN’s exit IP.
• ❌ Don’t assume there’s a leak just because the resolver appears to be in a different country from the VPN server. Public DNS services may use distributed servers, and test results can reflect the resolver’s network location.
• ❌ Don’t switch to an unfamiliar DNS address on a whim. Check the client’s documentation first to avoid disrupting internal domain names, company services, or existing routing rules.

A DNS test page typically detects the recursive resolver handling a query for its test domain, which may not be the server your device connects to directly. Check system and browser settings alongside the client’s logs. Cached results may also prevent a new query from appearing. Run the test again rather than assuming that an empty log means something is wrong.

System proxy vs. TUN: Why only some apps use the VPN

A system proxy provides an entry point for apps that honor that setting. Browsers commonly do, but some desktop apps, command-line tools, and games ignore it or use their own proxy settings. Support for HTTP and SOCKS proxies also depends on the client and app. “System proxy enabled” doesn’t mean every connection is routed through it.

TUN mode uses a virtual network interface and routing rules to capture traffic. It typically covers more than a system proxy, but can still be affected by app exclusions, destination networks, DNS, permissions, and protocol support. It doesn’t mean that all traffic must go through a remote server. In rule-based mode, the client may still route TUN traffic directly.

Verify the route one app at a time

Quit the target app completely, connect to the VPN, and reopen the app to rule out reused connections. Then perform an easy-to-identify action, such as refreshing remote content or reconnecting to a service. In the client’s connection list, find the app process or destination domain and check the matched rule, policy group, and final server.

If the client doesn’t provide connection logs, use the target app’s own network diagnostics or trusted records of remote sessions to help verify the route. App language, recommended content, and changes in speed can’t reliably identify an exit IP. Don’t send access tokens, subscription links, or passwords to unfamiliar test tools.

On Windows, some programs use their own proxy stack. On macOS, make sure you’ve approved the network permissions required by the client. On iOS and Android, check the system VPN status and whether the client excludes specific apps. On Linux, desktop proxy settings and terminal environment variables may be independent, so test each separately.

Use system commands as a diagnostic aid—not as proof

The commands below only read relevant settings; they don’t change your network configuration. They can help explain which route an app might use, but can’t replace checking the exit IP and testing the app’s actual connection. Run commands in the appropriate system terminal; don’t paste commands for another platform.

macOS: Check system proxy and DNS settings

scutil --proxy
scutil --dns

The first command shows system proxy settings; the second shows resolvers and their scope. A proxy address only confirms that a setting exists. You still need to test whether the app honors it and whether the proxy is reachable. The system may list several resolvers, so don’t assume one entry handles every request.

Windows: Check WinHTTP and DNS settings separately

netsh winhttp show proxy
Get-DnsClientServerAddress

Run the second command in PowerShell. WinHTTP settings aren’t the same as the user proxy settings commonly used by browsers, so a result showing direct access doesn’t prove that a browser isn’t using a proxy. The DNS address list shows interface settings, but may not include browser secure DNS or the client’s internal DNS route.

Linux: Check proxy environment variables in the terminal

env | grep -i proxy

Look for proxy variables or a bypass list. No output doesn’t mean there’s no tunnel, and having variables set doesn’t guarantee that every tool reads them. Before sharing command output, redact internal addresses, usernames, and any proxy URL that might contain credentials.

Common misdiagnoses: Find the failing step

Subscription updates, but the website won’t load

A successful subscription update only confirms that the configuration was retrieved. It doesn’t confirm that a server in it is reachable or that you’re using the configuration you just imported. Check the active configuration file, selected server, and connection logs. The client must support each protocol, including Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC. Being able to open a subscription link doesn’t mean every entry will work.

The browser works, but other apps don’t

Check whether the app ignores the system proxy, has its own proxy settings, is excluded from routing, or uses traffic types that the current setup doesn’t support. Switching servers won’t fix a routing coverage issue. If the request never reaches the client, changing the exit server usually won’t help.

The exit IP changed, but the website still blocks access

A website may also consider your account region, previous sessions, location permissions, or the reputation of the exit network. Review your account and session in accordance with the website’s rules, and avoid rapidly switching locations. A changed exit IP confirms a change in network route; it doesn’t guarantee the website will accept that IP or account.

Switching to a dedicated line makes no difference

IEPL, transit, and direct connections describe how a route is delivered, not how apps are routed through the client. They won’t automatically resolve conflicts with browser extensions, DNS settings, or incorrect traffic rules. Lower latency or a faster speed test doesn’t prove that the route is correct. Verify where traffic goes before evaluating connection performance.

Draw a conclusion and prepare troubleshooting details

If you need help, provide your device’s operating system, client name, routing mode, affected app, target domain, and what changed between tests before and after connecting. Include redacted rule-match details or error logs, and note whether you use another VPN, a proxy extension, or a corporate network with specific requirements. Don’t share full subscription links, passwords, or access tokens.

Follow the same troubleshooting order: confirm the configuration and server, check traffic routing, verify the exit IP and DNS, then investigate restrictions imposed by the destination service. Change one relevant setting at a time and record the result after each test. This makes it easier to isolate the problem and avoids disrupting routes that already work for other apps.

For client installation and subscription setup, see the Guides. To learn about VPNBoat’s service and common tasks, visit the FAQ. Get the client and subscription from the account panel; availability and requirements vary by platform and are shown there.