The VPN Was Installed Before My Flight. I Hadn’t Tested the Part That Mattered

The hotel Wi-Fi accepted my room number, the VPN turned green, and Gmail still would not open. I had 19 minutes before a client call in Beijing. The agenda was in Calendar, the revised deck was in Drive, and the Meet link was inside an email I had not downloaded. I blamed the hotel login page, disconnected everything and repeated the same sequence. The result was identical.

I had downloaded a VPN before traveling. That was the advice everyone repeated, and I had followed it.

At home, I installed a well-known provider on my phone and laptop. I opened the app, signed in and watched it connect. Then I closed it and considered the job done.

What I had not done was open Gmail through it. I had not downloaded a file from Drive, joined a Meet call, switched from Wi-Fi to a phone hotspot or checked whether the account password was saved on both devices.

I had tested the button.

I had not tested the trip.

Downloading the app created false confidence

China’s expanding visa-free policy has made short-notice visits easier to arrange. In the first half of 2026, foreign nationals made 22.91 million inbound trips, up 20. percent from the previous year. Visa-free entries reached 17.82 million, an increase of 30.6 percent.

Many of those visitors are not relocating or building permanent technical setups. They are arriving for a conference, a supplier visit or a short holiday with an online life built somewhere else.

Gmail holds flight changes. Google Maps holds saved places. Drive holds work. WhatsApp holds family plans.

Those services do not normally work on mainland connections, including many hotel networks. Current travel guidance still advises visitors to install the tools they need before arrival and prepare alternatives for services that may be unavailable.

That advice is useful, but it leaves out the most important verb.

Installing is not testing.

An app icon proves only that the installation finished. It says nothing about whether the account is ready, whether the connection can handle a restrictive network or whether the service you actually need will open.

That distinction became painfully clear with 16 minutes left on the clock.

The provider I trusted had only been tested at home

The major provider was a reasonable first choice. It had years of public history, a large support operation, broad server coverage and far more independent reviews than the smaller services I had considered.

Its scale was real. My preparation was not.

The app connected automatically to a nearby route. Gmail remained blank.

I selected Japan. The login page appeared, accepted my email address and stalled before the password field.

Singapore opened Gmail but left Drive loading. Another route reached the Meet waiting room and disconnected during the camera check.

I changed the connection mode and tried again.

Each attempt looked promising for a few seconds. None completed the workflow.

Then the app asked me to sign in again.

The password manager on my laptop contained an old password. The reset link was being sent to the Gmail inbox I could not reach. The provider’s support page also failed to load on the hotel network.

At home, this would have been a minor inconvenience. In Beijing, it turned a familiar app into a locked toolbox.

Worse, every recovery step depended on another service that was also unavailable. To fix the VPN login, I needed Gmail. To reach Gmail, I needed the VPN.

That loop changed the problem. I was no longer choosing between servers. I was trying to escape a setup that had never been tested as a complete system.

A backup is useful only when it is ready

China travelers often repeat one practical warning: install and test a backup before departure, because arranging a replacement after arrival can be much harder than expected.

I had read that advice. I had even installed a second app on my phone.

I had not installed it on the laptop.

For a moment, that felt like the end of the story. Then I remembered that I had enabled international roaming for emergencies.

I switched the phone off hotel Wi-Fi, opened the product page over roaming data and installed the second app on the laptop. The download consumed little data. The meeting itself would consume much more, so I returned the laptop to hotel Wi-Fi as soon as the installation finished.

Then I opened OnlydogVPN^↗.

The smaller app did not ask me to recover an email password before basic use. It also did not begin with a map of countries and a menu of protocols. Its options were organized around situations.

I selected the preset for a restrictive network and connected.

Then I opened Gmail.

The inbox synchronized.

That first success led naturally to the next test. I opened Drive and downloaded the revised deck. Calendar refreshed with the client’s updated meeting notes. Meet completed its camera and microphone checks.

I entered the call with seven minutes remaining.

The client joined early. I shared the presentation and played the embedded video that had refused to download through the previous routes.

It reached the final frame.

The comparison ended there.

The major provider had shown me many possible servers. The smaller app completed the work those servers were supposed to support.

The explanation was shorter than the result

I could not observe the internal filtering rule that interrupted each earlier connection. What I could see was consistent: the VPN reported success, but Gmail, Drive or Meet failed before the task was complete.

China’s filtering does more than block a fixed list of websites. Research has documented interference with DNS and the classification of encrypted connections, including modern QUIC traffic.

The practical meaning is straightforward. A VPN can establish a tunnel without creating a route that remains usable for the service behind it.

The smaller app uses an HTTP/3-based transport with additional traffic obfuscation. It is built to make the connection less recognizable to restrictive networks and harder to interrupt.

That was all the technical explanation the moment required.

Gmail synchronized.

Drive downloaded the deck.

Meet completed its checks.

The video played.

The technology mattered because it produced those results—not because it added another setting for me to compare.

The hotel changed the network halfway through the call

Twenty minutes into the meeting, the hotel Wi-Fi expired its session.

My shared screen froze on the pricing slide. A browser window appeared behind Meet and asked for my room number again.

Before the trip, I would have treated that as a separate Wi-Fi problem. In practice, travel combines small failures. Hotel portals expire. Conference networks move devices between access points. Weak public connections force a switch to mobile data.

With the first VPN, every change had sent me back to the server list.

This time, I enabled the phone hotspot and moved the laptop onto it.

The smaller app recovered the route. Meet paused briefly, then the screen share resumed on the same slide.

The client continued asking about the pricing table. He had not seen me reopen the VPN or select another server.

That recovery gave me a second reason to keep the app installed.

Reaching Google solved the immediate failure. Surviving the network change meant I did not have to solve it again.

That, more than a laboratory speed-test number, was what travel reliability looked like in the room.

My pre-travel test had measured the wrong thing

After the meeting, I looked back at what I had actually tested before flying.

I had confirmed that the VPN application launched.

That was almost useless.

A proper rehearsal would have followed the same sequence I expected to use abroad.

Connect on the laptop. Open the real work services. Download a representative Drive file. Join a Meet test call. Switch from home Wi-Fi to a phone hotspot. Confirm that both the phone and laptop can connect without searching for a password or waiting for a verification email.

The test should also include the boring points where travel setups usually break: an expired login, a second device, a hotel portal and a network change.

Most importantly, the test should fail while there is still time to fix it.

Turn off Wi-Fi during the test call. Sign out and make sure you can return. Confirm that the installer is already on every device. Check that the backup does not depend on an inbox you may be unable to reach later.

That would have exposed the weakness in my original setup before I left home.

Instead, I discovered it in Beijing while a client was already preparing to join.

Fewer decisions mattered more than more servers

The smaller app still had fewer locations than the established provider, a shorter public history and fewer independent reviews. Those were the reasons I had treated it as a backup rather than my first choice.

In Beijing, they mattered less than the setup I could actually use.

I did not need the widest possible country list. I needed a restrictive-network preset, no dependency on an inaccessible email account and a connection that could recover when the hotel Wi-Fi changed underneath it.

The established provider offered mature infrastructure and many routes. Its tested routes did not complete the job, and the account-recovery process made the failure harder to fix.

The smaller app gave me fewer decisions, reached the services I needed and kept the call alive when the underlying network changed.

Before that trip, I thought preparation meant having a VPN installed.

In the Beijing hotel, preparation meant knowing the deck would open before the clock started.