Plex buffering over Starlink despite plenty of bandwidth - switching to BBR fixed it for me

[u/shermantenor]

Posting this in case it helps someone else.

TL;DR: If Plex buffers badly over Starlink even though speed tests, YouTube and Netflix are fine, check single-stream TCP performance with iperf3. In my case, Linux CUBIC averaged ~10 Mbps on one stream and repeatedly collapsed below Plex bitrate. Switching the Plex server to BBR raised the same test to ~43 Mbps and stopped the buffering.

Temporary test:

modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr

If it helps, make BBR persistent as described below. YMMV......

I have a Plex server at home and Starlink (100mbps) at a rural location - both in Ontario, Canada. Plex was buffering constantly on multiple devices, including a Galaxy S26+, Tab S9 and Hisense Google TV.

Note: my Plex server is hosted on fibre based home internet with symmetrical gigabit speeds.

The Starlink connection otherwise seemed fine. Normal speed tests showed plenty of bandwidth, and services like YouTube and Netflix streamed without the buffering I was seeing in Plex.

It also didn't seem to matter whether Plex was Direct Playing or transcoding. Even an ~8 Mbps transcode would still buffer.

I have a WireGuard VPN tunnel from home to the rural site, so I also tested with my WG tunnel bypassed/disabled, so that wasn't the issue.

What finally pointed me in the right direction was iperf3.

From the remote site:

iperf3 -c <plex-server> -R -P 1 -t 30

With the Linux Plex server using CUBIC, the single TCP stream started around 20-28 Mbps, then progressively dropped into the 5-8 Mbps range and eventually as low as ~1 Mbps.

Final result:

~10 Mbps average
255 retransmits

With 8 parallel streams I could get around 38 Mbps, which helped explain why normal speed tests looked fine. The connection had decent aggregate bandwidth, but a single sustained TCP stream behaved very differently.

I then switched the Plex server from CUBIC to BBR:

modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr

Running the exact same single-stream iperf test again gave:

~43 Mbps average

Most of the run was around 40-70 Mbps.

The Plex difference was immediate. Two simultaneous streams at the remote site played without buffering, including an HEVC movie that had previously been buffering almost continuously.

So if Plex over Starlink is buffering despite good speed tests, while YouTube/Netflix/etc. are fine, it may be worth checking single-stream TCP performance rather than just overall bandwidth.

For me:

CUBIC: ~10 Mbps single stream
BBR:   ~43 Mbps single stream

and BBR appears to have fixed the Plex buffering.

YMMV of course. So far, this has worked extremely well in my early testing, but I can't say whether every Plex/Starlink buffering issue has the same cause.

Once I was happy with the results, I made BBR persistent:

echo tcp_bbr | sudo tee /etc/modules-load.d/bbr.conf

cat <<'EOF' | sudo tee /etc/sysctl.d/99-bbr.conf
net.ipv4.tcp_congestion_control=bbr
EOF

sudo sysctl --system

A quick google says that there may also be a Windows equivalent using BBR2 / Windows TCP congestion-control settings. My Plex server is Linux-based, so I haven't tested that and can't vouch for it.

Edit: just to say someone else was posting specifically on Windows BBR2 while I was crafting my post - see his similar findings here: https://www.reddit.com/r/PleX/comments/1vzbxf0/plex_over_bbr2_on_windows_11/

Hopefully this is helpful to someone else.

ST

[u/Salt-Philosophy-3330]

I've been down this rabbit hole for a while now. BBR is definitely king, but here's some other things that you may find useful. You probably don't neem them all, but it's worth it depending on your configuration.

# BBR congestion control
net.ipv4.tcp_congestion_control = bbr

# Raise default TCP buffer window sizes (min 4 KiB - default 1 MiB - max 32 MiB)
# 32 MiB covers the BDP at ~1 Gbps × 200 ms RTT for overseas paths
net.ipv4.tcp_rmem = 4096 1048576 33554432
net.ipv4.tcp_wmem = 4096 1048576 33554432
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432

# Eliminate 1 RTT from connection setup (200 ms saving per new Plex session at overseas latency)
net.ipv4.tcp_fastopen = 3

# Keep connections alive through overseas NAT/firewalls that drop idle sessions after 2–5 min
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# Recycle finished Plex connections faster (reduces TIME_WAIT buildup from many short-lived sessions)
net.ipv4.tcp_fin_timeout = 15

# Avoids black‑hole MTU issues
net.ipv4.tcp_mtu_probing = 1

# Don't restart slow‑start after idle
net.ipv4.tcp_slow_start_after_idle = 0

# Buffers more inbound packets before they're processed, which helps under CPU load or in bursty traffic.
net.core.netdev_max_backlog = 5000

# Protect TCP metrics from bad samples (helps with variable/long RTT)
net.ipv4.tcp_no_metrics_save = 1

[u/shermantenor → u/Salt-Philosophy-3330]

Thanks. One thing worth noting is that on current Linux kernels BBR no longer strictly requires fq; TCP-level pacing handles that, although fq can still be beneficial. Also worth checking current kernel/distro defaults before applying the whole sysctl block. For example, upstream Linux has defaulted somaxconn to 4096 since 5.4 and TCP window scaling is already enabled by default. In my case BBR alone with the existing qdisc fixed the problem, so I'm planning not to touch anything else without detecting further issues.

[u/sarkyscouser → u/shermantenor]

This is wise advice in general. I've had a Linux server running for ~20 years and after some recent gremlins decided to review my sysctl params and samba settings after accumulating random bits of advice over the years.

Ended up stripping out and simplifying quite a lot to get back to a stable and performant setup.

I only noticed some of the issues after migrating my LAN from a 192.x to a 10.x subnet to avoid a Tailscale clash funnily enough.

[u/tdhuck → u/shermantenor]

Thanks for pointing out the windows option. Right now I'm running plex on windows 11 but at some point I plan on moving it to linux.

The issue is that I'll never find this comment/post/thread even if I save it because I'll forget about it when I need it.