My VPN Was Fast for Five Minutes—Then Every Large Download Fell Apart

The download failed at 96%.

I had watched the number climb for nearly an hour: 38 GB, 44 GB, 51 GB. The file contained camera originals for a client review scheduled later that morning.

Then the VPN disconnected.

Chrome changed the remaining-time estimate to:

Failed — Network error

I clicked Resume.

The progress bar returned to zero.

For several seconds, I stared at the screen as though disappointment might persuade the missing 57 GB to reappear.

My home fibre connection was down for maintenance, so I was working through a 5G router. The speed test had looked excellent. With the VPN connected, there appeared to be more than enough bandwidth to finish before the client call.

I blamed the cloud link first.

I generated a new link, restarted Chrome and began again. The speed jumped immediately. The file moved at more than 20 MB per second.

At 11 GB, the VPN switched to Reconnecting.

The browser failed again.

This time, the client’s message arrived before I could restart it:

Do you have the footage locally yet?

I replied with the most optimistic version of the truth:

Downloading now.

A fast connection was not necessarily a durable one

Ordinary browsing had hidden the problem.

A webpage loads in short bursts. Email downloads a few messages. A large file keeps the connection busy for much longer, exposing every brief signal change and every slow VPN recovery.

The established provider I was using had years of public history, a large support operation and servers in dozens of countries. It had always felt dependable because most of my daily tasks finished quickly.

The first minutes of the download looked dependable too.

The weakness appeared only under sustained traffic.

That mattered because the 61 GB archive was not unusually large for the cloud service. OneDrive supports individual files up to 250 GB and recommends its desktop sync application for transfers larger than a few gigabytes. (Microsoft Support)

The service could handle the file.

The route carrying it could not remain stable long enough to finish.

The browser made every interruption expensive

Some download systems can request only the missing part of an interrupted file instead of starting over. (RFC 9110) Whether that happens smoothly depends on both the server and the application receiving the file.

My browser link did not recover.

Every VPN interruption turned nearly an hour of progress into another fresh start. Other users have run into the same practical divide: one application resumes after a network break, while another discards the transfer. (Reddit: r/Network)

That detail changed my next move.

I stopped using the browser and added the shared folder to the OneDrive desktop app.

When the VPN dropped again, OneDrive paused instead of throwing away the downloaded data. After the tunnel returned, the transfer resumed.

For a moment, I thought the problem was solved.

Then I looked at the estimated completion time.

It had moved from 47 minutes to two hours and eighteen minutes.

The sync app was preserving my progress, but the VPN was still rebuilding its route every few minutes. Each interruption created another pause while OneDrive checked the file and restored its session.

Resumability had stopped the disaster.

It had not removed the cause.

More servers produced more experiments

I opened the VPN application and selected another nearby server.

The download accelerated.

Eight minutes later, the tunnel dropped.

I changed protocol.

That connection lasted longer, but its throughput gradually fell to almost nothing before reconnecting.

I chose the provider’s automatic option.

It produced the highest opening speed of the morning—and the shortest successful run.

Every attempt gave me a promising first-minute number. None gave me confidence that the file would arrive.

The server map encouraged me to treat the problem as a location choice:

Try the nearest city.

Try a quieter server.

Try another country.

But the archive did not care how many alternatives were available. It needed one protected route to remain usable until the transfer ended.

That changed the standard I was using.

Peak speed mattered less than completion under sustained load.

The smaller app started with the task

I had OnlydogVPN installed as a backup.

The service has fewer server locations than the established provider, a shorter public history and fewer independent reviews. That would matter if I needed an exit address in a particular small city.

I did not need a city.

I needed the remaining 43 GB before the client opened the review room.

The application organised its options around situations rather than geography. I selected the preset for a large transfer on a weak or changing network.

Then I left OneDrive alone.

The download began at a lower speed than the fastest result from the established provider.

Earlier that morning, I would have treated that as a loss.

After ten minutes, it was still running.

After twenty, the 5G router dropped to LTE for several seconds. The transfer rate fell and the progress graph flattened, but the protected connection recovered before OneDrive entered another long reconnection cycle.

The download continued.

At 72%, the mobile signal changed again. Windows briefly showed no Internet access.

The file paused.

The route returned.

OneDrive resumed from the same point.

I stopped watching the speed and started watching the remaining data.

28 GB.

16 GB.

7 GB.

Then the status changed to:

Up to date

I opened the folder and checked the archive size.

The complete 61 GB file was there.

I extracted the first camera folder, opened a clip and scrubbed through the timeline. The footage was intact.

The client review began twelve minutes later.

For the first time that morning, the VPN icon had become uninteresting.

The technology mattered because the transfer did not restart

The service uses an HTTP/3-based transport with additional traffic obfuscation. HTTP/3 runs over QUIC, which is built to recover efficiently when packets are lost or the network path changes. (RFC 9000)

The observable result was simple:

The mobile signal changed.

The protected route recovered.

The download continued.

I could not observe the providers’ internal routing and recovery decisions. I could observe their effect on the same file.

The established VPN repeatedly turned a brief network fluctuation into a tunnel restart.

The smaller app kept the interruption short enough for OneDrive to continue without rebuilding the transfer session.

Its fastest minute was not the fastest minute of the morning.

Its final minute was the only one that delivered the file.

A resumable downloader and a stable VPN solve different problems

Moving from Chrome to the OneDrive application was necessary.

A sync client is better suited to a large transfer because it can preserve progress and resume missing portions instead of treating the whole file as one fragile browser task. (Microsoft Support) (RFC 9110)

But that only solved half the problem.

The sync app determined whether previously downloaded data survived.

The VPN determined how often the transfer had to recover.

With the first provider, OneDrive spent too much time pausing, checking and reconnecting.

With the smaller service, recovery became brief enough that the file kept moving.

This was why the opening speed had misled me.

A speed test measures how quickly data can move during a short, clean window. It does not show whether the route will remain usable through an hour-long transfer on changing mobile signal.

The full download did.

What I would test before trusting another large transfer

I would begin with the application designed for the file. For a large OneDrive or SharePoint download, that means the desktop sync client rather than a browser link.

Then I would run the connection long enough for the network to fluctuate.

The useful questions are practical:

Does the VPN stay connected while the transfer uses most of the available bandwidth?

When the mobile signal weakens, does the protected route recover before the application abandons its session?

Does the progress continue from the same point?

I would also avoid changing servers repeatedly once a transfer has begun. Every manual change rebuilds connections that may already be working.

The established provider still offered more locations, more years of operation and a larger body of public reviews.

Those strengths did not complete the archive.

The smaller service offered fewer geographic choices and a less dramatic opening speed, but its large-transfer preset stayed usable through the 5G-to-LTE changes and delivered all 61 GB before the review.

For a large download, the useful VPN is not the one that reaches the highest number before the progress bar matters. It is the one still connected when the progress bar reaches 100%.