RTMP (Real-Time Messaging Protocol) uses TCP port 1935 by default for clear-text streaming ingest, while RTMPS uses port 443 for encrypted streams and RTMPT uses port 80 for HTTP-tunneled traffic. VideoSDK supports RTMP output from its Interactive Live Streaming rooms, letting you broadcast to YouTube, Twitch, and other platforms over these standard ports. Understanding which port to use, how to configure firewalls, and when to switch to RTMPS is critical for reliable live streaming deployments.
Live streaming hinges on a fragile chain of network connections, and the port your RTMP stream travels through is often the weakest link. A misconfigured port can mean the difference between a flawless broadcast and a black screen for thousands of viewers. Whether you are pushing a stream to YouTube Live, Twitch, Amazon IVS, or your own NGINX-rtmp server, the port you select determines whether firewalls block you, whether your content is encrypted in transit, and whether your ingest latency stays predictable.
By the end of this guide, you will understand every RTMP port variant, how to configure firewalls and NAT for reliable ingest, when to use RTMPS on port 443, and how to troubleshoot the most common port-related failures.
What Is RTMP and Why Does It Use a Specific Port?
RTMP is defined as a TCP-based protocol originally developed by Macromedia (later Adobe) for transmitting audio, video, and data between a streaming server and a client. It works by maintaining a persistent TCP connection between an encoder and a media server, multiplexing audio and video chunks into a single stream over that connection.
Every network protocol operates on a specific port, which is a logical endpoint that tells the operating system which application should receive incoming data. The "port rtmp" concept refers to the specific TCP port that your streaming server listens on for incoming RTMP ingest connections. Without the correct port open and reachable, your encoder cannot deliver media to the server, and your viewers see nothing.
RTMP was assigned port 1935 by the Internet Assigned Numbers Authority (IANA) as its default listening port. This assignment means that when an encoder connects to an RTMP URL, it implicitly targets port 1935 unless a different port is specified in the URL. VideoSDK's Interactive Live Streaming feature can push RTMP output to external platforms, and understanding port behavior is essential when configuring those broadcast destinations.
Default RTMP Ports and Their Variants
RTMP has evolved into several variants, each using a different port to address specific network constraints. Understanding which variant uses which port is the foundation of any streaming deployment.
TCP Port 1935: The Standard RTMP Port
Port 1935 is the original and most widely supported RTMP port. When you see an RTMP URL without an explicit port number, the encoder defaults to 1935. This port carries clear-text RTMP traffic, meaning the stream content is not encrypted. Most streaming platforms, including YouTube Live and Twitch, accept ingest on port 1935 as their primary entry point. According to Adobe's original RTMP specification, port 1935 was chosen to avoid conflicts with well-known services while remaining memorable for streaming operators.
RTMPS on Port 443: Encrypted RTMP
RTMPS wraps the standard RTMP protocol inside a TLS connection, encrypting the stream between encoder and server. By convention, RTMPS uses port 443, the same port used for HTTPS traffic. This choice is deliberate: port 443 is almost always open on corporate and public networks because web traffic depends on it. By using 443, RTMPS can traverse firewalls that would block port 1935 outright.
RTMPT on Port 80: HTTP Tunneling
RTMPT encapsulates RTMP inside HTTP requests, allowing the stream to pass through HTTP proxies and firewalls that only permit web traffic. It uses port 80, the standard HTTP port. While this variant solves firewall problems, it introduces overhead from HTTP encapsulation, which can add latency and reduce throughput. RTMPT is rarely used in modern production setups but remains relevant in highly restrictive network environments.
UDP-Based Variants for Contrast
RTMFP (Real-Time Media Flow Protocol) uses UDP instead of TCP, enabling lower-latency peer-to-peer streaming. SRT (Secure Reliable Transport) also operates over UDP and has gained significant traction as an alternative to RTMP for contribution workflows. These protocols do not use port 1935 and have different firewall and NAT requirements, which we cover later in the alternatives section.
Firewall and NAT Considerations for Port RTMP
Firewalls are the most common cause of RTMP ingest failures. Port 1935 is not a well-known port like 80 or 443, which means many corporate, campus, and public Wi-Fi networks block it by default. If your encoder reports a connection timeout or refused connection, the firewall is the first suspect.
Inbound vs Outbound Firewall Rules
For a streaming server receiving ingest, the firewall must allow inbound TCP traffic on the RTMP port (typically 1935 or 443). For an encoder pushing a stream, the firewall must allow outbound TCP traffic to the server's IP on the same port. Most consumer firewalls allow all outbound traffic, but corporate environments often restrict outbound connections to a whitelist of ports, typically 80 and 443 only.
NAT Traversal and Port Forwarding
If your streaming server sits behind a NAT router, you must configure port forwarding to direct incoming RTMP traffic from the router's public IP to the server's private IP. For port 1935, this means creating a forwarding rule that maps external TCP 1935 to the internal server's TCP 1935. If you are using RTMPS on 443, ensure no other service on the server (such as a web server) is already bound to 443, or use a reverse proxy to multiplex both HTTPS and RTMPS on the same port.
Security Implications of Opening Ports
Every port you open expands your attack surface. Port 1935 clear-text RTMP is vulnerable to interception and replay attacks. Port 443 with RTMPS is significantly safer but still exposes a service to the public internet. Always combine port access with authentication mechanisms such as stream keys, IP whitelisting, and token-based validation to prevent unauthorized ingest.
Securing RTMP: When and How to Use RTMPS
Encrypting your RTMP stream protects your content from interception, prevents tampering, and satisfies compliance requirements in regulated industries like healthcare and finance. RTMPS is the standard way to achieve this, and port 443 is the preferred port for deployment.
Benefits of RTMPS Encryption
RTMPS establishes a TLS tunnel before any RTMP data flows. This tunnel encrypts the entire stream, including the handshake, stream key, and media payload. Without encryption, an attacker on the same network segment can capture your stream key and hijack your broadcast endpoint. With RTMPS, the stream key and media content are both protected.
Port Selection Strategy for RTMPS
Port 443 is the optimal choice for RTMPS for two reasons. First, it is universally recognized as a secure traffic port, so firewalls rarely block it. Second, it signals to network operators that the traffic is encrypted, reducing the likelihood of aggressive inspection or throttling. Avoid running RTMPS on non-standard ports like 8443 or 1935 with TLS, as these can trigger firewall blocks and confuse monitoring tools.
Configuring TLS on Popular Servers
For NGINX with the RTMP module, you configure TLS by enabling SSL on the RTMP listener and providing your certificate and private key paths. The server then accepts RTMPS connections on port 443 while optionally continuing to serve plain RTMP on 1935 for internal or trusted encoders.
For Wowza Streaming Engine, you enable SSL in the admin console by uploading your certificate and binding it to the streaming port. Wowza handles the TLS handshake and RTMP negotiation within the same connection.
For Amazon IVS, the ingest endpoint is provided as a URL that already uses RTMPS on port 443. You do not manage certificates yourself; AWS handles TLS termination at the ingest edge.
Configuring Popular Streaming Servers for the Correct Port
Each streaming server platform handles port configuration differently. Here is how the most common servers manage RTMP port assignments.
NGINX-rtmp Module
The NGINX-rtmp module lets you specify which port the RTMP listener binds to. By default, it listens on port 1935. To enable RTMPS, you add a second listener on port 443 with SSL enabled, providing the paths to your TLS certificate and key files. You can run both listeners simultaneously, allowing unencrypted ingest from trusted internal encoders on 1935 while requiring encryption for external contributors on 443.
One common mistake is attempting to bind NGINX-rtmp to port 443 when NGINX's HTTP block is already listening on 443. Since the RTMP module operates within NGINX, you need to ensure that the RTMP and HTTP blocks do not conflict. Some deployments solve this by using a separate IP address for the RTMP listener or by using a stream proxy to route traffic.
Wowza Streaming Engine
Wowza manages ports through its admin console under the server configuration. You can add or modify port bindings for RTMP, RTMPS, and other protocols. Wowza supports multiple simultaneous port bindings, so you can accept plain RTMP on 1935 and RTMPS on 443 at the same time. The admin console also lets you configure SSL certificates for RTMPS directly, without needing to edit configuration files manually.
Amazon IVS and Cloudflare Stream
Managed streaming services like Amazon IVS and Cloudflare Stream abstract port configuration entirely. They provide an ingest URL that already includes the correct port (typically 443 for RTMPS). You simply point your encoder at the provided URL with your stream key, and the service handles TLS, load balancing, and distribution. This approach eliminates port management overhead but locks you into their specific ingest endpoint format.
VideoSDK's Interactive Live Streaming capability similarly provides RTMP output endpoints, allowing you to push streams from VideoSDK rooms to external platforms like YouTube and Twitch without managing ingest ports yourself.
Testing Port Accessibility
Before going live, verify that your chosen port is reachable from your encoder's network. You can use network diagnostic tools to attempt a TCP connection to the server's IP address on the target port. If the connection succeeds, the port is open and the service is listening. If it times out, a firewall is blocking the traffic. If it is refused, the port is reachable but no service is listening on it. Test from the same network your encoder will use, not from a different location, to get accurate results.
Common Port-Related Issues and How to Troubleshoot Them
Even with careful configuration, port-related issues can surface during live streams. Here are the most frequent problems and how to diagnose them.
Connection Refused on Port 1935
A "connection refused" error means the TCP handshake reached the server but no application is listening on that port. Check that your streaming server process is running and that it is configured to listen on 1935. If the server is behind a load balancer or Docker container, verify that the port mapping exposes 1935 to the host network.
Connection Timeout on Port 1935
A timeout means the TCP SYN packet never reached the server or the response never came back. This is almost always a firewall issue. Check inbound firewall rules on the server, outbound rules on the encoder's network, and any cloud security groups (AWS Security Groups, GCP Firewall Rules) that might be filtering traffic. If port 1935 is blocked, switching to RTMPS on port 443 is the fastest workaround.
Latency Spikes on Port 80 vs Port 1935
RTMPT on port 80 adds HTTP encapsulation overhead, which increases latency and can cause buffering on high-bitrate streams. If you are experiencing latency on port 80, switch to direct RTMP on 1935 (if the firewall allows) or RTMPS on 443. Port 80 should be a last resort for firewall traversal, not a primary ingest port.
Certificate Mismatches on RTMPS
When using RTMPS, the TLS certificate must match the hostname in the RTMP URL. If your certificate is for streaming.example.com but your encoder connects to the server's IP address directly, the TLS handshake fails with a certificate validation error. Always use the hostname that matches your certificate, and ensure your certificate authority is trusted by your encoder software.
Systematic Troubleshooting Checklist
Start by confirming the server is listening on the correct port. Then verify the firewall allows traffic on that port from the encoder's network. Next, test connectivity from the encoder's network using a diagnostic tool. Finally, check the server logs for connection attempts and error messages. This four-step process isolates the problem in the majority of cases.
Best Practices for Production-Ready RTMP Port Management
Production streaming deployments require more than just opening a port and hoping it works. Here are the practices that separate reliable streams from fragile ones.
Keep Port 1935 Closed to the Public
If you do not need external encoders connecting over clear-text RTMP, keep port 1935 closed to the public internet. Use RTMPS on port 443 for all external ingest. Reserve port 1935 for internal, trusted encoders on a private network or behind a VPN. This reduces your attack surface and prevents unauthorized stream injection.
Implement IP Whitelisting and Token Authentication
Port access alone is not sufficient security. Combine open ports with IP whitelisting so only known encoder IPs can connect. Add token-based authentication or stream key validation so that even if an attacker discovers your port, they cannot publish without credentials. VideoSDK's REST API supports token-based authentication for room and stream management, providing an additional layer of access control.
Monitor Port Health and Bandwidth
Use network monitoring tools to track bandwidth usage, connection counts, and error rates on your RTMP ports. Sudden drops in bandwidth can indicate encoder disconnection. Spikes in connection attempts can signal a denial-of-service attack. Set up alerts for anomalous patterns so you can respond before viewers notice.
Document Port Configurations
Maintain a document recording which ports are open, which services listen on them, which firewall rules apply, and which certificates are bound to RTMPS. This documentation is invaluable during disaster recovery, team handoffs, and security audits. Update it every time you change a port configuration.
Alternatives to RTMP Port Ingestion
RTMP is not the only option for live stream ingest. Depending on your latency requirements, network conditions, and security needs, alternative protocols may serve you better.
SRT (Secure Reliable Transport)
SRT operates over UDP and is designed for high-latency, lossy networks. It supports encryption natively and handles packet loss more gracefully than TCP-based RTMP. SRT uses a configurable port (commonly 10080 or a custom port) and requires UDP firewall rules rather than TCP. According to the SRT Alliance, SRT adoption has grown significantly among broadcast contributors who need reliable transport over unpredictable networks.
HLS (HTTP Live Streaming)
HLS uses standard HTTP on port 80 or 443, making it the most firewall-friendly option. However, HLS is not designed for real-time ingest; it introduces significant latency (typically 2 to 30 seconds depending on segment duration). HLS is better suited for distribution to viewers than for encoder-to-server contribution.
RTSP (Real-Time Streaming Protocol)
RTSP is used primarily for IP camera streams and surveillance systems. It typically uses port 554 for control traffic and RTP over UDP or TCP for media delivery. RTSP is not commonly used for live streaming to platforms like YouTube or Twitch but remains relevant for security camera and IoT applications.
Quick Decision Matrix
| Protocol | Default Port | Transport | Latency | Encryption | Best For |
|---|---|---|---|---|---|
| RTMP | 1935 | TCP | Low (1-5s) | No | Standard ingest to streaming platforms |
| RTMPS | 443 | TCP | Low (1-5s) | Yes (TLS) | Secure ingest through restrictive firewalls |
| RTMPT | 80 | TCP | Medium (3-8s) | No | Firewall traversal when 1935 and 443 are blocked |
| SRT | Configurable (e.g., 10080) | UDP | Low (0.5-2s) | Yes (AES) | Unreliable networks, long-distance contribution |
| HLS | 80 / 443 | TCP (HTTP) | High (2-30s) | Yes (HTTPS) | Viewer distribution, not ingest |
[LINKABLE ASSET: comparison table]
VideoSDK's Interactive Live Streaming mode offers sub-second latency for interactive scenarios, which is significantly lower than any RTMP-based pipeline. When your use case requires audience interaction rather than one-way broadcast, ILS provides a compelling alternative to traditional RTMP workflows.
Definitions Glossary
RTMP (Real-Time Messaging Protocol): A TCP-based protocol for streaming audio, video, and data between an encoder and a media server, originally developed by Macromedia and later maintained by Adobe. It uses port 1935 by default for clear-text ingest.
RTMPS: The secure variant of RTMP that wraps the protocol inside a TLS connection, typically using port 443. It encrypts the stream key, handshake, and media payload.
RTMPT: RTMP tunneled over HTTP, using port 80 to traverse firewalls that only permit web traffic. It adds overhead and latency compared to direct RTMP.
Port 1935: The IANA-assigned default TCP port for RTMP traffic. It is not a well-known port, meaning many corporate and public firewalls block it by default.
SRT (Secure Reliable Transport): A UDP-based streaming protocol that supports encryption and handles packet loss more effectively than TCP-based protocols. It is increasingly used as an alternative to RTMP for contribution workflows.
Interactive Live Streaming (ILS): VideoSDK's low-latency streaming mode where viewers can be promoted to active speakers in real time, built on the same SDK surface as video calling with sub-second latency.
Key Takeaways
- RTMP uses TCP port 1935 by default, RTMPS uses port 443 for encrypted ingest, and RTMPT uses port 80 for HTTP-tunneled traffic through restrictive firewalls.
- Port 1935 is frequently blocked by corporate and public networks, making RTMPS on port 443 the recommended choice for external encoder ingest.
- Firewall configuration, NAT port forwarding, and TLS certificate management are the three most common failure points in RTMP port deployments.
- For production systems, keep port 1935 closed to the public, enforce IP whitelisting and token authentication, and monitor port health continuously.
- VideoSDK's Interactive Live Streaming supports RTMP output to external platforms while offering sub-second latency for interactive audience scenarios that traditional RTMP pipelines cannot match.
Conclusion
Understanding the port RTMP uses is not just a networking detail. It is the difference between a stream that reaches your audience reliably and one that fails silently behind a firewall. Port 1935 remains the standard for clear-text ingest, but port 443 with RTMPS is the production-ready choice for any deployment that values security and firewall compatibility. For scenarios where you need real-time audience interaction rather than one-way broadcast, VideoSDK's Interactive Live Streaming offers sub-second latency that RTMP was never designed to achieve.
Test your ingest endpoint today, verify your port accessibility, and document your configuration. If you are building a live streaming application and want to explore how VideoSDK can handle your RTMP output and interactive streaming needs, sign up at app.videosdk.live/login and check out the code samples to get started. What are you building with VideoSDK? Drop a comment below, I would love to hear what kind of streaming use case you are working on.
FAQ