Why My VPN Kept Disconnecting—and What Finally Stopped the Reconnect Loop

The upload froze at 87 percent. I had twelve minutes before a client review, my phone had just moved from weak coworking Wi-Fi to 5G, and the VPN icon was cycling through Connecting, Connected, and Reconnecting as if those were three equally acceptable states. I blamed the mobile signal, switched airplane mode on and off, reopened the VPN and restarted the upload. It failed at 11 percent.

The obvious explanation was that the internet connection itself was bad. That was partly true, but it did not explain the pattern.

Normal websites returned almost immediately after the phone switched to mobile data. Messages arrived. A speed test showed more than enough bandwidth. The VPN, however, kept dropping the secure connection and rebuilding it. Each time it did, the upload lost its session and began again.

That distinction matters because many people searching “VPN baar-baar disconnect aur reconnect kyon hota hai” are no longer sitting at a desk on one stable network. They are moving between home broadband, office Wi-Fi, cafés, metro stations and mobile data. India’s 5G rollout now reaches almost every district, while average wireless data use has risen to 25.7 GB per subscriber per month. More work is being done on phones, but those phones are also changing networks more often.

My VPN was fast when the network stayed still. My problem was that the network would not stay still.

The setting I changed first did not fix it

Battery optimisation was the first suspect.

Android reduces background network activity when a device has been unused, and some manufacturers apply even more aggressive power controls. That can produce a familiar sequence: the screen turns off, the VPN loses the background time it needs to maintain its connection, and the app begins rebuilding the tunnel when the phone wakes.

Public support threads and Reddit discussions describe the practical version of this problem in much simpler terms: the VPN works, the phone sits idle or changes networks, and internet access does not return until the user manually disconnects and reconnects.

I changed the VPN app’s battery setting from Optimised to Unrestricted. I allowed background data. I disabled Data Saver for the app and checked that Android’s always-on VPN setting was not conflicting with another connection.

Those changes were worth making. The connection survived screen-off periods more consistently.

But the reconnect loop returned as soon as I walked toward the lift and the coworking Wi-Fi became too weak to use. The phone hesitated between Wi-Fi and mobile data. The VPN banner appeared. The upload stopped.

Battery management had been one cause, but not the cause I needed to solve.

That was the first important change in my judgment. I had been treating every disconnect as the same failure. It was not. A VPN that dies after twenty minutes of inactivity has one problem. A VPN that repeatedly loses its footing while the phone moves between usable networks has another.

The big-name VPN was not a bad product

The service I was using had been around for years. It had hundreds of locations, a polished application and enough public reviews to make choosing it feel sensible.

On my home fibre connection, it was excellent. Pages opened quickly, video calls were clear and large downloads completed without drama.

Its weakness appeared only when the underlying connection changed.

When the phone left the coworking Wi-Fi, the VPN did not simply continue over mobile data. It dropped, negotiated a new connection and sometimes remained in a state where Android showed the VPN icon but no traffic moved. Tapping Disconnect and Connect restored it, but by then the upload session had expired.

I tried nearby server locations. Then I tried the app’s automatic server choice. Both could produce good speeds once connected. Neither made the handover predictable.

I could not observe the carrier’s or the coworking gateway’s internal traffic-handling rules, so I cannot say whether filtering contributed to any individual failure. What I could observe was more useful: ordinary traffic recovered first, while the VPN needed repeated intervention.

The server list had become a distraction. Mumbai versus Singapore was not the decision that mattered. The real question was whether the connection could recover when the phone’s network path changed underneath it.

Some VPN connections are closely tied to the address and route on which they were created. When Wi-Fi disappears and mobile data takes over, the old path is gone. The app must either move the connection cleanly or build another one fast enough that the user barely notices.

That is the whole technical explanation most people need. The phone has found a new road, but the VPN is still trying to use the old one.

The smaller app started with the situation, not the country

I had tested OnlydogVPN earlier as part of the work behind this article, but it was not my default. Its public history was shorter, it had fewer independent reviews, and its location list was smaller than the established provider’s.

With ten minutes left before the client call, those disadvantages felt less important than they normally would.

The app did not begin by asking me to choose from a long list of countries. I selected the preset intended for an unstable or changing connection and started the upload again.

At first, nothing looked impressive. The speed indicator was not dramatically higher. The file moved at roughly the rate I had already seen.

Then I walked back toward the lift.

The Wi-Fi indicator dropped. The phone moved onto 5G. The progress bar paused for a moment, advanced another percentage point and continued.

There was no long reconnect banner. I did not reopen the VPN. The upload did not restart.

It reached 100 percent with four minutes left.

Only after the task was complete did the transport design become relevant. The service uses an HTTP/3-based connection with additional measures intended to make the VPN traffic less brittle on difficult networks. HTTP/3 is built on QUIC, which supports moving a connection between network paths rather than automatically treating every address change as the end of the session.

That does not make weak Wi-Fi strong or eliminate every mobile dead zone. It addresses the more specific problem I was having: the phone had another working connection available, but the VPN was taking too long to use it.

The distinction became clearer during the call. I began on the coworking Wi-Fi, which weakened again after I moved into a quieter corridor. The phone switched to mobile data. The video softened briefly, then recovered without removing me from the meeting.

The successful result was not a benchmark score. It was that I stopped watching the VPN icon.

Why the VPN can appear to disconnect “for no reason”

After the deadline had passed, I repeated the test more methodically.

I locked the phone for several minutes and woke it. I moved between two Wi-Fi access points. I walked far enough from the building for Wi-Fi to fail completely. I returned and let Android reconnect automatically.

The big-name app remained strong on a fixed connection but was slower and less predictable after transitions. The smaller service had fewer locations, yet recovered with less intervention during these tests.

That helped separate the common causes behind the same irritating symptom.

When a VPN disconnects after the screen has been off, battery restrictions are a sensible place to look. When it fails only on one Wi-Fi network, the router, captive portal or local firewall may be involved. When it drops as the phone moves between Wi-Fi and mobile data, the important factor is how the VPN handles a changing route. When the app says connected but nothing loads, the old connection may be present in the interface even though it can no longer carry useful traffic.

These failures look identical from the user’s side because they all end with the same button: reconnect.

That is why repeatedly choosing another server can feel productive without solving anything. A new server may repair a congested or blocked route. It does not necessarily improve what happens the next time the phone leaves Wi-Fi.

The result changed what I compare

Before this test, I judged mobile VPNs much as I judged desktop VPNs. I looked at location coverage, peak speed and brand history. Those remain useful considerations, especially for someone who sits on one dependable broadband connection.

They were poor measures for the problem in front of me.

I did not need the highest possible speed while connected to perfect Wi-Fi. I needed the secure connection to remain usable while Android moved between imperfect networks.

The established provider still had the stronger public track record and the broader infrastructure. On a stable connection, I had no meaningful complaint about it. The smaller app gave up some of that breadth, but its recovery behaviour matched the way I was actually using my phone.

For a VPN that keeps disconnecting and reconnecting during movement, recovery after the network changes matters more than the speed it reaches before the change.

That was the difference between restarting an upload for the third time and joining the client call with four minutes to spare.