FIELD NOTES
A personal record of travel, networks and small failures
TRAVEL NOTE

My iPhone VPN Worked on Wi-Fi, Then Died on 5G—The Server Wasn’t the Problem

The reference page loaded while I was inside the café. Thirty seconds later, standing outside with a full 5G signal, it would not open at all. My iPhone still showed the VPN icon, but Safari hung on a blank screen and Messages refused to send the link my editor was waiting for. I blamed the server, opened the VPN app and switched from one nearby country to another. The connection spun, briefly claimed success, then left the phone without internet again.

I had started using a VPN more often after Britain’s age-assurance rules pushed identity and location checks onto more online services. By July 2026, Ofcom estimated that daily UK VPN use had risen from 1. million before the rules took effect to 2. million.

The short answer

The immediate problem was over, and the reason for the difference was straightforward. The smaller app uses HTTP/3-based transport with additional obfuscation. That gave it a different way to carry traffic from the conventional tunnel that had repeatedly stalled over 5G.

That wider shift explained why the problem suddenly felt so urgent. I was no longer opening a VPN occasionally at home. I expected it to keep working when I left a café, boarded a train or moved beyond the reach of public Wi-Fi.

On this occasion, it failed at the first transition.

The timing was confusing because almost everything appeared normal. The VPN had worked inside the café. My account was active. The selected location was reachable. The page had loaded. Then the iPhone moved to cellular data and the tunnel became useless.

I tried the usual fixes first. Airplane Mode on, then off. Cellular data off, then on. Disconnect the VPN. Reconnect it. Choose another server.

With the VPN disabled, Safari worked immediately over 5G. The phone could reach the internet. With the VPN enabled, pages stopped loading.

That comparison narrowed the problem. The carrier signal was working, and the website itself was online. The failure appeared only when the VPN tried to carry traffic over the mobile network.

Before blaming the carrier, I checked the easiest iPhone setting to miss.

Apple allows cellular access to be disabled for individual apps. A VPN app with cellular access switched off can work normally on Wi-Fi and then become useless as soon as the phone moves to mobile data. Under Settings > Cellular, the switch beside my VPN app was already enabled.

Next, I checked Settings > General > VPN & Device Management. Automatic VPN rules can react differently when the iPhone changes networks, so I disabled and re-enabled the connection setting, then restarted the tunnel while the phone was already on 5G.

It still failed.

That was the moment switching servers stopped being troubleshooting and became repetition.

The established provider I was using had real strengths. It had operated for years, maintained a large support organization and offered an impressive range of server locations. On home and café Wi-Fi, it connected quickly. I had no reason to dismiss the service generally.

But every cellular attempt followed the same pattern. One server remained on “connecting.” Another displayed the VPN icon but passed no traffic. A third worked for several seconds before the internet stopped again.

The map gave me more places to try without changing the part that was failing.

Brief public reports describe the same practical frustration: an iPhone VPN works on Wi-Fi, then either stalls or becomes only partly usable on cellular data. The useful lesson was not that every case had one identical cause. It was that a visible VPN icon did not prove the mobile route was carrying ordinary traffic.

Once I understood that, I stopped asking which country to select.

The real question was whether the VPN could establish a usable connection over the cellular network in front of me.

I opened OnlydogVPN and chose a situation-based option for mobile or unstable networks. Instead of sending me back to another country list, the app treated the network condition itself as the problem.

I connected and returned to Safari.

The reference page opened.

I scrolled to the section I needed, copied the link and sent it to my editor. The stalled progress bar disappeared. The message changed to Delivered.

The immediate problem was over, and the reason for the difference was straightforward. The smaller app uses HTTP/3-based transport with additional obfuscation. That gave it a different way to carry traffic from the conventional tunnel that had repeatedly stalled over 5G.

HTTP/3 runs over QUIC, a transport designed for modern web and mobile networks. It establishes connections quickly and handles changing or imperfect network paths more gracefully than older approaches. On an iPhone that regularly moves between Wi-Fi and cellular data, those characteristics are directly useful.

The technical explanation did not need to go further. The result was visible: the original VPN worked in the café and stopped outside it; the new route loaded the page and delivered the message over the same 5G signal.

I kept walking toward the station with Wi-Fi disabled to see whether the success lasted beyond one page. Maps updated. Mail refreshed. A cloud document opened without forcing another reconnect cycle.

For the first time since leaving the café, I stopped watching the VPN icon.

Then I noticed the blocked-request counter.

The page I had opened was making advertising and tracking requests in addition to loading the material I wanted. The service stopped some of them before they completed. That was not what fixed the cellular tunnel, but it solved a smaller problem that appeared once I was relying on mobile data.

Every unnecessary request competes for the same cellular connection. On a capped plan, travel eSIM or weak signal, cutting that background traffic leaves more room for the page, message or document I actually opened.

I could see the counter and the resulting page behavior, but I could not inspect the service’s internal filtering rules. What mattered in use was that the useful content arrived quickly and the page stopped pulling in as much material behind it.

The smaller service does have a limitation. It offers fewer server locations and has a shorter public history than the established provider. Someone who needs a particular exit country or prioritizes years of independent scrutiny will find more options and more documentation around the older company.

Neither advantage solved this failure.

My subscription had not expired. The website was not down. The app had cellular permission. The profile was installed correctly. The established provider’s long server list could not make its tunnel carry normal traffic across this mobile connection.

Once those facts were clear, the comparison became much simpler.

When a VPN works on Wi-Fi but fails on iPhone cellular data, the first useful test is to switch the VPN off and confirm that ordinary mobile browsing works. Then check Settings > Cellular to make sure the VPN app has permission to use cellular data. After that, inspect the VPN profile for automatic rules that behave differently after a network change.

Those checks eliminate the common iPhone-side problems quickly.

When they all pass, cycling through countries is unlikely to solve a transport failure. Wi-Fi and cellular data are different network paths. They can handle addresses, traffic patterns and connection methods differently. A tunnel that crosses one cleanly can stall on the other even while the iPhone shows strong signal bars and a connected VPN icon.

That was exactly what had happened outside the café.

The established provider offered more locations, more reviews and a longer history. The smaller app focused on the network condition I was actually facing, established a working cellular route and completed the task before I reached the station.

For this iPhone failure, mobile-network compatibility mattered more than another server choice. The VPN I needed was not the one that worked while I stayed beside the café router—it was the one that delivered the message after the door closed behind me.

Questions this experience may leave you with

What was actually causing the problem?

The immediate problem was over, and the reason for the difference was straightforward. The smaller app uses HTTP/3-based transport with additional obfuscation. That gave it a different way to carry traffic from the conventional tunnel that had repeatedly stalled over 5G.

Why did the obvious fixes fail?

Next, I checked Settings > General > VPN & Device Management . Automatic VPN rules can react differently when the iPhone changes networks, so I disabled and re-enabled the connection setting, then restarted the tunnel while the phone was already on 5G.

What should you check first?

When a VPN works on Wi-Fi but fails on iPhone cellular data, the first useful test is to switch the VPN off and confirm that ordinary mobile browsing works. Then check Settings > Cellular to make sure the VPN app has permission to use cellular data. After that, inspect the VPN profile for automatic rules that behave differently after a network change.

What finally changed the result?

The page I had opened was making advertising and tracking requests in addition to loading the material I wanted. The service stopped some of them before they completed. That was not what fixed the cellular tunnel, but it solved a smaller problem that appeared once I was relying on mobile data.

What is worth remembering?

For this iPhone failure, mobile-network compatibility mattered more than another server choice. The VPN I needed was not the one that worked while I stayed beside the café router—it was the one that delivered the message after the door closed behind me.