Fixing "Your Internet Connection is Unstable" in Microsoft Teams on macOS

Why Teams Is More Sensitive Than Zoom

You're on a Microsoft Teams call and see the dreaded yellow banner: "Your network connection is unstable." You open another tab and run a speed test. 150 Mbps down, 20 Mbps up. Everything looks fine. So why is Teams complaining?

The answer: Teams is built on a different set of network assumptions than Zoom, and it's significantly more sensitive to packet loss and jitter.

Teams Uses WebRTC with Aggressive Monitoring

Teams' real-time media stack is built on WebRTC, but with a monitoring layer that's far more aggressive than what you'll find in Zoom or other calling apps. Teams monitors packet loss, round-trip latency, and jitter at sub-second intervals. Every time a packet is late or missing, Teams' internal algorithms bump up a badness counter.

Here's the critical difference:

This isn't a bug in Teams; it's by design. Microsoft prioritizes call quality over resilience. The trade-off is that Teams calls sound pristine when the network cooperates, but it becomes overly cautious on mediocre connections. Zoom takes the opposite approach: be lenient so calls rarely drop, even if audio quality degrades slightly.

Why Your Internet Feels "Fine" but Teams Doesn't

A speed test measures sustained bandwidth. It sends large chunks of data and calculates the average throughput. A Teams call needs something entirely different: it needs every single packet to arrive on time, in order, with minimal variation.

Common scenarios where this breaks down:

• Micro-drops: Your ISP drops 0.3% of packets for 15 seconds every few minutes. Speed test: 100%. Teams call: "unstable."
• Buffer bloat: Your router's buffer is too large. Packets arrive, but some are delayed 50ms+ while the router processes them. Speed test: fine. Teams' latency metric: red.
• VPN routing issues: Your VPN client is splitting tunneling (routing Teams' traffic and other traffic differently), causing Teams packets to take longer paths or encounter congestion. Speed test: sees aggregate speed. Teams: sees the congested sub-path.
• Wi-Fi contention: Your Wi-Fi card is competing with interference or background scanning. Downloads work fine. Real-time audio/video can't absorb the delays.

The bottom line: Teams is detecting real network problems that your speed test can't see.

Reading Teams' Connection Status Indicators

Teams provides two main visual indicators of network trouble, and they mean different things:

The Yellow Banner: "Your network connection is unstable"

This appears at the top of the call screen and indicates that Teams detected degraded network conditions. The call will continue, but you might notice audio stuttering, video freezing, or participants' video quality dropping automatically. Yellow means Teams is adapting to poor conditions: it's reducing bitrate, possibly dropping video resolution, or increasing latency compensation. The call remains functional but noticeably degraded.

The Red Banner: "You've lost network connection"

This is more severe. It typically means packet loss exceeded 5–10% or latency spiked above 500ms for sustained periods. The call might freeze, audio becomes garbled, or the entire connection drops. Red is a critical failure state.

Accessing Teams' Call Health Stats

During an active Teams call, you can view detailed network statistics:

1. Click the "..." (more options) button during the call
2. Select "Call health"
3. A panel opens showing real-time network metrics

What you'll see in Teams' call health panel:

• Round trip time (RTT): Measured in milliseconds. Good is under 100ms. Over 150ms causes noticeable delay in conversation flow.
• Received audio packet loss: Percentage of audio packets arriving at your Mac. Below 1% is good. Above 2% causes clipping and glitching.
• Sent audio packet loss: Percentage of your audio packets reaching the other person. Same thresholds apply.
• Jitter (for audio): Variation in packet arrival times, shown as average variation in milliseconds. Below 20ms is good; above 40ms causes noticeable buffering.
• Bandwidth estimates: Current up/down bandwidth being used. If this is maxed out, you have congestion.
• Video resolution and frame rate: If Teams has downgraded these, your network is the limiting factor.

The critical insight: these stats only appear during a call. By then, the damage is visible to participants. Ideally, you'd want to check these metrics before joining a call so you can preemptively switch to Ethernet or fix the problem.

Teams' Specific Network Requirements

Teams uses specific protocols and ports that differ from other calling apps. Understanding these requirements helps you diagnose routing and firewall issues.

Ports and Protocols

UDP (media traffic): Teams prefers UDP for audio and video because it's lower-latency than TCP (it doesn't retransmit lost packets, which is the right trade-off for real-time audio/video).

• UDP ports 3478–3481: STUN/TURN signaling for NAT traversal
• UDP ports 50000–59999: Media relay and direct media paths

TCP (signaling): Teams uses TCP for control messages and fallback when UDP is blocked:

• TCP port 443: HTTPS signaling, also used for TURN over TLS

Direct Media vs. Relay Paths

Teams attempts to establish a direct media path between your Mac and the other participant (peer-to-peer). This is the lowest-latency option. However, if you're behind a restrictive NAT, firewall, or VPN, Teams can't establish a direct path. It falls back to Transport Relay (TURN) servers, which are Microsoft-hosted intermediaries that forward your media packets.

Here's the problem: if your connection negotiates a TURN relay instead of a direct path, all your audio and video packets travel through Microsoft's data centers first, adding 30–100ms of extra latency. Combined with your base latency, this can push you over Teams' 150ms threshold, triggering the "unstable" warning.

Why does relay negotiation fail?

• VPN blocking UDP: Your VPN client only allows TCP, so Teams can't use UDP media. It falls back to TCP media (slower and higher-latency) or relay.
• Router UPnP disabled: Teams uses UPnP (Universal Plug and Play) to request port forwarding. If your router has UPnP disabled, Teams can't negotiate an open port and uses relay instead.
• Restrictive firewall rules: If your firewall blocks the UDP ports Teams needs, it forces relay.
• ISP-level blocking: Some ISPs block or throttle UDP traffic. Teams detects this and uses relay or TCP fallback.

DNS and Service Discovery

Teams relies on DNS to discover signaling servers and relay endpoints. Slow DNS servers (resolution taking 500ms+) can cause connection delays and fallback issues. If your DNS server is unreliable or misconfigured, Teams might fail to discover the optimal relay path and default to a slower one.

Teams connects to regional servers based on your geography. If DNS resolution fails, Teams might retry with a different endpoint, causing visible latency spikes during the retry period.

6 Fixes for Teams Instability on Mac

Fix 1: Disable VPN Split Tunneling Conflicts

The combination of a VPN and Microsoft Teams is a common source of instability. Many corporate VPNs use split tunneling, which routes certain traffic (like Microsoft 365 services) directly and other traffic through the VPN tunnel. This can cause Teams media packets to take inconsistent routes, resulting in high jitter or asymmetric latency (fast upload, slow download, or vice versa).

Diagnosis: Disable your VPN entirely and run a Teams test call. If calls immediately stabilize, your VPN is the culprit.

Fix options:

• Request your IT team to exclude Teams' UDP port ranges (3478–3481, 50000–59999) from VPN tunneling. Route these ports directly to the internet, not through the VPN.
• If your VPN is personal (not corporate), switch to a different provider or disable it during Teams calls.
• As a temporary workaround, switch to a wired Ethernet connection while on the VPN. Wired connections are less sensitive to the routing inconsistencies that VPNs introduce over Wi-Fi.

Fix 2: Clear Teams Cache and Temporary Files

Teams accumulates cached data, temporary files, and corrupted media buffers over time. A bloated cache can cause network stack issues and stale DNS entries, leading to connection timeouts or slow recovery after network hiccups.

How to clear Teams cache on Mac:

For the new Teams app (the current version as of 2026), the cache is stored in different locations than classic Teams:

This deletes the new Teams' application cache and container data. You'll need to sign back in after restarting Teams.

If you previously used classic Teams and still have its cache around, you can also clean that up:

Note: Quit Teams completely before clearing the cache. After deleting, restart Teams, sign back in, and run a test call.

Fix 3: Disable Hardware Acceleration

Teams can use your GPU to accelerate video encoding/decoding. On some Macs (especially older models or those with integrated GPUs), hardware acceleration causes frame drops or latency because the GPU can't keep up, forcing the software encoder to fall back, but by then, frames are already queued and delayed.

How to disable hardware acceleration in Teams:

1. Open Microsoft Teams
2. Click your profile icon (top right)
3. Select Settings
4. Go to General
5. Check the box for "Disable GPU hardware acceleration" (the exact label may vary slightly by Teams version)
6. Restart Teams

After disabling, run a test call. If the "unstable" warning disappears, hardware acceleration was introducing jitter.

Fix 4: Disable AWDL Interference

Apple Wireless Direct Link (AWDL) is the protocol behind AirDrop and AirPlay. It periodically forces your Wi-Fi radio to scan for nearby Apple devices, briefly interrupting your main Wi-Fi connection. For Zoom, this causes occasional micro-drops that Zoom tolerates. For Teams, these micro-drops hit the 0.5% packet loss threshold and trigger warnings.

Check if AWDL is active:

If it returns "active," AWDL is running. To temporarily disable it:

Run a Teams test call. If it stabilizes, disable AirDrop permanently:

1. System Settings → General → AirDrop
2. Set AirDrop to "No One"

Note: macOS will re-enable AWDL after sleep/wake or reboot, so disabling AirDrop is the persistent solution.

Fix 5: Prioritize Teams Traffic in Router QoS

Many modern routers have Quality of Service (QoS) settings that can prioritize certain traffic. If your router misclassifies Teams' UDP packets (treating them as low-priority peer-to-peer traffic instead of business-critical media), it can throttle or deprioritize them during congestion.

How to set up QoS for Teams:

1. Log into your router's admin page (usually 192.168.1.1 or 192.168.0.1)
2. Find QoS or Traffic Management settings
3. Create a rule that prioritizes:
   • UDP ports 3478–3481 (STUN/TURN)
   • UDP ports 50000–59999 (media relay)
   • TCP port 443 (signaling and HTTPS)
4. Set these to "High" priority
5. Save and restart the router

If your router doesn't have granular QoS controls, try disabling QoS entirely (if your bandwidth is ample) or upgrading to a modern Wi-Fi 6 router that handles NAT and concurrent connections more efficiently.

Fix 6: Switch to a Faster DNS Provider

Slow or unreliable DNS servers cause Teams to misdetect network endpoints and potentially negotiate a slower relay path. Switching to a fast, reliable DNS provider can reduce connection negotiation latency and improve endpoint discovery.

How to change DNS on Mac:

1. System Settings → Network → Wi-Fi (or Ethernet)
2. Click Details
3. Go to the DNS tab
4. Click the + button and add these DNS servers:
   • 1.1.1.1 and 1.0.0.1 (Cloudflare, fastest average resolution)
   • or 8.8.8.8 and 8.8.4.4 (Google, most reliable uptime)
5. Click OK and apply

Restart Teams and test. DNS changes take effect immediately, so you should notice improvements right away if DNS was the bottleneck.

Terminal Diagnostics for Teams

Beyond the six fixes, you can run terminal commands to diagnose Teams-specific connectivity issues.

Test Connectivity to Teams' Signaling Servers

Teams connects to regional servers. Test your latency and packet loss to Teams' endpoints:

This pings Teams' Teams Relay server for your region. Look at the packet loss percentage and latency (min/avg/max). If packet loss is above 1%, you've found a problem that Teams will also detect.

Expected output:

Check Active Teams Connections

To see which network ports and addresses Teams is currently using:

This lists all active network connections for the Teams process, showing protocol (UDP or TCP), local and remote addresses, and ports. Look for entries using UDP ports in the 3478–3481 range or higher ephemeral ports. If you only see TCP connections on port 443, Teams is using relay or TCP fallback, which explains the added latency.

Monitor Teams' Network Activity in Real-Time

To see ongoing network activity:

This opens a live network traffic monitor. Start a Teams call and watch the traffic. If you see your connection switching between different IP addresses (relay hopping), or if upload/download is asymmetric (e.g., 5 Mbps down, 0.5 Mbps up), something is limiting Teams' media path.

The Advantage of Continuous Monitoring

Why Continuous Monitoring Matters for Teams

The core problem with troubleshooting Teams instability is timing. You join a call, encounter the "unstable" warning, and by then, 50 people can see your video freezing. You're forced to investigate in real-time while participants wait.

A continuous network monitor changes this dynamic:

• Predictive: Before you click "Join meeting," you see that packet loss is at 2.1%. You know to switch to Ethernet first.
• Pattern detection: If you see packet loss spikes every 30 seconds with perfect predictability, that's likely a background process (iCloud sync, Dropbox, Time Machine) saturating your upload. You can pause that process before the meeting.
• Intermittent issue tracking: The Teams call health stats only capture data during the call. A continuous monitor running in the background for the past hour shows whether instability is intermittent or chronic.
• Post-call diagnostics: If a call was unstable, you can check the monitor's history to see exactly when packet loss spiked and correlate it with system events (a Spotlight index finished, iCloud checked for updates, etc.).

The Real Solution: Network Resilience, Not Better Apps

Teams' sensitivity isn't a flaw; it's a feature. By complaining early (at 0.5% packet loss instead of 2%), Teams is telling you that your network has degraded from "excellent" to "acceptable for browsers" but "concerning for real-time communication."

The fix isn't to make Teams more lenient. The fix is to fix the underlying network. And the first step to fixing a network is seeing what's wrong.

Frequently Asked Questions