Android VPN Icon Is On, So Why Is Traffic Not Tunneled?

Your VPN key is in the status bar, the browser loads a page, and the address a website reports is still your home connection. That combination is normal on Android, because the icon says an app owns a virtual network interface, not that your traffic leaves through a remote server. A local filtering app uses the same facility. Check what the service is actually doing before you blame the provider.

The icon means a VPN service owns the interface

Android's VPN service lets an application create a virtual interface and receive the packets routed into it. What happens next is entirely up to that application: it can forward them to a remote server, filter them, or drop them. The key icon reports that a service holds the interface, not where the packets go. That is why a filtering app and a full tunnel look identical in the status bar.

adb shell dumpsys connectivity | grep -i vpn
adb shell settings get global always_on_vpn_app

Only one VPN service can be active per user or profile at a time, which is documented behaviour rather than a bug. When a second app tries to connect, it either takes over or fails, and the first one's traffic stops being handled. If a filtering app quits the moment you connect a tunnel, that competition is the likely reason.

Native profile or app VPN: they are not interchangeable

A platform-provisioned IKEv2 profile and an app that implements OpenVPN or WireGuard are different products with different menus. The platform API for IKEv2 exists from a specific Android version, and manufacturer builds do not all expose the same options in the same place. A screenshot from another phone is not a compatibility document.

adb shell getprop ro.build.version.sdk
adb shell dumpsys package com.example.vpn | head -40

Match the protocol to the client that supports it, and obtain the profile through the provider's verified channel rather than pasting it into an unrelated form. An endpoint address tells you where to connect, not which app can speak the protocol. Treat exported profiles and QR codes as credentials, because a QR image can contain the complete key. If the profile was issued for a different client, reissue it rather than converting it.

Per-app rules and work profiles change the scope

Android supports per-app VPN configurations, so a browser can be outside the tunnel while a mail app is inside it. Personal and work profiles are separate contexts with their own active service. Checking the address from the wrong app is one of the most common false conclusions in this area.

Look at the inclusion and exclusion lists, then test with the application you actually care about. A work profile tunnel does not cover personal apps, and a personal tunnel does not cover work apps. The same separation explains why a corporate resource works in one profile and fails in another with no visible configuration difference. Record the profile context in the ticket, because it changes which settings even apply.

Stop if the app you are testing is not in the tunnel's scope. That is a policy choice, not a fault.

Test what actually left the phone

Test public and private destinations, both address families and both access networks. Then compare the result with the app's own scope, because a successful page load in one app says nothing about the other. Repeat after a Wi-Fi to mobile-data switch, since a reconnect can land on a different path.

adb shell ip rule
adb shell dumpsys netpolicy | grep -i vpn

Always-on VPN and the option that blocks connections without a VPN are related but distinct, and a strict block can break captive-portal sign-in until you follow the documented procedure. Private DNS settings can also interact with the profile's resolver, so replacing an organisation's DNS blindly creates a new failure. If the tunnel dies when the screen locks, read the VPN developer guidance on background execution and battery optimisation before reinstalling anything.

The symptom to keep in view is the gap between the icon and the path. The key means a service owns the interface; only a test from the intended app on the intended network tells you where the traffic went. Check both, and the next report of a broken VPN is much easier to place.