iPhone VPN Reconnects After You Turn It Off: Who Restarts It?

Tap disconnect on the iPhone VPN, open a browser, and the tunnel is up again before the page loads, which makes the switch look broken. It is usually working as designed, just not as the user meant. Disconnecting ends one session; something else still holds permission to start a new one. Three different owners can do that on iOS, and each leaves a different fingerprint in when the reconnect happens.

Disconnecting is not disabling

A manual disconnect tells the tunnel to stop. It does not necessarily tell the system to stop asking for it. Connect On Demand rules, a provider app's own auto-connect policy, and a managed Always On configuration all survive a disconnect, and each can start the connection again without the user touching anything.

The distinction matters because the fix lives with the owner. Toggling the switch harder never helps, and deleting the profile is a much larger action than the problem requires. Find the trigger first, then decide whether it is yours to change. That order also keeps you from removing a working configuration in pursuit of a rule that lives somewhere else.

Compare the three owners by their trigger

Connect On Demand reacts to conditions the operating system evaluates: joining a network, or a request involving a domain the rule matches. A provider app can raise a connection when the app starts or when its own background policy decides to. A managed Always On deployment is a device-level requirement that the user is not meant to override at all.

Watch which event precedes the reconnect and the owner becomes fairly obvious. It is the difference between a rule you can edit and a policy you can only ask about.

What the On Demand rules actually do

On-demand behaviour is an ordered list. Each entry matches a condition and produces an action: connect, disconnect, evaluate a connection attempt, or ignore. A connect rule that appears before a disconnect rule wins whenever both match, which is why a device can reconnect immediately after a manual disconnect.

Rules can also be domain-driven, matching on a hostname in a request rather than an interface change. That is the pattern behind "the VPN comes back when I open the intranet site", and it points at the provider or profile that installed the rule rather than at iOS itself.

Managed Always On is not a personal option

On a supervised, managed device, the organization can require a VPN to stay up and can remove the user's ability to turn it off. No amount of switching in Settings will change that, and the honest answer is that the behaviour belongs to the administrator's policy.

Ask which policy applies and what exception process exists, if any. Deleting the installed management profile is not a supported workaround; it can remove other configuration the device depends on and it may break compliance reporting.

Test by removing the trigger, not the profile

Leave the profile installed, disconnect, then repeat the event that previously restarted the tunnel: join the same Wi-Fi, open the same app, request the same internal name. If the tunnel returns at that moment, you have identified the trigger and can go looking for the setting that owns it.

Change one setting at the owner, then repeat the same test. If the reconnect stops, you have the answer; if it persists, the trigger is elsewhere and the profile was never the problem. A downloaded settings file that is still sitting in Files is also not an installed configuration, so removing the file proves nothing either way.

The useful outcome is a sentence you can write down: this connection is started by this rule or policy, owned by this party. Once that is true, the switch stops feeling unpredictable, and the next person who reports it gets a direct answer instead of another reinstall.