Multi-Hop Made the VPN Feel Safer. It Also Made the Upload Impossible.

The progress bar reached 12 percent and stopped. A minute later, it moved to 13. The estimated upload time changed from eighteen minutes to two hours and forty-seven. I closed the hotel curtains, moved the laptop closer to the door and restarted the transfer. The speed rose briefly, then collapsed again. In twenty-five minutes, an editor in London was due to review the interview footage before the morning production meeting. The file was ready. My multi-hop VPN connection was not.

I was in a hotel outside Brussels after filming a cybersecurity conference. The raw interview had already been trimmed to a 2.4-gigabyte package. All I needed to do was upload it to the production drive and send the link.

Under ordinary circumstances, I would have used the hotel Wi-Fi without thinking much about it.

That week, however, Microsoft had warned that attackers were manipulating traffic on hotel, conference-centre and other captive-portal networks. The campaign redirected travellers to phishing infrastructure and fake updates designed to steal credentials or install malware. (Microsoft)

The warning was still fresh when the hotel login page disappeared and the internet came online.

I opened my established VPN and enabled its strongest-looking option: multi-hop.

My traffic would pass through one VPN server, then another, before reaching the upload service.

Two protected servers felt safer than one.

The file barely moved.

I blamed the hotel before I blamed the extra hop

The hotel Wi-Fi showed a respectable download speed. Web pages opened quickly, and the video-call test inside the production platform passed.

The upload was the exception.

I paused the transfer and ran another speed test. Download performance remained normal, but upstream speed through the VPN wandered between 1 and 4 Mbps.

I switched the multi-hop entry server from Belgium to the Netherlands while keeping the exit in Switzerland.

The connection took longer to establish.

The upload restarted from the beginning.

For thirty seconds, the estimate looked reasonable. Then it climbed past two hours again.

I tried Germany as the entry point and Sweden as the exit. That combination reduced the speed further and added enough delay for the production drive to report a network timeout.

Each pair looked sensible on the map.

None delivered the file.

The established provider was doing exactly what I had asked: sending the upload through two separate VPN locations.

The problem was that my deadline had to travel through both of them too.

More protection had become more distance

Multi-hop separates the entry and exit points of a VPN connection. That can add privacy, but it also sends every piece of data through an additional server.

The effect on my upload was immediate.

The hotel was in Belgium. My first route entered in the Netherlands, exited in Switzerland and only then continued to the production drive. The next route sent the same 2.4-gigabyte file through Germany and Sweden.

Each extra leg added delay and another place for congestion to slow the transfer. VPN providers themselves warn that multi-hop usually reduces performance, especially when the two locations are far apart. (Mullvad)

Public user discussions describe the result more simply: multi-hop can turn a connection that handles ordinary browsing into one that buffers or crawls during heavier tasks. (Reddit)

That was all the confirmation I needed.

I had chosen the strongest-looking setting without asking whether it matched the job.

With the progress bar still below 20 percent, the distinction suddenly mattered. I did not need the most elaborate route available.

I needed the file in London before the meeting began.

Turning multi-hop off solved only half the problem

With seventeen minutes remaining, I disabled multi-hop and selected the nearest ordinary server.

The difference was immediate.

The upload speed climbed above 18 Mbps, and the estimate dropped below twenty minutes.

For the first time that evening, the deadline looked possible.

Then the hotel Wi-Fi weakened.

The transfer paused at 41 percent. The VPN application began reconnecting, and the production drive displayed a failed-upload message.

When the connection returned, the file did not resume cleanly. It checked the uploaded blocks, stalled again and finally reset to zero.

The single-hop route was much faster, but the session was fragile.

I tried another nearby server. It connected quickly, reached 9 percent and then slowed as the hotel network fluctuated.

That failure changed the problem again.

Multi-hop had made the journey too long. The ordinary route was faster, but every interruption threatened to erase the progress I had made.

A good speed-test result was no longer enough.

I needed a protected connection that could keep one large upload moving even when the network underneath it did not behave perfectly.

The smaller app started with the file

OnlydogVPN was already installed on the laptop as a travel backup.

It had fewer server locations, a shorter public history and fewer independent reviews than the established provider. Those were the reasons I had not opened it first.

Its interface also asked a different question.

Instead of making me design an entry country, an exit country and a complete route, it presented options based on the task. I selected the preset for secure work and file transfers and connected.

Then I reopened the production drive.

The upload started at 24 Mbps.

I watched the estimate for a full minute, expecting the familiar climb from minutes to hours.

It stayed below fifteen minutes.

At 10 percent, the speed dipped and recovered.

At 30 percent, it remained steady enough that I stopped moving the laptop around the room.

At 54 percent, I sent the editor a message saying the footage was finally on its way.

The useful difference was already visible. The smaller app had chosen one route for the transfer and kept it moving without asking me to assemble the journey myself.

For this upload, fewer decisions produced the better connection.

The Wi-Fi failed at 78 percent

The hotel network dropped without warning.

My browser showed an offline page. The production drive froze, and the Wi-Fi icon disappeared from the taskbar.

The laptop switched to my phone hotspot.

I expected another failed upload.

Instead, the progress bar paused at 78 percent and stayed there.

Then it continued.

The speed returned at roughly 15 Mbps—lower than before, but fast enough to finish.

The smaller app uses HTTP/3-based transport that can recover when the underlying network changes. Its QUIC foundation allows an active connection to continue across a new network path instead of rebuilding the entire session from zero. (IETF)

That short explanation matched the result on screen.

The first single-hop transfer had collapsed when the hotel connection weakened.

This one survived the move from Wi-Fi to mobile data without discarding nearly two gigabytes of progress.

I could not observe the hotel network’s internal filtering rules or either provider’s complete routing decisions. I could see what mattered: the established setup repeatedly sent me back to the beginning, while the smaller app carried the same upload through the interruption.

The percentage kept rising.

I left the VPN window closed.

The upload finished before the meeting began

The file reached 100 percent with six minutes left.

The production drive processed it, generated a preview and displayed the sharing link.

I opened the interview from the beginning and skipped to the middle. The picture loaded. The sound was present. The file had arrived intact.

I sent the link to the editor.

A moment later, the reply appeared:

Got it. Downloading now.

That message completed the task.

The VPN was still connected.

The hotel Wi-Fi had failed once.

The upload had not restarted.

Only then did I realise how much time I had spent treating multi-hop as a general quality setting rather than a specialised tool.

I had turned it on because the network felt risky. I had not considered what the second server would do to a large, time-sensitive transfer—or how little the extra hop would matter if the file never reached its destination.

Multi-hop was solving the wrong problem

The mistake was not that multi-hop added protection.

The mistake was assuming that more hops automatically meant a better connection for the work in front of me.

Every additional server lengthened the route. For ordinary browsing, the delay might have been easy to tolerate. A page opening a second later would not ruin the evening.

A large upload exposed the cost immediately.

The first multi-hop route crawled.

The second timed out.

The ordinary single-hop connection restored speed but lost the upload when the hotel Wi-Fi weakened.

Only the task-based route combined the two results I actually needed: useful upload speed and recovery when the network changed.

That was the comparison the progress bar had forced me to make.

The strongest-looking privacy mode was not the most useful protection if it prevented the work from leaving my laptop.

I had confused maximum protection with useful protection

The warning about compromised hospitality networks was a good reason not to send work files over hotel Wi-Fi unprotected.

It was not a reason to add every available layer without considering the task.

The established provider gave me control over both halves of the multi-hop route. For this deadline, that control created more distance, more decisions and an upload estimate measured in hours.

Its ordinary route was faster, but it could not preserve the transfer when the hotel connection failed.

The smaller app made the narrower—and better—decision.

It selected one route for the file, kept the transfer moving and carried it from hotel Wi-Fi to mobile data without returning to zero.

I did not need the route with the most steps.

I needed the route that could carry the same file all the way to 100 percent.