Port RTMP refers to the network ports used by the Real-Time Messaging Protocol for live video ingest, with TCP port 1935 as the default, port 443 for encrypted RTMPS, and port 80 for HTTP-tunneled RTMPT. VideoSDK supports RTMP output for simultaneous broadcast to YouTube, Twitch, and other platforms, making port configuration critical for reliable streaming. Understanding which port to use, how to configure firewalls, and when to switch to alternatives like SRT or WebRTC ensures your live streams stay connected and secure.
A single blocked port can turn a polished live stream into a black screen with no warning. If you have ever watched a broadcast fail seconds before going live, the culprit is often the RTMP port configuration on the sending end, the receiving server, or a firewall sitting between them.
RTMP remains the dominant ingest protocol for live streaming in 2026, despite being over two decades old. Its port assignments, security variants, and firewall behavior determine whether your stream reaches the audience or dies in transit. Developers building streaming infrastructure need to understand not just the default port number, but the full landscape of RTMP port variants, encryption options, and alternatives.
This guide covers every port RTMP uses, how to configure firewalls and NAT for reliable ingest, the security trade-offs between clear-text and encrypted variants, and how to troubleshoot the most common port-related failures. By the end, you will have a complete mental model of RTMP port behavior and a clear plan for production deployments.

What Is RTMP and Why Does It Use Specific Ports?

RTMP is a TCP-based protocol originally developed by Macromedia (later Adobe) for streaming audio, video, and data between a server and a Flash player. While Flash is long gone, RTMP survives as the de facto ingest standard because it is simple, widely supported, and works reliably over TCP connections. Every major streaming platform, from YouTube Live to Twitch, accepts RTMP ingest on well-known ports.
Ports are logical endpoints in the TCP and UDP networking stack, numbered from 0 to 65535. When an RTMP client connects to a streaming server, it opens a TCP connection to a specific port on the server's IP address. The server listens on that port, accepts the connection, and begins receiving the video stream. The port number is not arbitrary. It must be agreed upon by both sides, and it must be open on every firewall, router, and NAT device in the path.
The Internet Assigned Numbers Authority (IANA) assigned port 1935 as the official default for RTMP. This assignment means that when a streaming server or client refers to RTMP without specifying a port, 1935 is implied. However, real-world deployments frequently use alternative ports for security, firewall traversal, or compatibility reasons. VideoSDK's Interactive Live Streaming supports RTMP output, which means understanding these port assignments matters when you are broadcasting from a VideoSDK room to external platforms.

Default RTMP Port Variants

RTMP has three primary port assignments, each serving a different use case. Choosing the right variant depends on your security requirements, firewall constraints, and the platform you are streaming to.

TCP Port 1935 – Standard Clear-Text RTMP

Port 1935 is the IANA-assigned default for RTMP and the most widely supported port across streaming platforms. When you configure an encoder to send a stream to a YouTube, Twitch, or custom RTMP endpoint without specifying a port, the connection targets port 1935 by default.
This port carries clear-text RTMP, meaning the video data is not encrypted in transit. For most ingest scenarios where the stream travels over a trusted network or a short hop to a CDN edge server, this is acceptable. The latency overhead is minimal because there is no TLS handshake or encryption processing. However, clear-text RTMP is vulnerable to interception on untrusted networks, and some corporate firewalls block port 1935 because it is a non-standard port that does not carry HTTP traffic.
Most streaming platforms, including YouTube Live, Twitch, and custom Wowza or nginx-RTMP servers, accept ingest on port 1935. If you are building a VideoSDK application with RTMP output, the destination URL typically uses this port.

TCP Port 443 – Encrypted RTMPS

Port 443 is the standard HTTPS port, and RTMPS (RTMP Secure) uses it to carry RTMP traffic wrapped in a TLS or SSL connection. RTMPS encrypts the entire stream payload, protecting video data from interception on untrusted networks. Because port 443 is the standard encrypted web traffic port, nearly every firewall allows outbound connections to it, making RTMPS the most firewall-friendly RTMP variant.
The trade-off is performance. The TLS handshake adds a small amount of connection setup time, and ongoing encryption and decryption introduce CPU overhead on both the sender and receiver. For most modern hardware, this overhead is negligible, but on low-powered embedded encoders or high-concurrency ingest servers, it can add a few milliseconds of latency per connection.
YouTube Live and Facebook Live both support RTMPS ingest on port 443, and many platforms are moving toward requiring it. If your stream travels over public internet paths or you need to comply with data protection regulations, RTMPS on port 443 is the right choice. VideoSDK's RTMP output supports secure endpoints, so you can target RTMPS URLs when broadcasting from a VideoSDK room.

TCP Port 80 – RTMPT (HTTP-Tunneled RTMP)

Port 80 is the standard HTTP port, and RTMPT wraps RTMP packets inside HTTP requests to traverse firewalls that block non-standard ports. This variant was critical in the Flash era when corporate firewalls routinely blocked port 1935. RTMPT encapsulates the RTMP stream in HTTP POST requests, making it look like ordinary web traffic to firewalls.
In 2026, RTMPT is largely a legacy fallback. The HTTP tunneling adds overhead, increases latency, and can cause buffering issues because HTTP is not designed for sustained bidirectional streaming. Most modern platforms have deprecated or removed RTMPT support. However, if you are streaming from a restrictive corporate network where only ports 80 and 443 are open, RTMPT on port 80 can still save a broadcast. In practice, RTMPS on port 443 is almost always a better choice because it combines firewall friendliness with encryption.

Configuring Firewalls and NAT for Port RTMP

Firewall and NAT configuration is where most RTMP port problems originate. The stream must traverse every network device between the encoder and the ingest server, and each device must allow the relevant port.
For outbound streaming from an encoder to a remote ingest server, the sending firewall must allow outbound TCP connections to the destination port (1935, 443, or 80). Most default firewall configurations allow all outbound traffic, but restrictive corporate or cloud environments may block non-standard ports like 1935. If outbound port 1935 is blocked, switching to RTMPS on port 443 usually resolves the issue because firewalls almost never block outbound HTTPS.
For inbound ingest, where you operate the receiving server, the server's firewall must allow inbound TCP connections on the RTMP port. On cloud platforms like AWS, Google Cloud, or Azure, this means configuring security group rules to allow inbound TCP traffic on port 1935 from your encoder's IP address range. For broader access, you can open the port to any source, but this increases exposure to unauthorized connection attempts.
Port forwarding on routers becomes relevant when the ingest server sits behind a NAT device, such as a home or office router. You must forward the external port (1935) to the internal IP address and port of the ingest server. Double NAT, where both the router and the ISP modem perform NAT, is a common pitfall that breaks port forwarding. In these cases, the port forward on the router works, but the ISP modem blocks the inbound connection before it reaches the router.
The diagram below shows the path an RTMP stream takes from an encoder through firewall and NAT layers to the ingest server:
Architecture Diagram
Common pitfalls include ISPs that block inbound port 1935 entirely, cloud security groups that default to denying all inbound traffic, and home routers where UPnP opens a different port than expected. Always test the port path end-to-end before going live.

RTMPS vs RTMP: Security and Performance Trade-offs

The choice between clear-text RTMP on port 1935 and encrypted RTMPS on port 443 involves a trade-off between performance and security that every streaming developer must understand.
Clear-text RTMP on port 1935 offers the lowest connection latency and the least CPU overhead. There is no TLS handshake, no certificate validation, and no ongoing encryption processing. For a local ingest server on a trusted network, or for a short hop to a CDN edge that you control, clear-text RTMP is perfectly adequate. The stream reaches the server with minimal delay, and the server can process it immediately.
RTMPS on port 443 adds a TLS layer that encrypts the stream payload end-to-end between the encoder and the ingest server. The TLS handshake adds roughly 50 to 100 milliseconds of connection setup time on the initial connect, which is negligible for a long-running live stream. Ongoing encryption overhead on modern hardware is typically under one millisecond per packet, making it effectively invisible in real-world latency measurements.
The real advantage of RTMPS is firewall compatibility. Port 443 is the HTTPS port, and virtually every network allows outbound connections to it. If you are streaming from a hotel network, a corporate office, or a mobile hotspot that blocks port 1935, RTMPS on 443 will connect where standard RTMP fails. This alone makes RTMPS the preferred choice for production deployments where the network conditions are unpredictable.
Major platforms have converged on RTMPS. YouTube Live recommends RTMPS, Facebook Live requires it, and Twitch supports both. VideoSDK's RTMP output works with both standard and secure endpoints, so you can target whichever protocol your destination platform prefers.
The one scenario where clear-text RTMP wins is when you control the entire network path and need every millisecond of latency reduction. Competitive gaming streams on a dedicated network, or internal corporate broadcasts on a LAN, benefit from the slight overhead reduction of port 1935.

Alternatives to Port RTMP for Ingest

RTMP is not the only ingest option, and in some scenarios, alternatives offer better latency, reliability, or firewall traversal. The streaming ecosystem in 2026 includes several protocols that compete with or complement RTMP.
SRT (Secure Reliable Transport) uses UDP instead of TCP, which means it does not rely on a specific port assignment in the same way. SRT can run on any port the server configures, and its UDP-based design handles packet loss and network jitter better than TCP-based RTMP. SRT is gaining traction for contribution feeds where network conditions are unpredictable, such as remote production and satellite links. However, SRT requires both ends to support it, and many consumer-facing platforms still only accept RTMP ingest.
WHIP (WebRTC-HTTP Ingestion Protocol) is an emerging standard that uses WebRTC for ingest, offering sub-second latency and native browser support. WHIP runs over HTTPS on port 443, making it firewall-friendly. VideoSDK's Interactive Live Streaming is built on WebRTC and offers sub-second latency, making it a strong alternative to RTMP for interactive scenarios where audience engagement matters.
HLS (HTTP Live Streaming) is primarily a distribution protocol, not an ingest protocol, but some platforms accept HLS ingest. HLS runs over HTTP on port 80 or HTTPS on port 443, making it extremely firewall-friendly. However, HLS ingest introduces significant latency, typically 10 to 30 seconds, making it unsuitable for interactive streaming.
The diagram below compares these protocols across key dimensions:
Architecture Diagram
For most developers, the decision comes down to this: use RTMP or RTMPS for maximum platform compatibility, use SRT for unreliable networks, and use WebRTC-based solutions like VideoSDK ILS when you need real-time audience interaction.

Troubleshooting Common Port RTMP Issues

When an RTMP stream fails to connect, the symptoms are usually obvious: the encoder shows a connection timeout, the player shows a black screen, or the stream appears live but drops repeatedly. The root cause is almost always a port-related issue.
The most common symptom is a connection timeout on the initial handshake. This means the encoder cannot reach the ingest server on the specified port. The first diagnostic step is to verify that the port is open end-to-end. You can test TCP connectivity to the server's IP address and port using network diagnostic tools like telnet or a port checker. If the connection is refused, the server is not listening on that port. If the connection times out, a firewall is blocking the traffic.
Another frequent issue is an incorrect port in the RTMP URL. Developers sometimes append the port number incorrectly or forget to specify it when using a non-default port. The RTMP URL format includes the port after the host, and omitting it defaults to 1935. If the server listens on a custom port, the URL must include it explicitly.
TLS certificate mismatches cause RTMPS failures on port 443. If the ingest server's TLS certificate does not match the hostname in the RTMP URL, the TLS handshake fails and the connection drops. This often happens when developers use an IP address instead of a domain name, or when the certificate is self-signed and the encoder rejects it. Always use a valid certificate from a recognized CA for RTMPS ingest.
ISP-level port filtering is a subtler problem. Some ISPs block inbound connections on non-standard ports like 1935 to prevent customers from running servers. If your ingest server is on a residential connection and remote encoders cannot connect, ISP filtering is a likely cause. Switching to RTMPS on port 443, which ISPs rarely block, usually resolves this.
For VideoSDK users, if RTMP output from a VideoSDK room to an external platform fails, verify the destination RTMP URL and port, confirm the destination platform is accepting ingest, and check the VideoSDK streaming documentation for the correct output configuration.

Best Practices for Reliable Port RTMP Deployments

Production streaming demands more than a working connection on localhost. The following practices ensure your RTMP port configuration survives real-world network conditions.
Use RTMPS on port 443 as your default production ingest protocol. The encryption overhead is negligible on modern hardware, and the firewall compatibility is dramatically better than port 1935. Keep clear-text RTMP on port 1935 as a fallback for scenarios where you control the network and need minimal overhead.
Keep your encoder firmware, streaming server software, and TLS libraries updated. Security vulnerabilities in older RTMP server implementations can expose your ingest endpoint to attacks, and outdated TLS libraries may fail to negotiate modern cipher suites with newer encoders.
Monitor latency and packet loss on your ingest connection. If you see latency spikes or dropped frames, investigate the network path between the encoder and the server. Tools that measure TCP retransmission rates and round-trip time can reveal congestion or firewall issues before they cause visible stream degradation.

Definitions Glossary

RTMP (Real-Time Messaging Protocol): A TCP-based protocol for streaming audio, video, and data between a client and server, originally developed by Macromedia and now the dominant ingest standard for live streaming platforms.
Port 1935: The IANA-assigned default TCP port for clear-text RTMP traffic, used by most streaming platforms for standard ingest connections.
RTMPS (RTMP Secure): RTMP traffic encrypted with TLS or SSL, typically transmitted over TCP port 443, providing both encryption and firewall compatibility for secure live streaming.
RTMPT (RTMP Tunneled): RTMP traffic encapsulated in HTTP requests, transmitted over TCP port 80, used as a legacy fallback for traversing firewalls that block non-standard ports.
SRT (Secure Reliable Transport): A UDP-based transport protocol for video streaming that handles packet loss and network jitter more effectively than TCP-based RTMP, using configurable ports rather than a fixed assignment.
WHIP (WebRTC-HTTP Ingestion Protocol): An emerging standard for WebRTC-based ingest over HTTPS on port 443, offering sub-second latency and native browser support as an alternative to RTMP.

Key Takeaways

  • Port 1935 is the IANA-assigned default for clear-text RTMP, but port 443 (RTMPS) is the better production choice due to encryption and universal firewall compatibility.
  • RTMPS on port 443 adds negligible latency overhead on modern hardware while protecting stream data and traversing restrictive firewalls that block port 1935.
  • Firewall and NAT configuration must allow the RTMP port end-to-end, including cloud security groups, router port forwarding, and ISP-level filtering.
  • Alternatives like SRT and WebRTC-based WHIP offer advantages for unreliable networks and sub-second latency scenarios, but RTMP remains the most widely compatible ingest protocol.
  • VideoSDK's Interactive Live Streaming supports RTMP output for simultaneous broadcast to YouTube, Twitch, and other platforms, making port configuration a key part of any multi-platform streaming workflow.

Conclusion

Port RTMP configuration is the foundation of reliable live streaming. Whether you use the default port 1935 for clear-text ingest, RTMPS on port 443 for encrypted and firewall-friendly streaming, or port 80 as a legacy fallback, the right choice depends on your security needs, network conditions, and target platform. For production deployments, RTMPS on port 443 is the safest default, with clear-text RTMP reserved for trusted networks where latency matters most.
If you are building a streaming application with VideoSDK, explore the Interactive Live Streaming documentation to configure RTMP output from your VideoSDK rooms. You can also check the VideoSDK quickstart to get a room running in minutes, and join the VideoSDK Discord community to connect with other developers building real-time streaming applications. Sign up at app.videosdk.live/login to start building with free credits.
What are you building with RTMP streaming? Drop a comment below, I would love to hear what kind of live streaming use case you are working on.

Free $20 Balance for AI Voice Agents & Video Calls

Sign up here

FAQ