My VPN Worked Until I Locked My iPhone—and the Alerts Stopped

The message that mattered arrived seven minutes before I saw it. I was in a Lisbon hotel room, waiting for my engineering team to confirm whether we should roll back a broken software release. Slack was open, the hotel Wi-Fi was strong, and my iPhone showed an active VPN connection. I set the phone beside my laptop, let the screen lock and continued reading the error logs. When I picked it up again, the VPN briefly displayed Reconnecting. Then six Slack messages appeared at once, including: “Need your approval now.” I blamed the notification settings, restarted Slack and asked a colleague to send a test message. It arrived immediately—while the screen was awake.

The release was still failing.

My colleague wrote:

“Can we roll back?”

“Yes,” I replied. “Do it.”

The approval had arrived late, but not too late. The incident would continue for at least another twenty minutes, and I could not afford a second gap.

I locked the phone again.

Three minutes later, I woke it manually.

The VPN reconnected.

Another delayed message appeared.

That was when the pattern became impossible to dismiss.

The connection worked whenever I watched it

I had updated the iPhone recently, so my first assumption was that an iOS setting had changed.

I checked Focus mode.

Off.

Low Power Mode.

Off.

Background App Refresh.

Enabled for Slack and the VPN.

Notifications were allowed on the Lock Screen. The hotel Wi-Fi had not failed either; my laptop remained connected throughout the same period.

I ran a controlled test.

With the display awake, the VPN stayed connected and Slack messages arrived immediately.

I pressed the side button.

A colleague sent three messages at one-minute intervals.

When I unlocked the phone four minutes later, the VPN changed from disconnected to connecting. The messages then arrived together.

Other iPhone users had noticed the same frustrating sequence: the VPN dropped after the phone locked, then missed notifications appeared when it reconnected. (Reddit)

That brief confirmation changed the problem.

The VPN did not need to fail while I was actively browsing to be unreliable. It only had to disappear during the hours when the phone was supposed to work without my attention.

The established provider looked excellent in the foreground

The VPN was a major service I had used for years.

It had polished iPhone software, a large support operation and servers in dozens of countries. On the hotel connection, its foreground performance looked healthy.

I selected a nearby server.

The tunnel opened in seconds.

Web pages loaded normally.

A speed test showed far more bandwidth than Slack, email or the incident dashboard required.

Then I locked the phone.

Four minutes later, the connection had dropped.

I changed from the automatic protocol to WireGuard and repeated the test.

The VPN lasted slightly longer, then reconnected when I woke the display.

I tried another server.

The result was the same.

OpenVPN survived a short lock period, but after a longer test the first message still waited until I touched the phone.

At that point, changing locations no longer made sense. The server was reachable, and the connection was fast whenever the screen remained active.

The failure was happening during absence.

Reconnecting was not the result I needed

Apple supports VPN On Demand, which can establish a connection automatically when matching network activity requires it. (Apple) That helps explain why a tunnel may return when an app becomes active again.

But a fast reconnection still leaves a gap.

If Slack waits for the tunnel to restart, the notification is late even when the VPN recovers a few seconds after I unlock the phone.

Apple also offers a stronger Always On VPN configuration for supervised devices managed by an organization. (Apple) My personal iPhone was not enrolled in a corporate device-management system.

That left a simple practical standard.

I did not care whether the VPN could reconnect after I came back.

I needed the message to arrive before I came back.

Keeping the display on solved the wrong problem

The quickest workaround was obvious.

I changed Auto-Lock to Never, reopened the VPN and left the screen awake.

The connection stayed active.

Slack messages arrived normally.

The incident dashboard remained current.

For the next ten minutes, the phone behaved exactly as I needed.

It also became warm on the desk.

The display was draining the battery to keep a background connection alive, and the VPN app had become a machine that worked only while I stared at it.

That might have been tolerable for the rest of one software incident. It was not something I wanted during a flight, train journey or full day away from a charger.

More importantly, the workaround clarified what I should be comparing.

The provider had already proved that it was fast with the screen on.

The real test began when the screen went dark.

The smaller app started with the failure itself

I closed the established provider and opened the smaller backup installed before the trip.

It did not begin with a country list.

The first screen asked what was going wrong.

I selected the preset for a connection that stopped in the background or changed networks.

The app connected over the hotel Wi-Fi.

I opened Slack and told my colleague:

“Send a message in five minutes. Don’t warn me first.”

Then I locked the iPhone and placed it face down.

I resisted the urge to check it.

Five minutes passed.

The phone vibrated.

The Lock Screen showed:

“Rollback complete. Error rate is falling.”

The message had arrived while the screen was still locked.

I left the phone untouched for another five minutes.

A second notification appeared.

When I finally unlocked it, the VPN was already connected.

There was no burst of delayed messages.

No reconnecting banner appeared.

The phone had done nothing dramatic.

That was exactly the result I wanted.

The test changed from speed to continuity

During the testing behind this article, the smaller app kept the tunnel available through repeated lock periods on the same iPhone and hotel network where the established provider had disconnected.

Its preset used HTTP/3-based transport and recovery behavior designed to keep a route usable when the device becomes quiet or the connection changes.

I could not observe iOS’s internal scheduling decisions or identify the precise event that had ended the earlier tunnels.

The visible comparison was enough:

the established provider worked while the phone was active and returned after I woke it;

leaving the display on prevented the failure but drained the battery;

the smaller app remained available while the phone was locked and delivered the alert without waiting for me.

That changed the standard completely.

A VPN can produce an excellent speed result during a thirty-second foreground test and still fail during the much longer periods when an iPhone sits in a pocket, bag or locked hotel room.

For messaging and incident monitoring, continuity mattered more than the peak number on a speed test.

The incident followed me out of the room

The rollback reduced the error rate but did not end the incident. The team needed another thirty minutes to verify that customer requests were processing normally.

I had already agreed to meet a colleague downstairs.

Before leaving, I locked the phone and put it in my pocket.

The elevator weakened the hotel Wi-Fi.

By the time I reached the lobby, the iPhone had switched to roaming data.

The smaller app briefly showed that it was recovering the route, but Slack remained open when I checked it.

A new message arrived:

“Payments look normal again.”

I acknowledged it and locked the phone.

The service’s HTTP/3 transport uses QUIC, which supports carrying a connection onto a new network path when the phone changes interfaces. (IETF)

On my screen, the technical result looked ordinary.

The hotel Wi-Fi disappeared.

Mobile data took over.

The conversation continued.

The lock-screen test had already solved the main problem upstairs. This transition removed the next friction: walking out of the hotel did not force another manual reconnection.

The foreground benchmark had hidden the failure

Before that night, I judged mobile VPNs by what happened immediately after pressing Connect.

How quickly did the tunnel open?

Which nearby server produced the highest speed?

How many locations were available?

Those questions were easy to measure because I could watch the answers appear.

The lock-screen failure was harder to catch.

The VPN disappeared while I was not looking.

Messages accumulated silently.

When I returned, the app reconnected quickly enough to make the interruption seem harmless.

During an active incident, it was not harmless.

A three-minute gap could delay a rollback, hide a login approval or leave a driver waiting outside while the phone still appeared connected.

The established provider’s quick recovery had made the underlying failure easy to overlook.

The smaller app removed the need for recovery in the first place during the tests that mattered.

More controls created more waiting

The major provider offered several protocols, automatic selection and a long server list. Those choices remain useful when a specific server is slow.

They did not solve this problem.

Every manual change required another full cycle:

connect;

send a test;

lock the phone;

wait;

unlock it;

check whether the message arrived.

The smaller app reduced the decision to the situation itself. I selected the background-connection preset and tested the only outcome that mattered.

The phone stayed locked.

The message arrived.

That saved more than setup time. It meant I no longer had to wake the phone repeatedly just to confirm that protection was still present.

The smaller service still made a visible trade-off

The smaller app has fewer server locations, fewer independent reviews and a shorter public history than the established provider. That is its clearest limitation.

Before the incident, I would have treated the larger company’s scale as the safer choice for an all-day iPhone connection.

The lock-screen tests changed that judgment.

A large network was useful only after the phone maintained a tunnel long enough to reach it.

A fast server was useful only if it remained available while the display was dark.

A quick reconnection was still evidence that a disconnection had happened.

The established provider gave me stronger foreground numbers and more ways to repeat the same test.

The smaller app delivered the result I could not create by watching the screen: the alert arrived while I was away from it.

For an iPhone that spends most of the day locked, the useful VPN is the one that keeps working before the owner returns.