My VPN Passed the Speed Test—Then Dropped the Video Call

My hotel Wi-Fi speed test showed 146 Mbps. The VPN connected in three seconds. Then, just as I began sharing the revised campaign deck, the client’s face froze and the meeting app displayed Your network connection is unstable. I blamed the call software, left the meeting and joined again. Thirty seconds into the second attempt, the VPN switched to Reconnecting and removed me from the call completely.

The speed test still looked excellent.

That was the first sign that I had measured the wrong thing.

I did not need enough bandwidth to download a film. I needed one live connection to remain intact while my voice, camera and shared screen moved through it.

The connection was fast but not steady

Video meetings expose interruptions that ordinary browsing can hide.

A webpage can pause and continue loading. A file can retry a missing section. During a live call, the same delay becomes broken audio, frozen video or a lost screen share. That is why meeting-quality tools measure latency, packet loss and jitter rather than relying on download speed alone. (Zoom Support)

My hotel connection had plenty of headline speed. What it lacked was consistency.

I reopened the meeting without sharing my screen. The audio held for several minutes. The moment I turned on the camera and presented the deck, the VPN began reconnecting again.

The VPN was not failing because video calls and encryption were inherently incompatible. It was failing because the tunnel recovered too slowly whenever the hotel connection wavered.

Current Teams network guidance makes the practical risk clear: routing live media through an unstable VPN path can add delay and jitter, while hotel-style Wi-Fi may already be unreliable for real-time traffic. (Microsoft Learn)

The speed test had measured the moments when both connections were behaving.

The call revealed what happened between those moments.

More servers did not create a stable meeting

The VPN already on my laptop came from a major provider with a long public history, broad server coverage and mature support.

Those were sensible reasons to trust it while travelling. When a connection felt slow, I chose a nearby server. When one server failed, I moved to another.

That habit worked for browsing. It became awkward while speaking to a client.

I muted myself, selected the provider’s recommended nearby location and rejoined. The call returned. When I shared the deck again, the audio became metallic and the client’s video stopped.

I changed protocols.

The next attempt lasted four minutes. Then the hotel signal weakened, the VPN began rebuilding its connection and the meeting app tried to reconnect at the same time.

By the time both recovered, the client had moved to the next agenda item.

I could rejoin the call. I could not recover the moment.

Other remote workers describe the same practical failure: the connection seems adequate until screen sharing or heavier media begins, then the VPN drops and the participant disappears from the meeting. (Reddit discussion)

That brief pattern matched what I had just seen. The established provider could encrypt the traffic, but it could not keep the usable route alive when the network changed.

From that point, the server list mattered less.

Recovery time mattered more.

Turning off the VPN saved the call but split the work apart

The simplest workaround was obvious.

I disconnected the VPN and joined the meeting directly through the hotel Wi-Fi.

The client heard me immediately. My camera remained clear, and the first ten slides advanced without interruption.

For a moment, the problem appeared solved.

Then I looked at everything else running on the laptop.

The campaign files were syncing through a desktop application. The client workspace was open. Email notifications were arriving. A browser tab contained the budget approval page I needed later in the meeting.

I could close those applications. I could protect only the browser. I could also use split tunnelling and send the meeting outside the VPN while keeping selected apps inside it.

Every workaround required me to divide one client session into separate routes.

Large organisations can design those exceptions carefully. I was in a hotel room, already late, trying to remember whether the meeting link had opened in the browser, the desktop app or both.

After the presentation, I reconnected the VPN.

The cloud-sync app restarted. The client workspace briefly signed out. The budget page asked me to authenticate again.

Turning off the tunnel had preserved the call by disrupting everything around it.

What I needed was simpler: keep the complete work session protected without making the meeting fragile.

The hotspot revealed the real weakness

I switched the laptop to my phone’s hotspot.

The meeting quality improved, confirming that the mobile connection could carry the call. But moving away from the hotel Wi-Fi forced the established VPN to reconnect again.

The meeting dropped before the new tunnel was ready.

I joined through the phone app while the laptop recovered. That kept me audible, but I could no longer present the deck properly or make changes on the larger screen.

The hotspot had not failed. It had exposed the part of the VPN that mattered most.

Both the hotel Wi-Fi and the mobile connection could support the meeting. The interruption happened while the tunnel moved between them.

A live call does not care whether a VPN eventually reconnects. It cares how much of the conversation disappears first.

Testing another server would only repeat the same sequence. I needed a tunnel that could adapt to the network change without turning it into a new meeting.

The smaller app stayed in the call

I disconnected the established provider and opened the smaller app named in the disclosure.

Its interface did not begin with a map or a protocol list. I selected the preset for a weak or changing network and connected.

Then I returned to the meeting.

The browser, cloud-sync app and client workspace remained active behind the same tunnel. I turned on the camera, shared the campaign deck and moved through the slides that had triggered the earlier failures.

The audio remained clear.

The client asked about the budget assumptions. I opened the spreadsheet, changed a figure and returned to the presentation without seeing another reconnect warning.

The work was moving again, so I stopped watching the VPN icon.

Ten minutes later, the hotel signal dropped sharply. The client’s voice broke for a moment, and the meeting app lowered the video quality.

The call did not end.

I switched the laptop to my phone’s hotspot.

The shared screen paused, then resumed. I heard the end of the client’s sentence without leaving the meeting. The workspace remained connected, and the updated deck continued syncing in the background.

That transition completed the test.

The service uses an HTTP/3-based transport with additional obfuscation. The useful explanation is short: its connection could adapt when the laptop moved from hotel Wi-Fi to mobile data instead of rebuilding the entire session around the new network. (RFC 9000)

I could not observe the hotel’s internal filtering or traffic-management rules. I could observe the meeting: the previous VPN repeatedly removed me from it, while the smaller app carried the call through the network change.

The meeting finished before I thought about the VPN again

Once the hotspot took over, I completed the presentation.

The client approved the revised direction. I sent the updated deck through the workspace while everyone was still on the call and watched the upload finish.

There was no dramatic jump in speed. The meeting app had lowered and restored its own video quality as the connection changed.

The difference was that the session survived.

That made the earlier 146 Mbps result feel almost irrelevant. It had described the hotel network during one quiet moment. It had said nothing about what the VPN would do when screen sharing increased the load, the Wi-Fi weakened or the laptop changed networks.

The established provider still had more locations, a longer public record and more independent reviews. The smaller service has fewer server choices and a shorter history.

But the call had created a narrower comparison.

One provider gave me many servers to try after each failure. The other prevented a three-second network interruption from becoming another login, another apology and another missed part of the conversation.

I had been troubleshooting the wrong number

Before that meeting, I treated VPN performance as a combination of server distance and download speed.

Those numbers still have value. A distant or overloaded route can make any call worse.

They do not answer the most important question for live communication:

What happens when the underlying network changes?

The established VPN rebuilt the tunnel, and the meeting removed me.

Turning the VPN off preserved the video but separated it from the protected workspace, files and browser session around it. Joining by phone kept me audible but took away the screen and tools I needed to do the work.

The smaller app kept the laptop, meeting and client files together through the interruption.

That changed what I would test before the next important call. I would confirm there was enough bandwidth, start a meeting, share my screen and switch between Wi-Fi and mobile data.

A speed test shows how quickly the network moves while everything is stable.

For this meeting, the better VPN was the one that stayed in the conversation when the network did not.