Why Does My Live Stream Keep Buffering? A VPS Troubleshooting Guide

Last updated: July 2, 2026 · Reviewed by StreamingVPS.com Engineering Team

Live stream buffering almost always traces back to one of three things: the server can’t produce video fast enough (CPU or disk I/O maxed out), the server can’t push video fast enough (bandwidth or NIC saturation), or the viewer’s own connection can’t keep up (last-mile bandwidth or Wi-Fi jitter). Fixing it means measuring all three during the actual buffering window, not guessing and raising the bitrate. Most buffering complaints on a properly-sized streaming VPS come down to a bitrate ladder that doesn’t match real-world viewer bandwidth, not a broken server.

What Causes Live Stream Buffering?

Buffering happens when the video player’s buffer empties faster than new segments arrive. That’s the full mechanical explanation — everything else is about why segments arrive late. In practice we see four causes repeatedly across the Wowza, NGINX RTMP, Ant Media, and MistServer instances we manage:

1. Encoder-side CPU exhaustion. If you’re transcoding (not just relaying), x264/x265 encoding is CPU-bound. A libx264 -preset medium 1080p60 encode needs roughly 3.5–4.5 vCPU cores of sustained headroom; -preset veryslow can need 6+. Undersize the VPS and frames get dropped or delayed before they’re even packaged into segments.
2. Outbound bandwidth saturation. Each concurrent viewer pulling a 6 Mbps 1080p HLS rendition adds 6 Mbps to your egress. 100 concurrent viewers on that rendition alone is 600 Mbps — well past what a 1 Gbps port can sustain once you add overhead, TCP retransmits, and other renditions.
3. Disk I/O contention, usually on shared/budget VPS plans where noisy neighbors compete for the same physical disk. HLS/DASH segment writes and reads are small and frequent; slow disk I/O delays segment availability even when CPU and network look fine.
4. Viewer-side network limits — the one cause that has nothing to do with your server. Mobile networks, congested home Wi-Fi, and VPNs routinely can’t sustain 6 Mbps continuously even if they can burst to it briefly.

Is Your VPS the Bottleneck, or Is It the Network?

Check three numbers on your server during the exact window a viewer reports buffering: CPU usage (including steal time), outbound bandwidth utilization, and disk I/O wait. If all three sit comfortably below capacity while the viewer buffers, the problem is downstream of your VPS.

# CPU, including steal time (%st) — critical on shared VPS hosts
top -o %CPU

# Real-time outbound bandwidth by interface
iftop -i eth0

# Disk I/O wait
iostat -x 2

# Path quality to a specific viewer region
mtr --report --report-cycles 50 <viewer-region-test-ip>

%st (steal time) is the number most people skip. It reflects CPU cycles your VPS wanted but the hypervisor gave to another tenant. We’ve seen budget VPS plans show 15–20% steal time during peak hours — your encoder thinks it has 4 full cores, but only gets 3.2, and frames start queuing. This is one of the concrete reasons StreamingVPS.com provisions dedicated vCPU allocations on streaming-tier plans rather than oversold shared cores — it’s a direct, measurable fix for a specific failure mode, not a marketing claim.

How Much Bandwidth and CPU Do You Actually Need?

Size for your busiest expected minute, not your average. A single 1080p60 H.264 stream at 6 Mbps sustained needs roughly that much guaranteed egress per concurrent viewer of that rendition, multiplied across your full ABR ladder mix. For encoding, budget vCPU cores per the table below — these are sustained-load numbers from our own transcoding benchmarks, not vendor spec-sheet best cases.

These numbers assume libx264 -preset medium; dropping to veryfast cuts CPU need by roughly 40% at the cost of compression efficiency (higher bitrate for the same visual quality), which is often the right tradeoff on a smaller VPS. Wowza’s own performance and tuning documentation and NGINX’s RTMP module wiki both confirm CPU, not bandwidth, is usually the first limit hit on transcoding workloads — bandwidth tends to bite first on pure relay/restreaming setups.

Step-by-Step: Diagnosing Buffering on a Live Streaming VPS

1. Reproduce it while watching server metrics. Have someone stream while you watch top, iftop, and iostat live. If nothing spikes, the bottleneck isn’t your server.
2. Check the encoder’s own buffer settings. An undersized bufsize relative to maxrate in FFmpeg causes rate-control overshoot that looks like buffering downstream:

   ffmpeg -i rtmp://source -c:v libx264 -preset medium \
     -b:v 4500k -maxrate 4500k -bufsize 9000k \
     -g 60 -keyint_min 60 -sc_threshold 0 \
     -c:a aac -b:a 128k -f flv rtmp://your-vps:1935/live/stream

   bufsize at roughly 2x maxrate and a GOP (-g) matching your segment duration (e.g., 60 frames at 30fps = 2-second GOP, matching a 2-second HLS segment) keeps rate control predictable.
3. Check segment/fragment duration on the server. In NGINX RTMP’s hls block, hls_fragment 2s; hls_playlist_length 10s; is a solid starting point — segments under 2 seconds increase request overhead per viewer; segments over 6 seconds increase startup and rebuffer-recovery latency.
4. Confirm ABR is actually working. Open your HLS manifest in a text editor or via curl and confirm multiple #EXT-X-STREAM-INF renditions exist. A single-rendition “ABR” ladder isn’t ABR — it’s one bitrate with no fallback.
5. Check player-side buffer configuration. hls.js defaults (maxBufferLength: 30) are usually fine; video.js and JW Player have similar tunables. Don’t shrink these to “reduce latency” unless you’ve also implemented LL-HLS or a low-latency protocol — an undersized player buffer with a standard-latency stream just trades startup smoothness for more frequent stalls.
6. Isolate the network path. Run mtr from a VPS in the viewer’s rough region toward your origin to spot packet loss or routing detours a CDN would otherwise absorb.

Player-Side vs. Server-Side Buffering: What’s the Difference?

Player-side buffering is intentional — a few seconds of pre-loaded video that absorbs normal network jitter without interrupting playback, controlled by the player’s buffer-length setting. Server-side buffering (more accurately, “stalling”) happens when your origin can’t produce or deliver the next segment in time, forcing the player to pause and wait. The practical test: if the pause happens once at stream start, that’s normal player buffering. If it recurs every 30–90 seconds throughout playback, that’s the server or network failing to keep pace, and it needs the diagnosis steps above, not a player-config tweak.

Frequently Asked Questions

Why does my live stream buffer for some viewers but not others?
This almost always points to the viewer’s last-mile network or device, not your server — if your VPS were the bottleneck, every viewer pulling the same rendition would stall at roughly the same time. Check whether the affected viewers are on the same ISP, region, or Wi-Fi, and confirm your player supports adaptive bitrate so it can step down instead of stalling.

Does raising the bitrate always fix buffering?
No — if the bottleneck is viewer bandwidth or your VPS’s upstream port, a higher bitrate makes buffering worse, not better. Raise bitrate only after confirming your server’s CPU, disk I/O, and network throughput all have headroom to sustain it continuously.

Will switching from RTMP to SRT or WebRTC fix my buffering?
Sometimes — SRT adds packet-loss recovery over lossy networks and WebRTC cuts latency dramatically, but neither fixes an undersized VPS or an under-provisioned viewer connection. Protocol changes solve transport-layer packet loss and latency, not raw capacity shortfalls.

What’s the difference between player-side buffering and server-side buffering?
Player-side buffering is the player deliberately holding a few seconds of video to smooth network jitter — normal and controlled by settings like hls.js’s maxBufferLength. Server-side stalling happens when the origin can’t produce or deliver segments fast enough, showing up as repeated rebuffer events rather than a one-time startup delay.

How do I tell if buffering is caused by my VPS or the viewer’s internet connection?
Pull up your server’s CPU, memory, and outbound bandwidth graphs during the exact buffering window — if all three are well under capacity, the problem is downstream of your server. If CPU is pegged or bandwidth is saturated at your port limit, the VPS is the bottleneck.

Get a VPS Sized to Actually Stop Buffering

Most buffering fixes come down to one root fact: the VPS wasn’t sized for the CPU or bandwidth the stream actually needs, or the ABR ladder wasn’t built to match real viewer bandwidth. StreamingVPS.com’s plans come with Wowza, NGINX RTMP, Ant Media, Red5, Flusonic, or MistServer pre-installed and tuned, plus dedicated vCPU allocations that eliminate the steal-time problem covered above. Check current plans and specs or read our Wowza setup guide for sizing help — go live in 60 seconds, correctly sized the first time.