When an encoder runs on an Oracle Cloud Infrastructure (OCI) instance, it sends the live feed out to YouTube. Start with the instance’s outbound route and egress controls for the URL and protocol shown in YouTube Studio; an inbound RTMP rule is not needed for that push.
Prefer YouTube’s RTMPS endpoint when your encoder supports it. If an SSL error persists, YouTube advises trying port 443. OCI security lists, network security groups, routes and the guest operating system’s firewall are separate parts of the path, so check each one that applies rather than opening ports by guesswork.
How YouTube encoder traffic flows
A YouTube encoder connection is initiated from the machine running the encoder to the ingestion endpoint assigned or displayed for your stream. The encoder sends video and audio to YouTube; it is not waiting for YouTube to initiate an RTMP connection back to the OCI instance. That direction is the key distinction when you are deciding which firewall rules matter.
If OBS runs on your home computer, OCI is not on the video path merely because you also have an OCI instance. A change to the cloud instance’s firewall will not repair the home computer’s outbound connection. If OBS, FFmpeg or another encoder runs on Compute, identify that instance’s VNIC and subnet, then follow its path towards the internet.
The path may include a public or private subnet, an internet or NAT gateway, a proxy, and OCI packet rules. The exact route depends on how the VCN was designed. After traffic leaves OCI, the encoder also needs working DNS, a reachable YouTube endpoint, a valid stream URL and key, and adequate upload capacity. A permissive ingress rule cannot fix a failure in any of those steps.
This distinction also helps separate streaming from administration. SSH access to an instance is inbound traffic initiated by your computer; YouTube ingest is outbound traffic initiated by the encoder. If you cannot connect to SSH, investigate its ingress path separately. Do not treat a YouTube streaming problem as a reason to expose an administrative port to the internet.
For a prerecorded channel, it is worth testing the whole broadcast workflow as well as network access. A stream that connects but repeats or switches content poorly has a different problem from a blocked connection; the guide to rotating a YouTube livestream playlist without repeating its opening video covers that programming issue.
Choose the YouTube ingest URL and port
In YouTube Studio, open Live Control Room and select or create the stream you intend to use. Copy the server URL and stream key shown in the stream settings into the encoder’s matching fields. The URL is not necessarily a hostname you should guess from an old configuration: use the value YouTube supplies for the current workflow.
YouTube recommends RTMPS, its encrypted version of RTMP. Some encoder presets expose a YouTube RTMPS option; otherwise, retrieve the RTMPS server URL in the stream settings, including through the lock icon where available. Check the encoder’s own protocol and URL fields together. An RTMP URL paired with an assumption that the connection is encrypted can lead you to investigate the wrong thing.
Port choice follows the actual URL and YouTube’s guidance, not a universal list of firewall ports. YouTube’s troubleshooting advice for a persistent SSL error is to try port 443. Do not infer that every endpoint supports every port, or that a generic RTMPS port should replace the URL YouTube gave you. If the URL includes a port, preserve it unless YouTube or the encoder’s relevant instructions say otherwise.
Treat the stream key as a password. It identifies the stream destination as well as authorising the encoder to send to it, so do not place it in a public script, screenshot or support post. If it has been exposed, reset it in Live Control Room and update the encoder. YouTube’s guide to setting up a live stream with an encoder explains the Studio workflow; its encoder settings guidance covers supported settings and connection setup.
Check OCI security lists and network security groups
OCI has two packet-level rule controls that commonly appear in this investigation. A security list is associated with a subnet and applies to VNICs in that subnet. A network security group (NSG) is associated with selected VNICs, letting you group resources by application role rather than by subnet. Oracle recommends NSGs for that separation, and a VNIC can belong to more than one NSG, so inspect the controls actually attached to the instance.
Start by recording the instance’s subnet and VNIC in the OCI Console. Inspect the subnet’s associated security lists, then inspect every NSG associated with that VNIC. A rule on some other subnet or on an NSG that is not attached to the VNIC will not solve the problem. Security lists and NSGs can both apply, so account for all relevant layers rather than assuming one replaces the other.
For a YouTube push stream, look at egress rules for the chosen destination and protocol. Compare the configured rule with the actual endpoint and port from the encoder, using the narrowest policy your design supports. Do not add a broad rule just because a tutorial uses it: destinations and network designs vary, and YouTube does not supply one static hostname-and-port prescription that fits every setup.
OCI’s default security list includes broad stateful egress and stateful SSH ingress, but a custom list or later policy change may differ. Stateful rules allow return traffic for a connection initiated under that rule; they do not mean you should create an unsolicited inbound listener for YouTube. Check the current configuration rather than relying on what a default once contained. Oracle’s security rules documentation explains how security lists and NSGs attach and how their rules work.
Keep administrative access distinct. If you need SSH, scope its allowed source to authorised addresses where practical; do not open SSH or RDP to all sources as a convenience. RDP is not included in the default security list’s ingress rules described in the research notes, and a custom policy may have its own requirements. Streaming egress and remote administration should be reviewed as separate flows.
Verify subnet routes and internet access
A permissive egress rule is only one condition. The subnet also needs a route and egress path that can reach the internet or the configured proxy. Depending on the design, that path may use an internet gateway, a NAT gateway or another approved arrangement. Do not copy a route-table recipe without first identifying whether the instance is public or private and what gateway the VCN actually uses.
In the OCI Console, trace from the instance to its subnet, then inspect the subnet’s route table and the relevant gateway or next hop. Confirm that the route applies to this subnet and that the destination it covers is appropriate for the intended path. If the instance relies on a proxy, check the proxy configuration and its own network permissions too. Route changes affect more than the encoder, so follow the network owner’s change process where one exists.
Then check DNS resolution from the instance and whether the operating system can make outbound connections under the intended policy. A correct route does not guarantee that DNS works; a correct DNS answer does not prove that a TCP or TLS connection succeeds. Gather these as separate observations. If you run the encoder locally instead, perform those checks on the local computer and its network, not on OCI.
Oracle also treats the guest operating system’s firewall as distinct from VCN controls. Its guidance says to align OS firewall policy with NSG and security-list rules. A packet permitted by the VCN may still be blocked inside the instance, and an open guest firewall cannot override a VCN denial. Use the commands and policy tool for the image and operating system you actually run; Oracle Linux examples do not automatically apply to Ubuntu or another distribution.
Allow outbound traffic for the encoder
Once the URL, protocol and port are known, compare them with the egress policy at each applicable layer: security list, NSG, route and host firewall. A stateful egress rule generally permits return traffic for the connection it allows, so the response path is not normally a reason to add an inbound RTMP rule. If your organisation uses a stateless policy or a filtering proxy, follow its documented return-traffic requirements instead of assuming stateful behaviour.
Prefer a specific, reviewable rule over a catch-all where your security model permits it. The destination should correspond to the endpoint actually used, and the protocol and port should match the encoder’s connection. YouTube endpoints can vary by workflow, so avoid hard-coding an imagined universal destination. If your network policy cannot use a stable destination restriction, ask the network administrator how outbound streaming is handled rather than silently broadening access.
Check whether the guest firewall has an outbound policy, not just inbound rules. Some installations allow outbound connections by default; others are hardened. The change should permit the encoder’s real connection and not introduce an inbound service that the channel does not run. Oracle’s example of opening a port with firewall-cmd demonstrates host firewall management, but its example port is for a different application, not a YouTube setting. Do not copy that port for streaming.
YouTube’s published encoder settings also matter after the socket connects. It supports several codecs and frame rates, and its bitrate guidance varies by resolution, frame rate and codec. Use its current settings page for the chosen format rather than treating a bitrate as a firewall requirement. A small devotional audio loop and a detailed moving news scene can need different encoding choices even at the same resolution.
| YouTube-published H.264 example | Minimum bitrate | Recommended bitrate |
|---|---|---|
| 720p at 30 fps | 3 Mbps | 8 Mbps |
| 1080p at 30 fps | 5 Mbps | 14 Mbps |
| 1080p at 60 fps | 6 Mbps | 17 Mbps |
YouTube also lists different figures for other codecs; for example, its page gives 1080p at 30 fps using AV1 or H.265 a minimum of 4 Mbps and a recommendation of 10 Mbps. These are encoder settings published by YouTube, not measured speeds or guarantees for your connection. YouTube recommends a speed test and choosing quality that is reliable on available upload capacity. Test with representative audio and motion, use the documented keyframe cadence, and watch stream health in Live Control Room.
Test connectivity and read encoder errors
Test in stages so a failure points towards a specific layer. First confirm that the encoder runs on the machine you think it does and that its URL, protocol and key are current. Next confirm DNS and outbound path from that machine. Then check the applicable OCI rules and guest firewall, and attempt the connection while watching the encoder log and YouTube’s stream preview.
A timeout usually means the connection did not complete, but it does not name the blocking layer. Recheck the copied server URL, route, egress rules, proxy and host firewall. If the encoder is not on OCI, move the checks to its actual network. Avoid changing an inbound listener rule as a first response: it does not govern an outbound connection initiated by the encoder.
An SSL or certificate error is a reason to verify that you are using the RTMPS URL and that the encoder supports it. Check for a mismatched scheme, incorrect server field or a stale endpoint. If the SSL error persists, YouTube advises trying port 443. This is targeted troubleshooting guidance, not a statement that RTMPS works over every port.
If YouTube receives no preview or rejects the stream, check that the stream key belongs to the selected event and has not been reset. Confirm the protocol and encoder settings, then start the encoder again and look for a preview before selecting Go live where the workflow requires it. If the key was exposed, reset it rather than trying to secure a copy that may already have been seen.
If the stream connects but health is poor or it drops intermittently, compare the actual uplink capacity with the settings for your selected codec, resolution and frame rate. Watch stream health during a representative test, including the audio and motion expected overnight. A firewall can permit every required packet while a constrained upload or unsuitable encoder configuration still produces an unhealthy broadcast.
For a channel built from recorded songs, separate technical testing from content preparation. Once the stream is stable, you can refine transitions with a guide to switching songs smoothly in an always-on Indian music stream. If you are weighing a local machine against a cloud-hosted encoder, the low-power PC considerations for a 24/7 YouTube stream help frame that separate operating decision.
When inbound ports are actually needed
An inbound port is needed only when something is meant to initiate a connection to the OCI instance. Examples include an application you intentionally host, a management service such as SSH, or a contribution workflow in which another encoder sends media into your own ingest service. In that last case, the listener belongs to your architecture; it is not required simply because the final destination is YouTube.
If a local encoder sends directly to YouTube, no inbound RTMP listener on the OCI machine is involved. If an OCI encoder sends directly to YouTube, the same is true: it pushes outward. If you deliberately build a relay that accepts a feed and then forwards it, document which component listens, which source is allowed to connect, and which component makes the onward YouTube connection. Apply an inbound rule only to the actual listener and its intended sources.
A channel that serves a web dashboard or another application may require inbound access for that application, but that is a different service and port decision. Keep it separate from the stream’s outbound ingest path, and avoid opening an inbound media port “just in case”. Unneeded listeners increase exposure without making the outbound YouTube connection more reliable.
For someone whose central problem is keeping a prerecorded file on air while their own computer is switched off, using a cloud-run broadcast removes the need to maintain a local encoder session overnight. StreamNeo can take away that specific always-on computer burden; it does not change the need to supply a valid YouTube stream URL and key or to use the right connection settings.
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
Do I need to open inbound RTMP on OCI for YouTube?
No, not when an encoder on the instance pushes its stream to YouTube. Check outbound connectivity to the URL and protocol YouTube gives you. Inbound media access is relevant only if your own design deliberately accepts a feed into a service on the instance.
Which port should I use for YouTube RTMPS?
Use the server URL and port supplied for your stream, and make sure the encoder is configured for RTMPS. If an SSL error persists, YouTube troubleshooting recommends trying port 443. Do not assume that every endpoint supports every port.
I allowed egress in a security list but the encoder still times out. What next?
Check the NSGs attached to the instance’s VNIC, the subnet route and gateway, DNS, any proxy, and the guest operating system firewall. Also verify that the encoder is running on that OCI instance; if it is running locally, OCI is not in its outbound path. Read the encoder log alongside the YouTube preview to distinguish a network failure from a key or settings problem.
Does a successful connection mean my settings are suitable for a 24/7 stream?
No. A connection only shows that the encoder reached YouTube; it does not establish that bitrate, codec, audio or upload capacity will remain healthy. Test with representative content, use YouTube’s current encoder guidance for your chosen format, and monitor stream health.