The Right Way to Start a VPN on Airport Wi-Fi

I had eighteen minutes before a client call when my laptop joined the airport Wi-Fi and then refused to do anything useful.

The signal looked strong. Slack stayed grey. The meeting page spun without loading. I blamed the airport network, disconnected, rejoined and tried the same link on my phone.

Still nothing.

Then I noticed the VPN icon. The large, familiar service I normally used was set to connect automatically on unknown Wi-Fi. Its kill switch was blocking traffic until it could establish an encrypted tunnel.

That sounded reassuring at home. At the airport, it had created a deadlock: the Wi-Fi wanted me to complete its login page before granting internet access, while the VPN would not let that page load outside the tunnel.

I had prepared for unsafe Wi-Fi. I had not prepared for the awkward minute before the VPN could actually protect me.

“Turn on the VPN first” is incomplete advice

Airport Wi-Fi often uses a captive portal. Joining the network does not immediately place you on the open internet. It first redirects you to a page where you may need to accept terms, enter a code or complete another access step. Until that happens, most other connections remain restricted. (RFC 8952)

That means the useful preparation happens before the trip.

The VPN should already be installed. You should have opened it at least once, confirmed that it connects and learned where its kill switch is. Discovering at the gate that an app needs an update, a forgotten password or an email verification link defeats the point of having it ready.

At the airport, the order is slightly different:

Verify the network, join it, complete the captive portal and then connect the VPN before opening anything sensitive.

Apple’s guidance for captive networks follows the same basic sequence: select the network, wait for the login screen and complete the required step before normal access begins. (Apple Support) Traveler discussions tend to reduce the workaround to one practical sentence: pause the VPN briefly, finish the portal, then reconnect it immediately. (Reddit: r/digitalnomad)

That was what I did.

I paused the kill switch and reopened the Wi-Fi login prompt. The page asked me to accept the airport’s terms. I did not open email, cloud storage or the meeting invitation during that gap. I completed the portal, confirmed that a plain webpage could load and restarted the VPN.

The login problem was solved.

The connection problem was not.

The network name mattered before the encryption did

Public Wi-Fi is often described as though anyone nearby can automatically read every password. That is no longer an accurate picture of ordinary web browsing. Most modern websites encrypt traffic between the browser and the site, which has made public Wi-Fi safer than it once was. (US Federal Trade Commission, Are Public Wi-Fi)

The more immediate risk is joining the wrong network or trusting a fake login page.

In November 2025, Australian authorities reported the sentencing of a man who had operated “evil twin” Wi-Fi networks that imitated legitimate services at airports and on domestic flights. The networks were used to collect credentials and personal material. (Australian Federal Police, WA man jailed for)

A VPN cannot undo information already entered into a fraudulent portal.

So before joining, I checked the official network name against the airport signage and confirmed it with the lounge desk. The portal asked only for acceptance of the usage terms. Had it unexpectedly requested my email password, social-media credentials or payment information, I would have stopped.

Only after that check did the VPN comparison begin.

The obvious choice gave me more options, not a working call

The established provider seemed like the sensible first attempt.

I had already paid for it. It had a long public history, a large support operation and a server list covering more places than I would ever visit. Under ordinary conditions, those are genuine advantages.

I pressed Connect.

The automatic connection stalled. I chose a nearby location manually. That attempt timed out. I switched to another server, then changed the protocol in the settings.

One connection appeared for a few seconds before dropping.

The meeting page still would not open.

I could not observe the airport network’s internal filtering rules, so I could not tell whether it was interfering with a recognizable connection pattern, rejecting particular exit addresses or simply losing too many packets on a crowded access point. The practical result was the same: I was spending the final minutes before the call managing a server menu.

That kind of inconsistency appears repeatedly in traveler accounts. At busy transit airports, people describe Wi-Fi that connects but will not sustain calls, tunnels that work on one device but not another, and repeated drops that turn a simple login into a troubleshooting session. (Reddit: r/travel)

The provider had not become a bad service. It was simply failing the task in front of me.

With eleven minutes left, the size of its server network stopped feeling important. I did not need fifty possible routes. I needed one route that could establish quickly and survive an unstable connection.

The smaller app removed the decisions I no longer had time to make

I opened OnlydogVPN, which I had installed as a backup before leaving home.

Instead of beginning with a map and a long list of countries, it offered a situation-based option for a restricted or unreliable network.

I selected it.

A few seconds later, Slack turned green.

I opened the meeting link. The waiting room appeared. The audio test played normally, and I joined before the client arrived. The video softened once when the airport signal dipped, but the call remained open.

The result came before the explanation, which was exactly what I needed.

The smaller app uses an HTTP/3-based transport with additional traffic obfuscation. In practical terms, it is designed to make the tunnel fit more naturally into modern web traffic rather than presenting the network with an immediately obvious conventional VPN pattern. HTTP/3 runs over QUIC, a transport built for faster recovery when connections change or packets disappear. (RFC 9308)

That technical difference mattered because airport Wi-Fi rarely fails in one dramatic moment. It degrades in small interruptions. A device moves between access points. Signal strength shifts as passengers pass. A crowded network drops packets and then recovers.

The established service had made each interruption feel like a new decision. Reconnect. Change server. Change protocol. Try again.

The smaller app handled the interruptions without sending me back to its menu.

Halfway through the call, I walked out of the lounge to find a quieter gate. My phone briefly moved from Wi-Fi to mobile data and then joined the airport network again. The connection recovered without forcing me to restart the session.

That was a secondary benefit, but it answered a different airport problem: movement. A VPN that connects only while I remain beside one access point is less useful during a long connection than one that can recover as the network underneath it changes.

The short unprotected interval should be intentional

The experience changed how I prepare for airport Wi-Fi.

I no longer think “use a VPN before joining” means pressing Connect while the device is still locked behind the captive portal. It means doing the preparation before arriving, then keeping the unavoidable portal step as narrow as possible.

At home, I install the app on every device I may need. I open it, test it and check how its kill switch behaves. I also disable automatic joining for public networks, because a familiar-looking network name is not proof that the access point is genuine.

At the airport, I verify the official Wi-Fi name using signage, the airport’s website over mobile data or a member of staff. I join manually and wait for the portal.

When the portal does not appear, I temporarily pause the VPN and any setting that blocks all non-VPN traffic. I use that interval only to complete the airport’s access page. I do not check messages, sign in to work systems or enter an unrelated password.

As soon as ordinary internet access works, I reconnect the VPN and then open the meeting, retrieve the file or send the message that brought me online.

The difference sounds small. It is not.

Without that sequence, a well-configured kill switch can make legitimate airport Wi-Fi appear broken. Without checking the network name, a traveler can secure a connection only after handing credentials to the wrong portal. And without a tunnel that can recover on a weak network, the remaining layover can disappear into server changes and repeated reconnections.

What mattered at the gate

The smaller service has fewer server locations than the established provider. For someone who regularly needs a specific country or city, that may matter.

It did not matter during this layover.

The major provider gave me more places to choose from after the captive portal. The backup gave me a usable connection before the client call.

That was the comparison I had been getting wrong. On airport Wi-Fi, the important question is not how many routes appear in the app. It is how cleanly the VPN can take over after the portal—and whether it stays out of the way while you finish the task that could not wait.