A “connection refused” error from an Oracle Cloud Ubuntu VPS does not identify one cause. Check the YouTube destination and protocol first, then work outward through internet routing, OCI egress rules, the Ubuntu firewall, and encoder settings.
This order helps you distinguish a wrong endpoint or stream key from a network filter or an encoder problem. Do not assume an inbound port needs opening: the VPS is initiating an outbound connection to YouTube, and the right fix depends on what the tests show.
Confirm the exact error and destination
Start with the encoder’s full error text and the time it occurred. “Connection refused”, a timeout, and an SSL or certificate error point you towards different checks, but none is enough on its own to prove which layer is responsible. Save the relevant log lines and redact the stream key before sharing them. A key in a screenshot, support ticket, shell history, or public issue should be treated as exposed.
Next, compare the encoder’s configured destination with the settings for the specific live stream in YouTube Studio’s Live Control Room. Copy the current server URL and the key associated with that stream. A saved profile may still contain an old URL, an endpoint for another stream, or a value entered with a typo. Do not paste a key into a connectivity command or publish it while asking for help.
A useful first pass is to note three separate facts: what hostname and port the encoder is attempting to reach, whether the message is a TCP, TLS, or authentication error, and whether the VPS can resolve and contact that hostname independently. Keep those facts separate. A successful network test does not verify the key, and an authentication error is not evidence that OCI blocked a connection.
If this is part of a longer-running channel, keep the stream settings and recovery notes somewhere you can access without relying on the VPS console. The practical guide to running a prerecorded YouTube stream is useful context for planning the stream workflow, but for this fault the URL shown for your live stream is authoritative.
Use the current YouTube ingest URL and protocol
YouTube supports RTMP and RTMPS ingest, and recommends RTMPS. RTMPS carries RTMP over TLS, so it requires both an endpoint that uses the secure protocol and an encoder that supports it. YouTube notes that the ordinary RTMP URL may be displayed by default; reveal and copy the RTMPS URL in the stream settings if that is the protocol you intend to use. See YouTube’s RTMPS instructions.
Do not substitute a remembered generic hostname or assume that a URL from an older guide applies to the stream now. Use the server URL displayed for the relevant stream. Then inspect the encoder profile to confirm the selected protocol matches it. A mismatch can appear as a connection or SSL problem before the encoder ever gets to send a usable stream.
For certain SSL errors, YouTube advises checking that the RTMPS URL is being used and trying port 443. That is a targeted diagnostic, not a universal port rule. Follow the exact endpoint and port presented in Live Control Room, and compare it with the encoder’s configuration and the network policy. A timeout may also warrant checking URL correctness and RTMPS support; it does not automatically mean a firewall is blocking traffic.
| What you are checking | RTMP | RTMPS |
|---|---|---|
| Endpoint | Copy the current URL shown for the stream | Reveal and copy the RTMPS URL shown for the stream |
| Transport | RTMP | RTMP carried over TLS |
| Encoder requirement | RTMP support | RTMPS support |
| Diagnostic point | Verify the configured host and port | Verify the secure URL; for certain SSL errors, YouTube suggests trying port 443 |
The table is a comparison of protocol checks, not a recommendation to force a port or endpoint. If a change does not match the URL supplied by YouTube, undo it and re-check the stream settings rather than accumulating guesses.
Verify the VPS has an outbound internet route
Before changing firewall rules, establish whether the VM can reach the public internet at all. Check that the VPS has a route appropriate to its subnet and network design. In OCI, a route table and internet gateway configuration may be part of the path; a VM can have a public address and still lack a working route or have traffic filtered elsewhere.
Test DNS resolution for the exact hostname copied from YouTube, rather than a different public website. If DNS lookup fails, the problem may be name resolution or a broader network configuration issue, and a TCP test by hostname will not tell you whether the YouTube service itself is reachable. If the name resolves, record the returned result and continue to a TCP test against the matching port.
Keep the scope narrow. A successful request to an unrelated website tells you the VM has some internet access, but does not show that traffic to the YouTube ingest host and port is allowed. Conversely, a failure against the ingest host should be read alongside the route, DNS result, and OCI and Ubuntu policies, not treated as proof of one blocked rule.
If the VPS serves a looping video, distinguish this network fault from media preparation problems. The FFmpeg encoding guide for continuous YouTube streaming can help you check the file and encoder workflow separately. Encoding quality and bitrate do not explain whether a TCP connection to the ingest endpoint can be established.
Review OCI security lists, NSGs and routing
OCI applies network controls at the VNIC and subnet levels. Security lists are associated with a subnet; network security groups (NSGs) apply to selected VNICs. Both are relevant when the VM initiates an outbound connection, so inspect the actual configuration rather than relying on a remembered default. Oracle describes these controls in its security list documentation and security rules documentation.
Find the VM’s VNIC and subnet, then identify every security list associated with that subnet and every NSG attached to the VNIC. Check the route table as well. For this outbound test, examine egress rules for the protocol and destination port in the current YouTube URL. A policy that allows traffic in a different direction or on a different port does not establish that this connection is permitted.
OCI’s default security list includes a stateful allow-all egress rule, but that fact is not a diagnosis for your VM. A custom security list, an attached NSG, route configuration, network firewall, or guest firewall can change what happens. Verify what is attached and effective in your tenancy. If your organisation manages the VCN, ask the network administrator to confirm the egress path and rules before changing shared controls.
Do not broaden inbound access as a first response. The encoder’s attempt to reach YouTube is outbound from the VPS, so opening an arbitrary inbound RTMP port does not address that direction. If you change an egress rule, make the smallest change that matches the required destination and port, keep a note of the prior state, and re-test. Avoid adding a broad allow rule simply because “connection refused” appears in a log.
The scope distinction is similar to choosing where a channel’s compute workload runs: a cloud VM has network controls that differ from a home PC or a cloud relay. The VPS versus spare PC comparison may help clarify the operational model, but it cannot establish the rules on your OCI VCN.
Check the Ubuntu host firewall
OCI rules are not the only filter. The Ubuntu guest can have its own firewall policy, and deployments vary: some use UFW, some use raw iptables or nftables rules, and some have no active host firewall. Inspect which manager is in use and its effective output policy before making changes. Do not assume that seeing a UFW command available means UFW is enabled, or that one tool shows every rule applied by another.
For an outbound stream, focus on whether the host allows the process to establish the relevant outbound connection. If a policy restricts outbound traffic, compare its rules with the exact protocol and port for the endpoint. Also look for rules added by provisioning scripts or other management tools; a locally permissive-looking rule may not be the complete effective policy.
Make one change at a time and keep your remote access in mind. A firewall change can cut off SSH access as well as alter streaming traffic. If you are not sure which rules are active, capture the current configuration and ask the person who maintains the VM before flushing a ruleset or disabling the firewall. A temporary test should not become an undocumented permanent security change.
Oracle’s guidance treats the operating-system firewall as an additional layer alongside VCN rules. That means a successful OCI egress review does not clear the guest firewall, and a host firewall change does not fix a missing route or a restrictive NSG. Work through each layer independently and re-test after a controlled change.
Test the endpoint from the VPS
Run a DNS lookup and a TCP connection test from the VPS using the hostname and port in the current YouTube URL. Use a tool available on the system, such as a DNS query utility and a TCP client or connectivity-testing utility. The exact command depends on what is installed. Do not include the stream key in a command: these tests need only the hostname and port.
Record the full endpoint (without credentials), port, time, DNS result, and test output. A connection that succeeds shows that the host could establish TCP connectivity to that destination at that moment. It does not prove that the encoder is configured to use the same URL, that TLS negotiation will succeed, or that YouTube will accept the stream key. A refused result and a timeout are observations to investigate, not a diagnosis of the exact rule or component that caused them.
Interpret the result with the other evidence:
- If the hostname does not resolve, check DNS settings and the exact copied hostname before altering OCI rules.
- If it resolves but TCP fails, compare the route, OCI egress policy, host firewall, destination, and port. Preserve the exact test output for whoever administers the network.
- If TCP succeeds but the encoder reports an SSL error, revisit the RTMPS URL, protocol support, and port guidance from YouTube.
- If the encoder reaches the service but the stream does not appear, check the matching stream key and selected stream in Live Control Room.
Tests can behave differently depending on the machine, tool, and endpoint, so do not treat a single message as proof that YouTube rejected the connection. YouTube’s RTMPS help page offers protocol-specific guidance; it does not inspect your route table, OCI rules, or Ubuntu firewall. Those need to be checked in the VPS environment.
Verify encoder support and stream-key configuration
Once the endpoint is reachable, check the encoder configuration separately. Confirm it supports the chosen protocol and that the selected profile uses the same URL and port you tested. YouTube lists RTMP and RTMPS among its encoder protocols; its RTMPS guidance says to check that the encoder supports RTMPS when connection trouble continues. An older encoder build or a profile saved for RTMP may not behave as expected when pointed at RTMPS.
Then select the stream key associated with the live stream in Live Control Room. The key is not interchangeable with the server URL, and a key from another stream can lead to a failure even when the network path is healthy. YouTube describes stream keys as the stream’s password and address; keep yours private. If it may have been exposed, reset it in Live Control Room and update the encoder. See YouTube’s guidance on live stream settings.
If a test succeeds but the encoder cannot start, update the encoder if appropriate and inspect its logs for a TLS, authentication, or configuration error. Change one setting at a time, then retry and note what changed. If the encoder appears healthy but cannot send data, confirm that the VPS itself has outbound internet access and that the tested endpoint is precisely the one configured in the encoder.
For a channel that depends on a file looping continuously, the local encoder and the always-on broadcast have different failure points. When the recurring issue is that a computer must stay on to keep the stream running, StreamNeo removes that particular burden by taking an uploaded video and running the YouTube broadcast while your computer is switched off; it does not diagnose or change the OCI VPS in this article’s scenario.
A practical order for the next test
Use a short checklist to avoid changing several layers at once:
- Copy the current URL and matching key from the selected stream in Live Control Room, keeping the key private.
- Confirm whether the encoder should use RTMP or RTMPS and whether it supports that protocol.
- From the VPS, check DNS and TCP connectivity to the exact hostname and port.
- If the test fails, review the subnet route, all attached security lists, VNIC NSGs, and the Ubuntu host firewall.
- Change only a rule or setting supported by the evidence, then repeat the same test and preserve the result.
- If TCP works but streaming fails, focus on TLS, encoder profile, and the correct stream key rather than opening unrelated ports.
This sequence is deliberately diagnostic rather than a promise that a particular edit will restore the stream. A refusal can come from the endpoint or path, and a stream can still fail after TCP works because the protocol, TLS handshake, encoder, or credentials are wrong. If your OCI network has a central firewall or is managed by an organisation, involve its administrator with the endpoint, port, timestamp, and redacted test output.
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
Does “connection refused” prove OCI blocked YouTube?
No. It is not enough to identify a specific cause. Verify the endpoint and port, then compare the VPS test with routing, OCI egress rules, host firewall policy, and encoder logs.
Should I open an inbound RTMP port on the VPS?
Not as a fix for an encoder that is initiating an outbound connection to YouTube. Check outbound routing and egress policy for the exact current endpoint and port instead; do not add an unrelated inbound rule.
Should I switch to RTMPS on port 443?
YouTube recommends RTMPS and suggests trying port 443 for certain SSL errors, but use the URL shown for your stream and confirm encoder support. Port 443 is a diagnostic suggestion for those cases, not a universal replacement for the endpoint or port shown in Live Control Room.
What if the TCP test works but the live stream does not appear?
A TCP test does not verify the encoder’s TLS handling or stream credentials. Check the selected protocol and URL, then make sure the key belongs to that stream; reset it if it may have been exposed.