WireGuard vs OpenVPN: The Faster Protocol Wasn’t the One That Finished My Upload

The software package stopped uploading at 18 percent while the VPN app insisted that WireGuard was connected. I was in a Barcelona conference hotel, trying to push an emergency checkout fix before a retailer demonstrated the site to its European partners. I blamed the repository, refreshed my access token and restarted the transfer. The progress bar moved for three seconds, then froze at exactly the same place.

The fix itself was small.

A currency selector had stopped updating the total when a customer changed delivery countries. I had corrected the calculation, tested it locally and received approval from the retailer’s engineering lead.

All that remained was to upload the package, let the automated checks run and join the demonstration call.

The call began in thirty-one minutes.

The hotel Wi-Fi looked excellent. Email opened instantly. A nearby speed-test server reported more than 400 Mbps.

WireGuard also connected almost immediately.

Nothing behind it moved.

That was the problem hidden inside the usual WireGuard-versus-OpenVPN debate. I did not need to know which protocol won under ideal conditions.

I needed to know which one could carry this release through the network in front of me.

WireGuard was fast until the hotel joined the test

WireGuard has a compact design and carries its traffic over UDP. (WireGuard) That helps explain why it often connects quickly and performs well on ordinary home, mobile and office networks.

It had been my default for months.

At home, I barely noticed it connecting. On mobile data, it usually recovered quickly as the phone moved between towers. For everyday travel, it felt like the obvious modern choice.

The conference hotel changed that.

Its Wi-Fi used a captive portal that required a room number, surname and renewed agreement every few hours. Ordinary web traffic worked after the login page disappeared.

The WireGuard tunnel showed as active too.

But the repository, private dashboard and messaging app all stopped receiving data.

I disconnected the VPN.

The dashboard opened immediately.

I reconnected.

The page froze again.

Other travelers have reported the same practical split: WireGuard works over a phone hotspot but stalls on hotel or captive-portal Wi-Fi. (Reddit) My screen was showing exactly that kind of failure.

So I stopped changing WireGuard servers and changed protocols instead.

OpenVPN reached the repository

OpenVPN can operate over UDP or TCP. TCP on port 443 is commonly used when a network restricts other forms of VPN traffic because it travels through a port normally needed for secure websites. (OpenVPN)

That made it the logical fallback.

I selected OpenVPN TCP.

The connection took noticeably longer to establish.

Then the retailer’s private dashboard appeared.

The repository authenticated.

The messaging app updated with six missed messages from the engineering lead.

Are you able to deploy? Demo starts at 10:00.

I replied:

Connected now. Uploading.

For the first time that morning, the progress moved beyond 18 percent.

It reached 30.

Then 46.

The immediate comparison seemed settled.

WireGuard had connected faster but carried nothing.

OpenVPN had connected slowly and reached the work.

Then the upload began hesitating.

Access was not the same as completion

At 58 percent, the transfer paused for nearly a minute.

The hotel Wi-Fi had not disconnected. Ordinary sites still opened in another browser window.

The OpenVPN connection also remained active.

The repository upload simply stopped advancing.

When it resumed, the meeting application began losing audio from a test call with the retailer’s engineer.

“I can hear every third word,” she said.

I turned off the camera.

The audio improved briefly.

Then the VPN reconnected and the repository reported that the upload session had expired.

The progress returned to zero.

OpenVPN TCP had solved the first failure. It crossed the hotel network and reached the private systems.

It did not keep the upload and call usable together.

That changed what “better” meant.

For opening one restricted page, OpenVPN had already beaten WireGuard on this Wi-Fi.

I needed a complete release process.

Access was only the beginning.

The phone hotspot reversed the result

I switched the laptop to my phone’s hotspot and returned to WireGuard.

It connected immediately.

The repository opened.

The upload moved quickly through the first 20 percent.

That proved the WireGuard configuration, account and server were working. The hotel network had been the obstacle.

Unfortunately, the conference hall was built from glass, concrete and too many temporary walls. The mobile signal moved between two bars and one.

At 34 percent, the upload estimate jumped from six minutes to forty-two.

The demonstration call would begin in nineteen.

I now had two protocols that were better in different ways.

WireGuard was responsive on mobile data but unusable through the hotel Wi-Fi.

OpenVPN passed through the hotel network but could not keep the complete working session stable enough to finish.

The question was no longer simply which protocol was faster.

It was which connection could complete the task across the network I actually had.

The protocol menu became another delay

I returned to the hotel Wi-Fi because it still had far more capacity than the mobile connection.

The major provider offered more ports, automatic modes, alternative endpoints and another OpenVPN profile.

Any of them might have changed the result.

Each also required another upload from zero.

The engineering lead sent a new message:

Twelve minutes. We can delay the demo five, no more.

Protocol experimentation was now consuming the time the protocols were supposed to save.

WireGuard was not simply the fast option.

OpenVPN was not simply the compatible option.

On this network, one failed before the work began and the other failed before the work finished.

That was when the backup became relevant.

The smaller app started with the situation

I had installed OnlydogVPN^↗ before the trip but had not made it my default.

The established provider had more ratings, more server locations and a much longer public history. The smaller app’s shorter record was why I had kept it as a secondary option.

Its opening screen did not ask me to choose between WireGuard and OpenVPN.

It asked what kind of problem I was facing.

I selected the preset for a restrictive or unreliable public network.

The connection established while the laptop remained on the hotel Wi-Fi.

The repository opened.

The private dashboard opened.

The messaging app continued updating.

I restarted the package upload.

It passed 18 percent.

Then 34, where the mobile connection had slowed.

Then 58, where OpenVPN had begun hesitating.

The meeting application remained open beside it.

At 86 percent, the hotel network paused for several seconds.

The upload stopped.

Then it continued from the same point.

The package reached 100 percent.

The retailer’s build system began its checks.

One test passed.

Then another.

The currency test turned green last.

I clicked Deploy to staging.

The corrected checkout appeared on the retailer’s preview site with four minutes remaining.

The engineering lead replied:

Confirmed. Joining demo.

That completed the task.

The finished build mattered more than the label

The service uses an HTTP/3-based connection with traffic obfuscation suited to restrictive or unreliable networks.

The practical difference was already visible.

WireGuard connected quickly on mobile data but could not carry traffic through the hotel Wi-Fi.

OpenVPN TCP crossed the hotel network but failed to preserve the upload and call together.

The backup kept the whole-device workflow moving on the same guest connection.

I could not observe the hotel network’s internal filtering or traffic-management rules. I could compare what happened from the moment each connection started until the build finished.

For this situation, completing the full task mattered more than whether the protocol was considered faster or more established in isolation.

The demonstration created a second test

The retailer joined the call and shared the staging site.

The presenter changed the delivery country from Spain to Germany.

The currency selector updated the order total correctly.

Then she changed it to Sweden.

The correct amount appeared again.

Halfway through the demonstration, the hotel Wi-Fi disappeared.

The captive-portal session had expired.

The call froze.

My laptop moved automatically to the phone hotspot.

The VPN recovered on the new network.

The meeting returned without removing me from the room, and the retailer’s preview site remained open on the Swedish checkout screen.

“Are you still there?” the presenter asked.

“Yes. Continue.”

She completed the demonstration.

No one outside the engineering call needed to know that the network underneath my laptop had changed.

That smaller recovery clarified the comparison.

WireGuard had performed well on the hotspot when tested by itself.

The backup carried the existing work session from hotel Wi-Fi to that hotspot after the upload and demonstration were already underway.

The difference was not a better benchmark.

It was less disruption at the moment disruption would have cost the most.

WireGuard and OpenVPN were tools, not rankings

By the end of the call, I no longer thought the original question had one permanent answer.

WireGuard is an excellent default on networks that carry it cleanly. It had been quick and responsive through my mobile connection.

OpenVPN’s flexibility matters when a restrictive network blocks or mishandles UDP. Its TCP mode allowed me to reach systems WireGuard could not reach through the hotel.

Both results were useful.

Neither completed my release that morning.

The mistake was treating the protocol name as the final comparison criterion.

A traveler may move between home broadband, airport Wi-Fi, a hotel captive portal, conference internet and mobile data within one day. The protocol that works beautifully at breakfast may become the wrong one by lunch.

The useful test is not whether the VPN says Connected.

It is whether the actual task survives:

Does the private page open?

Does the upload continue?

Does the call remain usable?

Does the session recover when the network changes?

Does the client see the finished result?

The green build settled the debate

The established provider remained the better-known service. Its WireGuard mode was fast on mobile data, and its OpenVPN TCP mode reached the retailer through the hotel network.

Both were reasonable attempts.

Neither produced the final build.

The smaller backup had fewer locations, fewer ratings and a shorter public history.

It was also the option that completed the upload, passed the automated tests and remained connected when the hotel Wi-Fi handed the laptop over to mobile data.

I began the morning asking whether WireGuard was better than OpenVPN.

The green build gave me the answer I actually needed: the better protocol was the one I did not have to think about while the checkout fix crossed the finish line.