A DDoS attack on a live streaming server almost always targets one of three things: the RTMP ingest port (1935), the HLS/DASH delivery path over HTTP(S), or the raw TCP/UDP stack underneath both — and the fix is layered, not a single setting. You need edge-level scrubbing (a provider or CDN that filters traffic before it reaches your VPS), OS-level hardening (SYN cookies, connection-rate limits, ipset bans), and application-level limits (Wowza/NGINX connection caps, token-gated playback). Skip any one layer and an attacker will find the gap — most successful attacks we’ve dealt with on customer streams exploited the layer nobody had configured, not a sophisticated technique.
Key Takeaways
- Volumetric (SYN/UDP flood) attacks against port 1935 or your HLS delivery ports must be stopped upstream, before traffic reaches your VPS’s network interface — no server-side firewall rule stops a multi-gigabit flood on its own.
- A single unprotected streaming VPS on a standard 1 Gbps or 10 Gbps port can be saturated by a sustained flood in seconds; provider-level DDoS scrubbing (BGP blackhole or Anycast) is the only layer that actually absorbs volumetric traffic.
- Cloudflare’s free/standard proxy protects HTTP(S) delivery (HLS/DASH playlists and segments) but cannot proxy raw RTMP — RTMP ingest still needs provider-level network protection or a TCP proxy service like Cloudflare Spectrum.
- OS-level tuning (net.ipv4.tcp_syncookies, nf_conntrack limits, iptables/nftables rate limiting) stops small-to-medium application-layer floods and connection exhaustion attacks that get past the edge.
- Token-authenticated playback URLs and short-lived signed HLS segments remove the easiest DDoS vector on public streams: bots hammering your CDN or origin with valid-looking but illegitimate segment requests.
What Makes Streaming Servers an Easy DDoS Target?
Live streaming infrastructure is unusually exposed compared to a typical web app. RTMP ingest has to stay open on a predictable port (1935) so any encoder — OBS, a hardware encoder, a mobile app — can connect, which means that port can’t be hidden behind auth-gated HTTP the way an admin panel can. HLS/DASH delivery, by design, serves large numbers of anonymous GET requests for .m3u8 playlists and .ts/.m4s segments every few seconds per viewer, so a flood of fake segment requests looks structurally similar to legitimate traffic at high viewer counts — which makes rate-based detection harder to tune without false-positiving real viewers during a traffic spike.
On top of that, streaming servers run CPU-heavy processes (transcoding, packaging) that degrade fast under load. We’ve seen a 4 vCPU / 8 GB streaming VPS running Wowza go from smoothly serving 300 concurrent HLS viewers to dropping frames and disconnecting encoders under nothing more than 15,000 pps of forged SYN packets — not because the attack was large, but because the encoder’s RTMP handshake retries piled onto an already-strained TCP stack.
How Do DDoS Attacks on RTMP/HLS Servers Actually Work?
Three attack patterns account for almost everything we see against customer streaming VPS instances:
SYN floods against port 1935 — forged TCP SYN packets that never complete the handshake, exhausting the kernel’s connection backlog (net.ipv4.tcp_max_syn_backlog) so legitimate encoders can’t connect. This is the most common attack against RTMP specifically, because 1935 is always open and always expecting new connections.
UDP/volumetric floods against the network link itself — garbage UDP packets (often amplified via DNS, NTP, or memcached reflection) aimed at the VPS’s IP, saturating the uplink regardless of which service is running. This doesn’t care that you’re running a streaming server at all; it just fills the pipe.
HTTP(S) floods against HLS/DASH delivery — repeated GET requests for playlist or segment URLs, sometimes from a real botnet, sometimes scripted. Because these look like normal viewer requests, this is the pattern most likely to slip past a naive rate limiter and hit your origin’s CPU or bandwidth directly.
Which DDoS Protection Layers Actually Stop an Attack?
No single layer covers all three attack patterns. Here’s how they map:
| Attack type | Effective mitigation | Where it must happen |
|---|---|---|
| SYN flood (port 1935) | SYN cookies, tcp_max_syn_backlog tuning, connection-rate limiting | OS/kernel on the VPS, or upstream firewall |
| UDP/volumetric flood | BGP blackhole routing, Anycast scrubbing center | Provider network edge — cannot be stopped on the VPS itself |
| HTTP(S) flood on HLS/DASH | Reverse proxy with rate limiting, signed/token URLs, CDN caching of segments | CDN/edge (e.g., Cloudflare) + application layer |
| RTMP connection exhaustion | Max-connections cap in Wowza/NGINX-RTMP, ipset auto-ban of abusive IPs | Application config + OS firewall |
| Slowloris-style HTTP exhaustion | Connection timeouts, limit_conn in NGINX, worker connection caps | Web server config |
How Do You Configure a VPS to Survive a Volumetric Attack?
You can’t out-firewall a multi-gigabit flood on a single VPS uplink — that part has to be handled by your hosting provider’s network (BGP blackhole, scrubbing center, or an upstream Anycast network). What you can control on the box itself is everything downstream of that: making sure the server doesn’t fall over the moment traffic gets ugly, and closing the smaller attack surfaces that don’t require volumetric scale.
A baseline hardening pass we run on every managed streaming VPS looks like this:
# Enable SYN cookies (survives SYN floods without dropping the backlog)
sysctl -w net.ipv4.tcp_syncookies=1
# Increase the half-open connection backlog
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
# Reduce SYN-ACK retries so half-open connections clear faster
sysctl -w net.ipv4.tcp_synack_retries=2
# Cap new connections per source IP to the RTMP port (nftables)
nft add rule inet filter input tcp dport 1935 ct state new limit rate 20/second per ip counter dropFor NGINX-RTMP or an HLS reverse proxy, limit_conn and limit_req zones cap how many simultaneous connections or requests-per-second a single IP can hold against your segment delivery paths — set generously enough not to cut off a legitimate viewer behind CGNAT (which can share an IP with hundreds of other real viewers), but tight enough to blunt a scripted flood. On our own edge nodes we typically start limit_req at 15 requests/second per IP for .m3u8/.ts paths and adjust upward only if we see real playback errors in logs.
Fail2ban tied to NGINX or Wowza access logs is worth running as a second layer — it auto-bans IPs that request segments at a rate no real HLS player would sustain, feeding those bans into ipset for near-zero-overhead blocking at the kernel level rather than parsing rules per-packet in iptables.
Is Cloudflare Enough to Protect a Live Stream?
Partially. Cloudflare’s standard proxy (orange-cloud) sits in front of HTTP(S) traffic, so it’s genuinely effective at absorbing HLS/DASH-directed floods and caching segment requests before they hit your origin. It does not proxy raw RTMP — RTMP is a persistent TCP protocol on port 1935, not HTTP, and Cloudflare’s free/pro tiers simply don’t route it. If your ingest port needs edge protection, you’re looking at either Cloudflare Spectrum (a paid TCP/UDP proxy product) or provider-level network protection at your VPS host — which is why we bake network-layer DDoS filtering into StreamingVPS.com plans by default rather than leaving RTMP exposed and telling customers “just add Cloudflare.”
The practical split we recommend: put your HLS/DASH delivery domain behind a CDN/WAF for the viewer-facing side, and rely on host-level network scrubbing plus the OS hardening above for the RTMP ingest side. Trying to force RTMP through an HTTP-oriented CDN usually just adds latency without adding real protection.
What Does DDoS-Protected Streaming Hosting Cost?
| Protection level | Typical monthly cost (add-on) | Covers |
|---|---|---|
| None (bare VPS) | $0 | Nothing — first sizeable flood takes the server offline |
| Basic provider-level filtering (included on most reputable streaming VPS plans) | $0–$10 | Volumetric floods up to a few Gbps, common SYN/UDP patterns |
| Dedicated always-on scrubbing (enterprise-tier) | $50–$300+ | Sustained multi-Gbps attacks, targeted/persistent attackers |
| Cloudflare Spectrum (TCP/UDP proxy for RTMP) | Custom/enterprise pricing | RTMP-specific edge proxying, on top of host-level protection |
For most independent streamers, churches, and small-to-mid businesses running one or two encoders, provider-level filtering that’s already included in a managed streaming VPS plan plus the OS hardening steps above is enough. Enterprise scrubbing tiers make sense once you’re a visible target — competitive esports events, contested political streams, or platforms that have already been hit once tend to justify the extra spend.
FAQ
Can Cloudflare protect my RTMP ingest port?
No — Cloudflare’s standard proxy only routes HTTP(S) traffic, not raw RTMP on port 1935. RTMP needs either Cloudflare Spectrum (a paid TCP proxy product) or DDoS filtering at the VPS network/provider level.
What’s the difference between a SYN flood and a UDP flood?
A SYN flood sends incomplete TCP handshake requests to exhaust a server’s connection backlog, while a UDP flood sends high-volume garbage packets to saturate the network link itself — SYN floods are mitigated with kernel tuning (SYN cookies), UDP floods require upstream network scrubbing.
Will rate limiting block real viewers on shared IPs?
It can, if set too aggressively — viewers behind carrier-grade NAT or corporate proxies can share one public IP with hundreds of other people, so per-IP limits for HLS segment requests should be tuned generously (we start around 15 requests/second per IP) and monitored for false positives.
Do I need enterprise DDoS protection for a small streaming setup?
Not usually — basic provider-level network filtering plus OS-level hardening (SYN cookies, connection limits, fail2ban) is sufficient for most independent streamers and small businesses; enterprise scrubbing tiers are worth the added cost mainly for high-visibility or previously-targeted streams.
Does DDoS protection add latency to a live stream?
Network-level scrubbing typically adds negligible latency (low single-digit milliseconds) since traffic is filtered at the edge before reaching your origin; a poorly configured HTTP proxy or overly aggressive rate limiter is far more likely to introduce noticeable delay or dropped connections than the protection layer itself.
Get Protected Before You Need It
DDoS mitigation is one of those things that’s cheap to configure in advance and expensive to improvise mid-attack. Every StreamingVPS.com plan ships with network-level DDoS filtering and pre-installed streaming engines (Wowza, NGINX RTMP, Ant Media, Red5, Flussonic, MistServer) already hardened against the attack patterns above — get a pre-installed, DDoS-protected streaming VPS from StreamingVPS.com and go live in 60 seconds without having to build this stack yourself.
Last updated: July 3, 2026 · Reviewed by the StreamingVPS.com Engineering Team.
