For a basic SRS relay that sends a stream to YouTube, expose only the configured ingest service to the systems that publish to it, and allow the SRS host to make the required outbound RTMPS connection. Keep API, playback and WebRTC services private unless your channel actually uses them.
SRS’s documented ports describe services it can provide, not a checklist to open to the internet. Your firewall rules should follow the SRS version and configuration you run, plus the path your encoder, relay and viewers actually use.
Map the SRS services you actually use
Start with the data flow, not with a port list. A common arrangement has an encoder or another source sending an RTMP feed to SRS, then SRS forwarding that feed to YouTube. In that arrangement, the inbound publishing listener and the outbound YouTube connection are separate firewall decisions. A viewer who watches on YouTube does not need access to an SRS playback port.
SRS documentation identifies TCP 1935 for RTMP, TCP 1985 for its HTTP API and WebRTC-related services, TCP 8080 for HTTP streaming such as HTTP-FLV or HLS, and UDP 8000 as a default WebRTC media port. It also describes optional services and ports, including HTTPS, converters and signaling. These are service references, not a public allowlist. Check the resource and configuration documentation for the version you have installed before relying on any example: SRS resource and port documentation.
Write down the path before changing rules. For example:
| Connection | Direction at the SRS host | Consider opening when | Default posture for a basic relay |
|---|---|---|---|
| RTMP publisher to SRS | Inbound TCP | RTMP publishing is enabled and an encoder sends to SRS | Permit only the configured listener, preferably from known publisher networks |
| SRS to YouTube | Outbound TCP | SRS forwards a live feed to the YouTube endpoint in Live Control Room | Permit the supplied RTMPS route under your egress policy |
| Client to SRS API | Inbound TCP | A trusted management or application workflow needs the API | Keep private or restrict to the intended trusted network |
| Viewer to SRS playback | Inbound TCP | Viewers consume HTTP-FLV or HLS from SRS itself | Do not expose for YouTube-only viewing |
| WebRTC media peer to SRS | Inbound UDP or configured alternative | The channel actually uses WebRTC media | Design from the active WebRTC configuration |
The table is an orientation aid, not a substitute for inspecting the running configuration. A distribution, container, reverse proxy or local configuration may change listeners and binding addresses. An example port in a guide is not proof that your running process uses it.
Also distinguish a host firewall from a cloud network firewall. A VM may have a rule at the provider edge and another on the operating system. Both need to agree with the intended path. A useful checklist for the source side is the OBS and YouTube Live setup guide, which helps clarify what the publishing application is expected to send; it does not mean every stream needs the same network layout.
Protect the YouTube stream key
A narrow firewall does not make a leaked stream key harmless. YouTube describes stream keys as like a stream’s password and address: they direct the encoder and let YouTube accept the incoming feed. Treat the key as a credential, even if the firewall limits who can connect to SRS.
Retrieve the RTMPS URL and key from the channel’s Live Control Room, then enter them only into the relay configuration or encoder field intended for them. Do not put a real key in a public example, source repository, screenshot, support ticket, or command transcript that may be retained. If you must share a diagnostic capture, redact the key and any URL component that contains credentials.
If a key is exposed, use YouTube’s current reset process rather than assuming a network rule has contained it. YouTube Help explains how to manage live stream settings and reset a compromised key. A reset may require the appropriate channel permissions, so confirm that the person handling the incident has access before a scheduled broadcast depends on the new credential.
The separate network connections matter here. RTMPS encrypts the SRS-to-YouTube feed in transit; it does not protect a key copied into an untrusted place, secure an exposed SRS API by itself, or encrypt an unrelated publishing leg that uses plain RTMP. YouTube recommends RTMPS for live encoding in its encoder settings guidance. Choose encryption and credential handling for each leg of the route, rather than assuming one secure connection covers the whole system.
Allow only intended ingest publishers
For an RTMP-only ingest design, TCP 1935 is the usual inbound listener to consider if RTMP publishing is enabled in your SRS configuration. If your encoder has a stable public address, a private address, or a VPN route, limit the source rule to that route where the network permits. If publishers come from changing addresses, decide deliberately how they should reach the service instead of opening the listener to every source by habit.
Source restrictions are least-privilege guidance based on the service inventory, not a promise about a particular SRS default. Verify the listener address, protocol and port that the running configuration actually uses. If you have configured an alternate listener or RTMPS at the SRS edge, allow that listener instead of opening the illustrative RTMP port as well.
A firewall source restriction can reduce unsolicited access, but it is not a replacement for sensible publishing credentials, host maintenance, or a trusted management route. Keep server administration on a separate path such as a restricted private network or VPN. Do not use a public streaming listener as a convenient route to administer the machine.
If the source drops, diagnose the path in order: can the encoder reach the listener, does SRS accept and process the publish, and can SRS reach YouTube? That separation makes a firewall change easier to reverse if it blocks the wrong leg. For symptoms on the onward delivery leg, the guide to diagnosing YouTube ingest warnings on an Indian cloud VPS provides a useful operational distinction between a source-to-relay problem and a YouTube ingest warning.
Keep unused API and playback services private
TCP 1985 and TCP 8080 appear in SRS’s service documentation, but a basic YouTube relay does not thereby need to accept public connections to either. The API has a different purpose from publishing, and an HTTP playback listener serves clients that consume media from SRS. If your audience watches the YouTube channel, YouTube is the viewer endpoint; exposing an SRS playback port adds a path you may not need.
Leave unused listeners closed at both the cloud network layer and host firewall where applicable. If an operational tool needs an API, allow only the trusted system or private network that uses it, and apply the deployment’s authentication and HTTPS or proxy controls. Do not assume that moving a port to a different number is access control.
If viewers genuinely need HLS or HTTP-FLV directly from SRS, that is a separate service decision. Identify the configured HTTP or HTTPS listener, decide which viewers should reach it, and place it behind the TLS and access-control design appropriate to your deployment. SRS documentation lists HTTP streaming and optional HTTPS services, but your active configuration determines what is listening. A direct SRS viewer endpoint also creates a different availability and bandwidth question from a YouTube-only stream.
Keep configuration examples and logs in mind when checking exposure. An API URL or playback address can disclose hostnames, paths, or operational details even if it does not contain a key. The same careful separation is useful when you organise a long-running channel: for example, a 24/7 recorded-video stream setup has its own source and monitoring decisions, but does not make SRS’s unused API or playback functions necessary.
Permit outbound RTMPS to YouTube
The relay needs outbound reachability from SRS to the RTMPS URL displayed by YouTube Live Control Room. Retrieve the current URL there, rather than copying a hostname from an old example or treating an example in a troubleshooting page as your permanent destination. The outbound rule should match the endpoint and port in use, subject to your organisation’s egress controls.
YouTube’s help guidance says to verify that the connection uses rtmps when troubleshooting TLS issues and gives port 443 as an option to try when necessary. That is guidance for the YouTube-facing connection, not a direction to open inbound TCP 443 on the SRS host. The connection direction is easy to confuse: the server initiates outbound delivery to YouTube; publishers separately connect inbound to SRS.
If your egress firewall permits only named destinations, confirm how it handles the current YouTube endpoint and any endpoint changes before the channel goes live. Avoid turning a temporary test into a broad permanent egress exception. Record the service, destination and reason for the rule so the next person can tell it apart from an inbound listener rule.
YouTube’s recommendation of RTMPS addresses transport encryption for that delivery leg. It does not mean every source-to-SRS connection is encrypted, and it does not configure TLS for an API or web playback endpoint. If you choose RTMPS between a publisher and SRS as well, that uses the SRS listener you configured and must be considered separately from outbound RTMPS to YouTube.
Treat WebRTC as a separate firewall design
Do not carry an RTMP-only firewall plan over unchanged if the application also uses WebRTC. SRS separates signaling from media. Its documentation identifies TCP 1985 for related services and UDP 8000 as a default media port, while also describing TCP transport as an option where UDP is unavailable. Actual signaling, candidate and media settings determine the reachable path.
The practical implication is that opening TCP 1935 does not make WebRTC work. Nor should UDP 8000 be made public simply because it appears as a documented default. First confirm that WebRTC is enabled, which signaling route is in use, which media transport has been selected, and which address the peer is expected to reach. Then write rules for those configured paths and restrict source ranges where the topology allows.
If a proxy, NAT gateway or cloud network sits in the route, check that the candidate address advertised to peers is reachable from their network. A service can appear to be listening locally while peers cannot reach its advertised media address. Test from the real client network, not only from the SRS host itself.
For a channel that only ingests via RTMP and forwards to YouTube, the simpler answer is usually to leave WebRTC services disabled or unreachable if they are not needed. That keeps the firewall plan aligned with the actual stream path instead of expanding it to cover hypothetical future uses.
Test rules against the running configuration
After applying a change, validate the intended end-to-end path rather than treating a successful firewall reload as proof that the stream works. Check the configured listeners on the SRS host and compare them with the policy at the host and cloud layers. Confirm that an intended publisher can connect and that an unintended source cannot reach listeners that should be private, using authorised tests.
Then start a short controlled publish and observe each leg: encoder to SRS, SRS processing and forwarding, and SRS to the YouTube endpoint. Confirm the broadcast appears in YouTube Live Control Room and watch for the relevant ingest status. A connection test to a port alone does not prove that a stream key, protocol, media format or onward route is correct.
Also test the negative cases that matter. From a network that should not have access, verify that the API and playback listener are not publicly reachable if they are meant to remain private. If you intentionally provide playback, test it from the intended viewer network and confirm that the TLS or proxy path behaves as designed. A rule that is too narrow can interrupt publishing; one that is too broad can expose a service unrelated to the channel.
Keep a small change record: the SRS version, relevant listener settings, rule direction, source or destination scope, and the test performed. Revisit it when you upgrade SRS, enable a new feature, change an encoder location, or move between cloud network policies. Version and configuration changes can alter the service map, so a copied rule set can become stale even if it once matched the deployment.
For a simple RTMP ingest and YouTube egress, the operational goal is not to open every port SRS documents. It is to prove that the one configured publishing path and the required outbound delivery path work, while unrelated listeners remain inaccessible. If maintaining a source machine and its overnight forwarding process is itself the difficult part, StreamNeo can remove that specific operational burden by taking an uploaded video and running it as a YouTube live stream while your computer is off.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Which ports should I open for SRS to stream to YouTube?
There is no universal list. For a basic RTMP ingest path, consider the configured inbound RTMP listener, commonly TCP 1935, and permit the SRS host’s outbound route to the RTMPS endpoint shown in YouTube Live Control Room. Keep API, playback and WebRTC paths closed unless your configuration and use case need them.
Is TCP 443 an inbound SRS port for YouTube streaming?
Not by virtue of YouTube’s RTMPS guidance. YouTube’s troubleshooting help mentions trying port 443 for the outbound connection to its supplied endpoint; that is different from an inbound listener on SRS. Use the endpoint and port currently shown for your channel and the listener you have configured on SRS.
Does a firewall protect a leaked YouTube stream key?
No. Network restrictions may limit who can reach your relay, but they do not invalidate a credential that has been exposed. Treat the key as a password, avoid including it in shared material, and follow YouTube’s reset process if it is compromised.
Do I need UDP 8000 for an RTMP stream?
Not for an RTMP-only path simply because SRS documents UDP 8000 as a WebRTC media default. If WebRTC is enabled, inspect the active signaling, transport and candidate settings, then design the firewall rules around those actual paths rather than assuming the RTMP rules are sufficient.