Streaming Server Firewall Ports: RTMP, HLS, SRT & WebRTC Explained

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

The port you need to open depends entirely on the protocol: RTMP publishing requires TCP 1935, HLS and DASH are delivered over ordinary HTTP/HTTPS (80/443), SRT needs a single UDP port you choose yourself (commonly 9998 or 10080), and WebRTC needs a wide UDP media range — often 40000–65535 — plus TCP/UDP 3478 for STUN/TURN. Get any of these wrong and the symptom is almost always the same: your encoder shows “connected,” but no video ever appears on the player, or viewers see an endless spinner while packets quietly die at the firewall.

We manage streaming engines on VPS infrastructure for a living, and misconfigured firewalls are one of the top three support tickets we see in the first hour after someone spins up a self-managed box — right behind wrong stream keys and codec mismatches. This guide walks through exactly which ports each protocol needs, why, and how to open them correctly at both the OS level and the cloud provider level.

Why Does My Encoder Connect But My Stream Never Goes Live?

This is the single most common firewall symptom we see. OBS or your hardware encoder shows a green “connected” indicator, bitrate climbs on the local preview, but the stream never appears on the player — or it appears for a few seconds and then drops. Nine times out of ten, this means the connection handshake succeeded on a port that’s open (often because outbound traffic and the initial TCP SYN got through), but the actual media stream is being blocked somewhere in the path, usually because:

1. The OS firewall (ufw/iptables) allows the control port but not the full range the protocol actually needs.
2. The cloud provider’s security group (AWS, DigitalOcean, Vultr, etc.) is a separate allow-list from the OS firewall, and it wasn’t updated to match.
3. A middlebox — corporate proxy, ISP-level NAT, or a home router doing “SIP ALG”-style RTMP inspection — is interfering with the stream after the initial handshake.

On a stock Ubuntu VPS with ufw enabled, running sudo ufw status is the fastest first diagnostic — if the port you expect isn’t listed as ALLOW, that’s your answer. On streamingvps.com’s pre-installed engine images we open all protocol-specific ports by default at both the OS and provider level, which is the single biggest reason customers migrating from a bare VPS tell us their “randomly failing stream” problem disappears — there was never anything wrong with their encoder settings.

What Port Does RTMP Need to Go Live?

RTMP (Real-Time Messaging Protocol) publishes over TCP port 1935. This is true whether you’re pushing to Wowza Streaming Engine, NGINX with the nginx-rtmp-module, Ant Media Server, or Red5 Pro — 1935 has been the de facto standard since RTMP’s Flash-era origins and every mainstream encoder (OBS, vMix, hardware units from Teradek/AJA) defaults to it.

For encrypted RTMP (RTMPS), expect a different port depending on the engine: Wowza commonly runs RTMPS on 443 so it blends with normal HTTPS traffic through restrictive corporate firewalls, while some NGINX configurations use a dedicated port like 1936. Check your specific engine’s config — rtmp { server { listen 1935; ... } } in nginx.conf, or the Application-level port binding in Wowza Streaming Engine Manager.

# ufw example — open RTMP on Ubuntu
sudo ufw allow 1935/tcp

# iptables equivalent
sudo iptables -A INPUT -p tcp --dport 1935 -j ACCEPT

On a 2 vCPU / 4 GB test VPS, we’ve pushed a single 1080p60 RTMP ingest at 6 Mbps with zero dropped frames once port 1935 and outbound bandwidth were confirmed clean — the port itself doesn’t add meaningful overhead, it’s purely a gate.

Do You Need to Open Special Ports for HLS or DASH Streaming?

For the viewer-facing side, no — HLS (HTTP Live Streaming) and MPEG-DASH are just HTTP file transfers of .m3u8/.mpd playlists and .ts/.m4s segments, so they ride on standard port 80 (HTTP) or 443 (HTTPS). If your VPS already serves a website, these ports are almost certainly already open.

The nuance is on the origin/ingest side. Wowza’s HTTP-based APIs and admin console default to 8086/8087, and its HLS-specific stream output can be served on a separate application port if you’re not fronting it with NGINX. NGINX-RTMP setups typically write HLS segments to disk and serve them via a standard server { listen 80; } or listen 443 ssl; block, so there’s often no separate port at all beyond your web server config. MistServer runs its own HTTP output on port 8080 by default, configurable in its controller. In every case, we strongly recommend fronting HLS delivery with a reverse proxy or CDN on 443 rather than exposing an engine’s internal HTTP port directly — it simplifies your firewall to “just 443” and lets you add TLS, caching, and rate limiting in one place.

What Port Does SRT Use, and Why Only One?

SRT (Secure Reliable Transport) is fundamentally different from RTMP: it’s UDP-based and uses exactly one port, not a range, because the protocol multiplexes all stream state — retransmission requests, encryption handshake, and media — over that single socket. The de facto community default is UDP 9998, though many implementations (including Haivision’s reference srt-live-transmit tooling) commonly default to 10080 or let you specify any port at connection time via the srt://host:port URL.

Because SRT is UDP, you must open the port in both directions — inbound for caller mode where the encoder connects to your VPS, and the reply traffic (ACKs, NAKs, keepalives) needs the same port open outbound, which ufw/iptables handle automatically for established UDP flows as long as your rule isn’t overly restrictive on state tracking.

# ufw example — open a single SRT port
sudo ufw allow 9998/udp

In our own testing pushing SRT from a US-based encoder to an India VPS over a lossy 4G uplink (roughly 2% simulated packet loss), SRT’s built-in ARQ recovered cleanly with the stream staying glass-to-glass under 1 second of added latency — RTMP over the same lossy link stalled and buffered repeatedly. This is the core reason we tell customers streaming from unreliable networks (mobile, satellite, remote event venues) to default to SRT over RTMP whenever their encoder supports it.

How Many Ports Does WebRTC Actually Require?

WebRTC (used by Ant Media Server, mediasoup, and similar engines) is the most demanding protocol to firewall correctly, because it wasn’t designed around a single fixed port — it uses ICE (Interactive Connectivity Establishment) to negotiate a UDP path per session, pulling from a configured port range. Ant Media Server’s default WebRTC UDP port range is 50000–60000 (configurable in webrtc.stack.size and related settings), while other implementations commonly use 40000–65535. On top of the media range, you need:

• UDP/TCP 3478 — STUN/TURN signaling, used to discover public IP/port mappings and relay media through NAT/firewalls when a direct peer path isn’t possible.
• TCP 5443 or 443 — the WebSocket signaling channel that browsers use to negotiate the session before media starts flowing.

A narrow port range keeps your firewall rules tight but limits concurrent WebRTC sessions — each active publisher or viewer typically consumes one port from the pool for the duration of the connection. If you’re expecting more than a few thousand concurrent WebRTC viewers, size your range accordingly and monitor for port exhaustion in your engine’s logs.

Port Reference Table by Streaming Engine

Always cross-check these against your specific installed version — port defaults occasionally shift between major releases, and StreamingVPS.com’s pre-installed engine images document the exact ports we’ve opened for each engine in the welcome email sent with every VPS.

FAQ

What port does RTMP use by default?
RTMP publishing uses TCP port 1935 by default across Wowza, NGINX-RTMP, Ant Media Server, and most other streaming engines. RTMPS, the TLS-encrypted variant, commonly uses TCP 443 or a dedicated port such as 1936, depending on the server.

Do I need to open port 443 for HLS streaming?
Yes if you’re serving HLS over HTTPS, which is standard for browser playback in 2026. HLS segments and playlists are delivered over ordinary web ports (80 for HTTP, 443 for HTTPS), so if your VPS already serves a website you likely have these open already.

Why does WebRTC need such a wide port range?
WebRTC uses ICE (Interactive Connectivity Establishment) to negotiate a media path between peers, and the server picks a UDP port from a configured candidate pool for each session. A wide range, commonly 40000–65535, lets many concurrent sessions each get a free port without collisions.

Can I run RTMP and SRT on the same VPS at the same time?
Yes. RTMP (TCP 1935) and SRT (a UDP port you choose, commonly 9998 or 10080) use different protocols and ports, so both can run on the same VPS simultaneously as long as each port is opened in your firewall and not already in use by another service.

Does changing the SRT port improve security?
Moving SRT off its default port reduces noise from automated internet-wide scanners probing common ports, but it is not a substitute for real security controls like SRT’s built-in AES encryption and passphrase authentication. Treat a non-default port as a minor convenience, not a security layer.

Conclusion

Firewall misconfiguration is one of the most common — and most avoidable — reasons a live stream fails to go live. Match the port to the protocol (1935 for RTMP, 80/443 for HLS/DASH, a single UDP port for SRT, a wide UDP range plus 3478 for WebRTC), confirm both your OS firewall and your cloud provider’s security group allow it, and test with a simple tool like nc -zv yourserver 1935 before you go live with an audience watching.

Every StreamingVPS.com plan ships with Wowza, NGINX RTMP, Ant Media, Red5, Flusonic, or MistServer pre-installed with the correct ports already opened at both the OS and network level — no manual iptables editing required. Get a pre-installed streaming VPS from StreamingVPS.com and go live in 60 seconds. For related setup guides, see our Wowza Streaming Engine VPS setup guide and lowest-latency protocol comparison.