iPhone VPN Icon On: Does It Cover Every App or Just Work?
One badge, three different claims. Separate what the profile covers, what on-demand rules do, and which address family you actually tested.
Your badge appears, the app still behaves as if it were at home, and the obvious conclusion is that the tunnel is broken. Usually nothing is broken. The badge reports one connection, while the question behind it is about coverage, and those are different claims.
Three conditions decide which claim you can make. Until they are settled, any test result is ambiguous.
Three Answers Hide Behind One Icon
The first question is what you wanted the tunnel to do. Reaching an internal wiki, hiding your address from a streaming service, and protecting a single managed app are three different requirements that three different profiles satisfy.
The second is who owns the profile. A personally installed configuration behaves differently from one pushed by a management system, and only the second can carry per-app rules that iOS enforces. The badge cannot tell those two apart.
The third is the address family you are standing on. A tunnel that carries IPv4 while the network hands out IPv6 leaves one path outside the tunnel. A test that only reaches an IPv4 site will never see it.
Per-App Profiles Cover Only Their Apps
A per-app VPN is the case that produces the most false alarms. The profile names the apps whose traffic enters the tunnel, and everything else continues on the local network by design. Your public address staying the same in a browser is therefore expected behaviour, not evidence of failure. Nothing in the status bar contradicts it.
Test the app the profile was built for, and test it against a resource that only exists inside. A successful internal request from the named app describes a working setup. A normal public address in Safari then describes a per-app profile behaving exactly as configured.
On-Demand Rules Change What You Observe
On-demand configuration decides when a connection is established rather than whether traffic is covered. A rule can bring the tunnel up when a particular domain is requested and tear it down when the request finishes, which means the badge appearing and disappearing during ordinary use is the design working. Read the rules before interpreting the badge.
That behaviour also explains results that look inconsistent across a day. The same app can be tunnelled at ten in the morning and direct at noon, because the trigger condition changed rather than the policy.
One Probe Is Not a Coverage Proof
A single browser check proves one request took one path, and nothing more. It says nothing about a second app with its own networking stack, a background sync that ran before the tunnel came up, or a connection that survived a network change because the old socket was never re-established. That gap is a scope problem rather than a leak.
| Observation | Decide this first | Then test |
|---|---|---|
| Badge on, public address unchanged | Is the profile per-app? | The named internal app, not a browser |
| Badge flickers during the day | Are on-demand rules present? | Whether the flip follows a trigger domain |
| Internal app works, another fails | Is that app in the profile? | Its own settings and any proxy config |
| Nothing works while badge is on | Is this a path failure? | Name resolution and a known-good internal host |
The fourth row is the only one that points at a fault. A connected tunnel with broken resolution, a missing return route, or a service that is simply down all look identical from the app's point of view.
What to Record Before Escalating
Write down the profile name, whether it came from a management system, whether per-app rules are present, and the exact time of the failing request. Add the address family you tested and the app you tested from. No number on the screen replaces that list. That record separates a coverage question from an outage in one round trip.
Keep the security basics in view as well. A tunnel does not replace certificate validation, account protection or device permissions. An icon appearing next to the network status is not evidence that any of them are configured, and treating it that way is how a privacy claim gets made on the strength of a badge.
Apple's deployment overview of VPN describes the profile types and the on-demand behaviour behind these differences. Read it before arguing with a management system about what a profile should cover.