The Hotel Wi-Fi Was Fast—The VPN Needed to Survive the Whole Stay

The upload reached 61 percent before the hotel Wi-Fi asked me to sign in again. I was in a room near Amsterdam Schiphol, trying to send a 1.7 GB design package before an 8 a.m. client review. The Wi-Fi icon still showed full strength, and my VPN still said Connected, but the project portal had stopped moving. I refreshed the page, watched the progress disappear, and restarted the upload from zero. My first thought was that the file was too large. The second attempt failed at 34 percent.

The client did not need an explanation about hotel internet.

They needed the revised drawings before the review began.

I had forty-three minutes.

A fast speed test did not mean a stable connection

The hotel Wi-Fi looked better than I expected.

A speed test suggested the file should take about twelve minutes. Video played without buffering, and email arrived normally.

I had also confirmed the exact network name with reception before connecting. Public hotel networks can be imitated, so checking the official hotspot name was one sensible precaution I could complete before opening any work accounts.

The obvious risks seemed covered.

I was on the correct network.

The signal was strong.

The VPN was active.

The upload still would not finish.

When I reopened the hotel’s welcome page, I found the first problem: my session had expired. Like many hotel networks, this one placed internet access behind a captive portal that required a room number, surname, or acceptance of its terms.

The laptop remained attached to Wi-Fi after that authorization ended. That was why the icon looked healthy even though the path to the internet had closed.

My established VPN made the failure harder to read. Its kill switch blocked traffic outside the protected connection, while the protected connection could no longer reach its server through the expired hotel session.

The result looked strangely convincing:

Wi-Fi connected.

VPN connected.

No usable internet.

I disconnected the VPN, entered my room number and surname again, and restored the hotel connection.

Then I reconnected to the nearest VPN server and restarted the upload.

This time it moved quickly.

Ten percent.

Twenty-six.

Forty-eight.

For a moment, I thought the expired portal had been the whole problem.

Then the progress bar stopped again.

The hotel network kept changing underneath the upload

I was working at the desk beside the window, where the laptop moved between two hotel access points. The Wi-Fi icon barely changed, but the route through the building did.

Each shift made the VPN reconnect.

Sometimes it recovered in a few seconds.

Sometimes the VPN remained green while the project portal stopped responding.

Other travelers have described the same practical pattern: hotel Wi-Fi appears connected, yet the internet repeatedly disappears once the VPN is involved.

That was enough to confirm what I was seeing.

The network was not permanently slow.

It was briefly unstable often enough to destroy a long transfer.

My established provider was a reasonable service. It had a long public history, broad server coverage, and enough settings to handle many different networks.

Its first suggestion was to change servers.

I selected another nearby endpoint.

The upload restarted and reached 22 percent before stopping.

I changed protocols.

The next attempt made it to 57 percent.

Then the hotel portal appeared again.

I renewed the room login and returned to the VPN. By the time it had reconnected, the project portal had ended the upload session.

Thirty-one minutes remained.

I moved to a chair near the room door, where the signal appeared stronger, and began again.

The estimate dropped to nine minutes.

At 71 percent, housekeeping entered the corridor with a cart. I shifted the laptop toward the desk to make space.

The device changed access points.

The VPN disconnected.

The upload froze.

A few seconds later, the portal reported that the transfer had failed.

That fourth restart changed what I was looking for.

The server list was no longer helping. Every new endpoint created another experiment, while the underlying problem stayed the same.

The hotel connection was going to wobble.

I needed a VPN that expected it to wobble.

Mobile data solved the wrong half of the problem

My phone hotspot was the obvious escape.

I disconnected from the hotel Wi-Fi, enabled the hotspot, and opened the project portal.

The mobile signal inside the room was weak but usable.

The upload estimate showed fifty-six minutes.

I moved closer to the window.

It dropped to thirty-nine.

That was still too late for the review.

I turned the established VPN back on, hoping the mobile route would at least remain consistent. Instead, the estimate rose again as the phone moved between LTE and 5G.

The hotspot had removed the captive portal and the hotel’s access-point changes.

It had also removed most of the available speed.

I now had two incomplete solutions.

The hotel Wi-Fi was fast enough but unstable.

The hotspot was simpler but too slow.

What I needed was the hotel’s speed with a protected connection that could recover whenever the underlying route shifted.

At that point, another server change would only repeat the same test.

I closed the established provider.

The smaller app stayed with the upload

I completed the hotel sign-in once more and opened OnlydogVPN, which I had installed before the trip as a backup.

Instead of asking me to choose a country, city, server percentage, and protocol, the smaller app presented situations.

I selected the preset for hotel work on an unstable connection.

The app connected.

I returned to the project portal and selected the design package again.

The upload reached 12 percent.

Then 29.

Then 46.

I left the laptop at the desk rather than carrying it around in search of a supposedly perfect signal. The room was where I needed to work. The connection needed to cope with it.

At 52 percent, the hotel Wi-Fi paused.

The VPN status briefly changed to Recovering.

The upload stopped moving.

A few seconds later, it advanced to 53 percent.

There was no new sign-in and no return to zero.

At 68 percent, the hotel portal expired again. This time, I received a clear prompt to renew the hotel session instead of a VPN window that continued claiming everything was fine.

I entered the room details and returned to the project portal.

The upload continued from 68 percent.

That was the first meaningful difference.

The smaller app did not make the hotel Wi-Fi flawless. It prevented each short interruption from becoming a complete restart.

The upload reached 84 percent just as the client sent a message:

Do we have the final files?

I replied:

Uploading now. A few minutes.

Then the hotel Wi-Fi disappeared completely.

The laptop switched to my phone hotspot.

The progress bar paused at 91 percent.

I watched it for three seconds.

Four.

Five.

Then it changed to 92.

The transfer had moved from the hotel network to mobile data without throwing away the work already completed.

At 7:51 a.m., the project portal displayed:

Upload complete.

A confirmation email arrived immediately afterward.

The client opened the package and replied:

Received. We’ll use this version.

That was the outcome I had been trying to reach for almost an hour.

The file was no longer waiting on my laptop.

It was in the client’s workspace before the meeting.

The technology mattered because the transfer continued

The hotel preset used an HTTP/3-based connection designed to recover when the device’s network path changed.

The practical explanation was shorter.

The hotel Wi-Fi faltered.

The hotspot took over.

The upload continued.

I could not observe the hotel’s internal traffic rules or every routing decision inside either VPN app. I could see the result on the same laptop: the established provider repeatedly showed a connection while long transfers failed, whereas the smaller app recovered through the interruptions and completed the file.

Nine minutes later, I joined the client review from the same hotel room.

I shared the uploaded drawings and watched the architect move through them without waiting for missing pages to load.

The network dipped twice during the call.

My video softened.

The audio continued.

Neither interruption removed me from the meeting.

With the urgent work finished, I opened the airline website to move my afternoon flight.

The next page needed less from the same weak network

The airline site normally loaded several promotional panels before showing the booking controls. On the hotel connection, every extra request made the page feel heavier.

A blocked-request counter in the smaller app began increasing as unnecessary advertising and tracking requests were filtered.

The booking form appeared.

I changed the flight and received the new boarding pass.

That filtering had not completed the client upload. Connection recovery had already solved the urgent problem.

It simply made the next ordinary task less fragile on the same inconsistent network. Fewer background requests were competing with the page I actually needed.

I left the hotel preset active while I packed the laptop.

Continuity mattered more than the fastest speed test

The smaller service has fewer server locations and a shorter public history than the established provider.

That matters when a traveler needs a specific exit city.

It did not decide whether my client received the design package.

The established provider offered more locations and more manual controls. On that hotel network, each interruption sent me back to its server list, protocol menu, or the beginning of the upload.

The smaller app treated hotel internet as temporary and imperfect. It let me complete the portal step, recovered when the Wi-Fi route shifted, and carried the transfer onto mobile data when the hotel network disappeared.

The speed test showed how fast the hotel Wi-Fi could be for a few seconds.

The completed upload showed which connection could remain useful for the whole job.