How can you tell if your VPN is working? Compare your exit IP before and after connecting, check where DNS requests go, then test the app you actually want to use. A “Connected” status only means a connection was established; it doesn’t confirm that your browser, terminal, or other apps are using it.
First, clarify what you’re trying to achieve: route a particular website through an international connection, or send as much device traffic as possible through the tunnel? Rule-based mode may allow some traffic to connect directly, which is often expected. The checks below focus on whether the specific request follows the route you configured—not on whether every IP address changes.
Before you start testing: Record your direct-connection baseline
Pause your proxy or VPN, then open a trusted public IP lookup site in the same browser and on the same network. Note the displayed address, ISP details, and whether IPv4 and IPv6 are listed separately. Connect your client, confirm the selected route and mode, then check the same site again. Don’t switch networks and routes at the same time, or you won’t know what caused the change.
During testing, try to keep just one client responsible for routing traffic. Browser proxy extensions, system proxy settings, other VPNs, and built-in app proxies can override one another. Devices managed by an organization may also have enforced network policies, so don’t disable management components without authorization.
- ✅ Note your current network, selected route, and whether you’re using rule-based or global mode.
- ✅ Save the public IP results from your direct connection, noting IPv4 and IPv6 separately.
- ✅ Make sure your system has authorized the client to establish a VPN or enable the required proxy routing.
- ✅ Choose a website or app you actually want to use—not just a test page.
Exit IP: Check where the request is going out
A public IP lookup shows the exit address for the request to that page—not a report of all your device’s traffic. If the address changes after you connect and matches the selected route’s exit information, that’s a good sign the request is going through a proxy or tunnel. If it doesn’t change, first check which rule matched the test domain before deciding the connection has failed.
An IP’s listed location isn’t an exact physical location. Databases may update at different times, and the route’s access location may differ from its final exit location. If results don’t match, cross-check with another lookup service, but don’t assume there’s a problem based on a city name alone.
| What you see | Possible reason | Next step |
|---|---|---|
| Address changed; target site works | The test request used a different exit | Check the target app and DNS route next |
| Address unchanged; logs show a direct connection | Rules may allow the test site to connect directly | Check the rule for the target domain before switching routes |
| Address unchanged; no request in the logs | The app may not be covered by the client’s traffic routing | Check system proxy settings, app settings, and routing mode |
| IPv4 changed, but IPv6 still uses the local exit | IPv4 and IPv6 may be taking different routes | Check the client’s IPv6 support and routing policy |
| Address changed, but the target service is still unavailable | The issue may involve your account, service policies, or exit restrictions | Check the error message; don’t just keep checking your IP |
If the service already uses the same exit, switching routes may still show the same address. A changed address is useful evidence, but it isn’t required in every situation. For a more reliable assessment, compare the exit IP with your client’s connection logs.
DNS: Check the resolution route, not just the location
DNS translates domain names into addresses that devices can connect to. Test pages typically ask your browser to look up a set of test domains, then report which recursive resolvers handled the requests. The server addresses shown are usually resolvers, not the exit IP used to access a website. A difference between the resolver’s location and your route’s location doesn’t, by itself, prove there’s a DNS leak.
Whether a DNS leak has occurred depends on your expected setup. If DNS lookups are supposed to use a specific route but instead go to an unexpected local or ISP resolver, that may indicate a leak. On the other hand, a local resolver may be exactly what you want when rules allow local DNS for domestic domains. Check your client’s DNS mode before interpreting the results.
Check browser Secure DNS separately from system DNS
Your browser may use its own resolver through encrypted DNS, and some apps resolve domains independently. So changing system DNS may not affect what your browser’s test shows. Encryption only describes how a query is transmitted; it doesn’t prove the query used your selected tunnel. The actual route still depends on routing and proxy rules.
- Check whether the client handles DNS and which resolution policy applies to the target domain.
- Check whether your browser has its own Secure DNS setting enabled, and note the current setting.
- Compare test results before and after connecting on the same network, changing only one setting at a time.
- If needed, reopen the app or clear its cache as directed by your system, then test a fresh DNS lookup.
Test each app: A working browser isn’t enough
On desktop systems, “system proxy” settings usually make proxy details available to apps; they don’t force every program to use them. A website working in your browser doesn’t prove that your terminal, download tools, or desktop apps use the same route. TUN or VPN interfaces can route more traffic at the network layer, but may still be affected by routing, app exclusions, and protocol support.
Browsers and desktop apps
Find the target domain in your client’s connection logs and check whether it matched a proxy, direct, or reject rule. If the browser works but a desktop app doesn’t, check whether the app uses its own proxy, needs a restart to pick up system settings, or is sending requests to a different domain. A working sign-in page doesn’t guarantee that the APIs, media, or persistent connections used after sign-in will work too.
Terminals and developer tools
Terminal tools may read HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, while others only accept their own settings. Tools don’t all handle variable names, proxy protocols, or where DNS lookups happen in the same way. Don’t copy someone else’s local port. Use the listening address, protocol, and port shown by your client, and check the tool’s documentation.
If your browser works but your terminal doesn’t, first check whether the terminal’s request appears in the client logs. If it doesn’t, focus on how traffic is being routed. If it appears but the connection fails, check the rules, route, and target service. For certificate issues in a corporate development environment, follow your organization’s policies rather than bypassing certificate validation.
Mobile devices
The VPN indicator on iOS and VPN status on Android only show that a connection may be active. Whether all apps use it depends on the client’s capabilities, per-app settings, and system policies. After switching between Wi-Fi and cellular, you may need to reconnect. To test, reopen the target app, perform the action you need, and check whether the client records its traffic—don’t rely on the status bar alone.
Common reasons a VPN looks connected but isn’t routing traffic
A rule sends traffic directly: Rule-based mode chooses a route based on domains, addresses, or other conditions, and requests that don’t match a rule may use the default policy. Temporarily switching to the client’s global proxy mode can help with comparisons. Here, “global” usually means that covered requests all use the proxy; it doesn’t guarantee every app is covered. Restore your preferred routing rules when you’re done testing.
An old configuration is still selected after a subscription update: Updating a subscription doesn’t necessarily change the currently selected configuration. Check that the update succeeded, that the selected route is still available, and that the policy group has the intended selection. If the subscription can’t be retrieved, check its status in your service dashboard. Don’t share the full subscription link with strangers.
The address family or transport isn’t covered: An app may prefer IPv6 or use UDP, while your current routing setup handles only some requests. A working webpage doesn’t mean real-time calls or other UDP apps will work too. First confirm that your client and route support the transport you need, then adjust settings according to the documentation.
The test page shows other clues: A WebRTC test may show a local address, a privacy-masked host identifier, or a public candidate address. These aren’t the same as the exit IP for a regular web request. Identify the address type; if an unexpected public address from your local network appears, check the client’s routing and your browser settings.
Connecting and accessing a service are separate issues: A service may also check your account region, authorization status, payment details, or the reputation of your exit IP. A working VPN doesn’t override these requirements. Switching proxy protocols or seeing a route labeled IEPL, relay, or direct doesn’t, by itself, prove the service will be accessible.
Troubleshoot in this order instead of repeatedly reinstalling
- First, check that your regular connection works. Disconnect and try a regular website. If your direct connection is already having problems, troubleshoot network access first.
- Check your configuration and traffic routing. Verify your subscription status, selected route, system permissions, proxy settings, and whether another client could be interfering.
- Compare your exit IP using the same test page. Check IPv4 and IPv6 separately, and see which rule matched the domain.
- Check your DNS policies. Review system, browser, and client DNS settings separately. Don’t draw conclusions based on a location label alone.
- Reproduce the issue in the target app. Note the exact action, error message, matching rule, and connection result in the logs.
- Change just one variable at a time. Compare another route or traffic-routing mode, record the results before and after, then decide what to adjust next.
If you still can’t pinpoint the issue, share your system and client names, selected mode, steps that trigger the problem, and a redacted error message with support. Hide subscription links, access tokens, account details, and any unnecessary address information in screenshots. These details help distinguish configuration problems from service-side issues far better than “it’s connected but doesn’t work.”
Get InnVPN subscriptions and client downloads from the user dashboard. For basic setup, see the Guides. To investigate an issue, consult Troubleshooting or contact support through a support ticket.