A refused RTMP connection means the connection attempt was actively rejected somewhere along the route; it is not the same symptom as a timeout, a TLS error or dropped frames after streaming begins. First identify which machine is connecting to which destination, then test that connection leg before changing the stream key, bitrate or firewall rules.
A Linux VPS may publish directly to YouTube, or it may send video to an RTMP relay on the VPS that then publishes to YouTube. Those arrangements have different destinations and failure points, so the steps below are conditional on the path you actually use.
Identify the exact connection error
Read the encoder or relay log around the failure and note the destination hostname, port, time, and the most specific error text available. A phrase such as “connection refused” usually reports that a TCP connection attempt received an active rejection. It does not identify who rejected it: the destination host, an intermediate network device, or a local service could be involved. The wording alone does not prove that YouTube is unavailable, that the key is wrong, or that a provider blocks a port.
A timeout is different: the client did not receive a response within its waiting period. A TLS or certificate error means TCP may have connected, but secure negotiation or certificate verification failed. Dropped frames or intermittent disconnections generally arise after a streaming connection has been established and point towards the network path or the sustainable bitrate, rather than an initial refusal. Keep these diagnoses separate.
Find the first failed stage, not just the last line printed. Depending on the software, the sequence may include resolving a hostname, opening TCP, negotiating TLS, completing an RTMP handshake, publishing with a key, and sending media. A log that says the socket could not connect is not evidence of a rejected stream key, because the client may not have reached the stage where YouTube checks it.
If the only message is “failed to connect to server”, inspect the surrounding log and test the destination that the program actually tried. YouTube uses similar wording in guidance about encoder timeouts, and a remembered URL or a configuration error can make that message ambiguous. The YouTube Live streaming status guide is relevant if you have a separate Studio status or channel-eligibility problem, but it does not diagnose a TCP refusal.
Map the VPS-to-YouTube delivery path
Write the path down before testing. In a direct setup it is typically encoder on VPS → YouTube ingest. In a relay setup it is encoder → relay on VPS → YouTube ingest. The encoder may be OBS, FFmpeg, or another publisher; the relay may be an RTMP service such as NGINX. NGINX describes its RTMP module as supporting RTMP, HLS and DASH streaming, but that does not mean every VPS is configured as a relay.
| Actual arrangement | Connection to test first | What a refusal can indicate |
|---|---|---|
| Encoder publishes directly to YouTube | VPS encoder to the configured YouTube ingest host and port | The configured endpoint, local or provider network path, or a rejecting intermediate service; logs are needed to distinguish them |
| Encoder publishes to a relay on the same VPS | Encoder to the relay's address and listening port | The relay may not be listening on that address/port, or a local rule may reject the connection |
| Encoder publishes to a relay on another host | Encoder to the relay host and port | The relay endpoint or the route and policy between the two hosts needs checking |
| Relay publishes to YouTube | Relay to the configured YouTube ingest host and port | The relay's destination, outbound access, or TLS setup needs checking |
In a relay arrangement, a successful encoder-to-relay connection does not prove that the relay can reach YouTube. Likewise, a relay's successful outbound connection does not prove that the encoder can reach the relay. Test and record each leg independently. If you have no relay configuration and the encoder targets YouTube directly, skip relay-only checks rather than adding a service that is not part of your setup.
This distinction also matters if you use a local playback or automation process. For example, a recorded-video workflow may have an encoder on the VPS sending the media onward; the VLC-based 24/7 channel walkthrough is useful context for identifying the publishing process, but the network destination still comes from your live encoder configuration.
Verify the YouTube ingest URL and key
For a direct publisher, open YouTube Live Control Room and copy the current ingest settings for the stream. YouTube's RTMPS ingestion documentation explains the supported endpoint format and secure connection requirements. The ordinary RTMP URL may be shown by default; if you intend to use RTMPS, explicitly select and copy the RTMPS URL rather than reusing a remembered address from an older setup.
Check protocol, hostname, application path and port together. A plausible-looking hostname is not enough if the protocol is wrong, the path is incomplete, or the client is trying the wrong port. For YouTube RTMPS, the documented arrangement uses the rtmps scheme, a valid YouTube ingestion server and application path, port 443, and the destination hostname for TLS SNI. Do not substitute the default port of a self-hosted relay for YouTube's ingest port, or vice versa.
Copy the stream key from the same stream settings and keep it private. A key can be rotated or replaced, so an old saved configuration deserves verification. But do not start by changing a key when the log shows failure before the RTMP publish stage: a key is normally relevant after the network connection and protocol handshake progress far enough to submit it. If a connection succeeds but publishing is rejected, then check that the key belongs to the intended stream and that the encoder has not added spaces or altered the value.
Where a relay is used, there may be two distinct configurations: the encoder's input address for the relay, and the relay's output URL and key for YouTube. Confirm each one in the appropriate software. Do not paste YouTube's key into a relay input field just because both are labelled “key”; know which side of the relay that field controls. Treat keys in command lines, service files and logs as credentials, and redact them before sharing diagnostic output.
Check DNS, outbound access and port use
Test the exact host and port shown in the running configuration, from the machine that initiates that connection. For direct publishing, run the checks on the VPS running the encoder. For a relay's outbound leg, run them on the relay host. A test from your laptop or from a different machine does not establish that the VPS has the same DNS answer or network policy.
Start with name resolution, then test TCP reachability using an appropriate diagnostic available on your Linux distribution. A DNS lookup that fails is a different finding from a resolved hostname whose TCP connection is refused. A TCP test that times out is different again. Record the command, target, time and complete result; a bare statement that “the port is open” does not say which host was tested or what path was used. Avoid repeatedly probing unrelated addresses or changing multiple variables at once.
If the destination is a local relay, confirm the relay process is running and listening on the address and port configured by the encoder. A service listening only on a loopback address cannot necessarily be reached through the VPS's public address. Conversely, a listener bound to a public interface has exposure implications, so do not broaden its access just to make a test pass. Check the relay's own logs at the same timestamp as the encoder's attempt.
For a direct YouTube destination or the relay's outbound leg, inspect outbound policy at both relevant layers: the Linux host firewall and the VPS provider's network firewall or egress controls. Look for a rule affecting the actual destination and transport, not merely a rule with “RTMP” in its comment. Permit only the required outbound flow if a rule needs correction. The researched official guidance does not establish that any particular VPS provider blocks YouTube, so treat provider policy as something to verify, not a presumed cause.
Port use depends on the connection leg and protocol. A relay may listen on a port chosen in its own configuration, while YouTube's documented RTMPS ingest uses port 443. Do not open an inbound port on the VPS to solve a direct outbound connection to YouTube; those are different directions. If you are unsure which rule applies, preserve the current rules and ask the host or network administrator to identify the matching outbound policy from the recorded destination and time.
Check TLS settings when using RTMPS
Only follow this section if the configured connection is RTMPS. RTMPS is RTMP carried through TLS, not plain RTMP with a different label. YouTube recommends RTMPS; the YouTube encoder settings page also describes supported protocols and stream settings. A client that opens a TCP socket but never performs TLS has not completed an RTMPS connection.
Verify that the URL uses rtmps, that the hostname and port come from current Live Control Room settings, and that the TLS client sends the hostname as SNI. YouTube's protocol documentation specifies SNI for hostname authentication. This matters when an application is given an IP address directly, or when a relay has been configured with a bare address rather than the hostname: a TCP test to the IP might succeed while TLS validation or server selection still fails.
Use a TLS diagnostic against the configured hostname and port to determine whether a handshake can complete and whether certificate validation succeeds. Keep the hostname in the test so SNI is exercised. Do not disable certificate checks as a workaround; that hides a validation failure rather than establishing a correct secure connection. If the TLS diagnostic fails, keep the output and check client support, system time, hostname, port and any proxy or TLS interception in the path before changing stream settings.
If your setup uses ordinary RTMP rather than RTMPS, TLS tests do not apply to that leg. Do not infer that a plain RTMP connection is healthy or appropriate for YouTube simply because its TCP socket opens. Compare the protocol configured in the encoder with the current endpoint instructions, and test that exact configuration. Avoid switching back and forth without noting which URL and transport produced each result.
Inspect firewall and relay configuration where relevant
Check firewall rules only after identifying whether the failed leg is inbound to a relay or outbound to YouTube. A direct publisher normally needs to initiate an outbound connection; a self-hosted relay may also need an inbound listener for its encoder. These require different rule directions. Changing both at once makes it harder to learn which control affected the result and may expose a listener unnecessarily.
On the Linux host, inspect the active firewall manager and its effective rules, rather than assuming a particular tool is in use. Also check the provider's control panel or documented network controls. If a rule appears to match, note its direction, protocol, port, source or destination scope, and action. Make a narrow, reversible change only when the evidence points to that rule, then repeat the same test. Do not flush firewall rules or disable them wholesale on an Internet-facing VPS.
For a relay, inspect the configured listening address, port, application path and output destination. Confirm the process loaded the configuration you are reading; a file edit has no effect until the service is reloaded or restarted according to its documented procedure. Check that the relay's outbound URL uses the intended YouTube endpoint and that its own RTMPS/TLS support is enabled if using RTMPS. A healthy listener is only evidence about the encoder-to-relay leg, not the relay-to-YouTube leg.
If you are running FFmpeg, OBS, or a managed process under a service supervisor, make sure the log belongs to the current process and current configuration. An old process may still hold a socket or continue publishing with a stale URL. The guide to FFmpeg input read errors on a 24/7 stream concerns media input failures rather than YouTube connection refusal, but it can help you keep local input problems distinct from network-stage errors.
Retest and capture the result
Change one variable at a time. A useful sequence is: confirm the target and path, test DNS, test TCP to the exact port, test TLS if the leg is RTMPS, then attempt publishing and inspect the application log. In a relay setup, perform this sequence separately for encoder-to-relay and relay-to-YouTube. Keep the stream key redacted in saved output.
Record what changed and what moved in the failure sequence. If TCP now connects but TLS fails, the problem has advanced to a different stage; investigate the TLS result rather than continuing to alter firewall rules. If TLS and the RTMP handshake complete but publishing is refused, inspect the current stream key and application path. If media begins, use YouTube's stream health information and representative audio and motion to assess delivery. That later quality check is not evidence that an earlier refusal was caused by bitrate.
For a stream that connects but then drops frames or disconnects intermittently, treat it as a separate stability issue. OBS's stream connection troubleshooting guide describes dropped frames and intermittent disconnections in terms of the network path to the ingest service. In that case, examine network stability and sustainable bitrate, and test with representative content; YouTube's encoder guidance recommends CBR and a two-second keyframe interval, not exceeding four seconds. Those settings concern stream compatibility and health, not the first explanation for a TCP refusal.
When asking your VPS provider, relay administrator or encoder community for help, include the architecture, destination hostname and port, the exact error with timestamp, and redacted TCP/TLS results. Include the relevant firewall rule or relay log, but remove the stream key and any other credentials. A clear report lets someone distinguish a refused socket from a timeout or failed TLS negotiation without guessing at your configuration.
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” mean YouTube rejected my stream key?
Not by itself. A refused TCP connection can happen before the client reaches the stage where the key is submitted, so check the log's failure stage first. A key becomes a stronger suspect when the connection and protocol handshake succeed but the publish step is rejected.
Should I open port 1935 on my VPS?
Only if your actual relay configuration needs an inbound listener on that port, and then scope access to the intended publishers. A direct outbound connection to YouTube is a different flow, and YouTube RTMPS uses port 443 in its documented setup. Verify the target and direction before editing firewall rules.
Is RTMPS always the fix for a refused connection?
No. YouTube recommends RTMPS, but switching protocols will not fix an unrelated local listener, route, or firewall issue, and a broken TLS configuration can create a different error. Copy the current endpoint and test the protocol and connection leg your encoder actually uses.