Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.


If a VPN disconnects during video calls, do not assume the VPN app is the only cause. Real-time calls expose brief upload stalls, packet loss, route changes, Wi-Fi roaming, and device pressure that ordinary browsing can hide. Reproduce the problem with one variable changed at a time, then send the evidence to the owner of the failing layer.
Key Takeaways
- A speed-test headline is not enough; calls depend on sustained upload, latency, jitter, and packet loss.[1][3]
- First learn whether the VPN tunnel drops, the meeting reconnects, or only audio/video freezes.
- Compare the same call, device, network, and time window while changing only one VPN variable.
- A no-VPN comparison is useful only where policy permits it.
- Keep a timestamped test log so the VPN, ISP, or meeting provider can inspect the correct event.
Review the complete VPN guide first if tunnel, server, and exit-route terms are unfamiliar.
Three failures can feel identical to a participant but point to different owners.
| What you observe | Likely layer | Evidence to collect |
|---|---|---|
| VPN app reports reconnecting and all traffic pauses | Tunnel, server path, or base network | VPN event time, server, protocol, Wi-Fi state |
| Meeting says reconnecting but other websites work | Meeting route or service | Meeting diagnostics, region, participant impact |
| Video freezes but audio continues | Bandwidth, packet loss, CPU, or camera load | Call statistics, CPU load, resolution |
| Entire device loses Wi-Fi | Local access point, driver, roaming, or power saving | Wi-Fi icon, router log, another-device comparison |
| Only your microphone or camera stops | Permission, device, or application | Device selection, permission, app log |
Before changing settings, note the exact symptom and minute. Microsoft Teams exposes round-trip time, jitter, packet loss, bitrate, and device information in real-time telemetry because these measurements help separate network and media problems.[1]
Use a test meeting or a willing colleague. Avoid experimenting during a confidential client call, and follow your employer's network policy.
This is an isolation matrix, not a competition for the best single result. One successful minute does not prove stability, and a different meeting host or resolution makes comparisons weaker.
Your camera sends data continuously. A connection can have fast downloads yet poor upload headroom, especially while another device backs up photos. Zoom publishes different bandwidth needs for one-to-one and group video at different quality levels, so lowering video quality is a valid diagnostic step.[2]
Latency is the travel time for a packet; jitter is variation in that time. A VPN normally adds another routing and encryption step. A distant or congested exit can make delivery less consistent even when average bandwidth looks adequate.
Real-time media cannot always wait for retransmission. Small bursts of loss can create robotic audio, freezes, or a meeting reconnect. Compare loss inside the meeting app with a broader Measure speed under repeatable conditions, but do not treat an internet speed test as proof of the meeting provider's route.
Test next to the router or on Ethernet. Pause other uploads. Disable aggressive battery saving for the meeting and VPN apps only if your device vendor documents that control. If every device loses connectivity, troubleshoot the router or ISP before changing VPN settings.
A geographically closer exit often shortens the route, although internet routing can still be indirect. Test one nearby server long enough to include normal two-way video. If only one exit fails repeatedly, report that exact server and time window.
Protocols respond differently to blocked UDP, lossy networks, roaming, and middleboxes. Use only options exposed by the VPN client, and compare one protocol at a time. Our TCP and UDP guide explains the trade-offs without assuming that one is universally faster.
Turn off HD video, virtual backgrounds, screen sharing, or incoming video as a test. If audio stabilizes, the connection or device may lack headroom. Restore features individually to find the threshold.
Update the operating system, meeting app, VPN client, and network driver using vendor-supported methods. Do not install random “network optimizer” utilities or replace drivers solely because a call dropped.
A VPN cannot repair weak Wi-Fi, ISP packet loss, a conferencing outage, camera or microphone faults, or exhausted device resources. If the controlled matrix points to the tunnel path, compare video-call behavior through AethoVPN while keeping the meeting service, device, and network fixed. A changed encrypted route is a test variable, not a promise of uninterrupted calls.
If the tunnel fails outside calls too, use the broader VPN not connecting guide. If it stays connected but performance is consistently poor, continue with ways to speed up a VPN.
Include time zone, precise timestamps, device and OS version, meeting app version, VPN app version, server location, selected protocol, connection type, and whether the no-VPN baseline was permitted and tested. Add redacted screenshots or exported diagnostics if the vendor provides them.
Do not send meeting links, participant names, chat history, access tokens, full VPN configuration files, or unredacted logs. Ask support which diagnostic format they need before sharing a large capture.
Keep one known-good call profile: the preferred network, a nearby VPN server, a supported protocol, and a conservative video setting. Recheck it after router, operating-system, meeting-app, or VPN updates rather than changing everything during the next important call. Join several minutes early, pause scheduled uploads, and keep a dial-in or approved secondary connection available when the meeting is critical.
Do not treat the fallback as proof that the main path is fixed. Record which path succeeded and repeat the original test later under comparable conditions.
Browsing can retry and buffer data, while a call needs timely two-way delivery. Brief upload stalls, jitter, or packet-loss bursts may be invisible on a normal webpage.
No, but it is a sensible first test because it may shorten the route. Internet peering and server load still matter, so compare a small number of stable exits.
Follow employer policy. If the VPN protects corporate access or is mandatory, do not disable it; provide the test evidence to IT instead.
It can when the current protocol interacts poorly with loss, blocked traffic, or roaming. Use only supported options and keep the server and call conditions constant during the comparison.
No. A headline download result does not show short loss bursts, unstable upload, or the specific route to the meeting service.
Video consumes more bandwidth and device resources than audio. If audio becomes stable, gradually restore resolution, backgrounds, and incoming video to identify the constraint.
Stay near one access point for a controlled test. If roaming is the trigger, record the access-point change and ask IT or the VPN provider about supported mobility behavior.
Contact the ISP when the permitted no-VPN baseline also shows loss or disconnection, multiple devices are affected, or the modem/router records a line drop at the same time.
Disclaimer: This guide is general network troubleshooting, not authorization to bypass an employer's VPN, monitoring, access-control, or data-handling policy.
Sources:
Sources checked 6 September 2026.
Related Articles:
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.