“Connecting” is a symptom, not a diagnosis. To narrow it down, check the active YouTube stream URL and key, the RTMPS destination and port, Hetzner’s outbound firewall rules, and the FFmpeg build before treating it as a video-quality problem.
Without your command and logs, no one can identify the cause or promise a successful connection. Work through the checks below in order, changing one thing at a time and recording what YouTube and FFmpeg report.
What “connecting” does and does not tell you
A stream can appear to be connecting because the encoder has not established a network session, because YouTube has not yet recognised the incoming session, or because the broadcast is connected but has not supplied media YouTube can process. Those states need different checks. The label alone does not tell you which one applies.
Start by locating the exact point of failure. In the FFmpeg output, look for whether it reports opening the output, attempting a connection, completing a TLS handshake, or writing media. Save the complete stderr output, with the stream key and any private credentials removed. A timeout while opening the output points you first towards destination, DNS, routing or egress policy. Errors after media begins to flow call for a different investigation.
Then check Live Control Room. Is YouTube receiving a signal? Does the selected broadcast show an incoming stream, a preview, or an encoder error? YouTube’s live-stream troubleshooting guidance treats encoder connection errors and stream-health problems as matters to inspect through the encoder and the live control room. Use its current instructions rather than inferring a diagnosis from the word “connecting”.
A connection timeout is not the same as dropped frames, a black preview or poor stream health. If no data reaches YouTube, bitrate and keyframe adjustments are unlikely to repair a blocked or misdirected connection. If data does reach YouTube, then media settings and encoder output become relevant. You can use the distinction in encoder-side and viewer-side buffering checks, but first establish whether this is a transport problem at all.
Copy the endpoint for the active YouTube stream
Open YouTube Live Control Room and select the broadcast you intend to run. Copy the stream URL and the stream key shown for that stream, then compare them with the values used by your FFmpeg command or configuration. A saved command can quietly contain an endpoint or key from an earlier broadcast, a different channel, or a test stream.
Do not take a URL from an old shell history entry, a forum example or another encoder’s setup screen as authoritative. The selected stream in Live Control Room is the source of the destination and key for that broadcast. YouTube’s instructions for starting a stream with encoder software describe obtaining the key in Live Control Room and updating the third-party encoder when needed.
Keep the key private. In a command it may be embedded in the output URL, so redact it before sharing a command, terminal capture or log. Redact it from shell history extracts too. You can still provide useful troubleshooting material by preserving the URL scheme, hostname, port, FFmpeg options and error text while replacing the secret with a placeholder such as [REDACTED].
If startup began failing after you changed or replaced a key, update the command with the currently displayed value and test once. Avoid rotating the key repeatedly while also changing the endpoint and firewall: that makes it harder to tell which change mattered. If the destination is wrong, firewall work will not correct it; if the credentials are wrong, opening another port will not correct them.
For a longer-running prerecorded broadcast, the same endpoint discipline applies whether you use one file or a playlist. The practical setup considerations in streaming a prerecorded playlist from a Linux VPS in India are useful context, but the stream-specific URL and key still need to come from the selected YouTube broadcast.
Verify protocol, hostname and port
Read the destination as three separate things: protocol, hostname and port. For YouTube RTMPS, keep the rtmps scheme, preserve the hostname provided by YouTube, and use port 443 where an explicit port is required. Do not assume that changing rtmps to rtmp, omitting the hostname, or borrowing a hostname from a sample command is harmless.
This matters because RTMPS is RTMP carried over TLS. Google’s RTMPS ingestion documentation specifies port 443 and explains the role of the server hostname in TLS authentication through SNI. If your FFmpeg command needs an explicit port, use the documented port while retaining the exact active hostname. An IP address substituted for that hostname can interfere with hostname-based TLS verification or server selection.
YouTube recommends RTMPS for YouTube Live in its encoder settings guidance. That recommendation is a useful starting point, not proof that every setup is configured for it. Verify what your command actually passes to FFmpeg, especially if the URL is built from separate variables or generated by a script.
| Destination choice | What to check | Practical trade-off |
|---|---|---|
| RTMPS | Active YouTube hostname, rtmps scheme, TLS port 443 |
Encrypted transport; the hostname must remain available for TLS/SNI. |
| RTMP | Exact active endpoint and the port specified for that endpoint | Different transport choice; do not change to it just to bypass an unexplained RTMPS failure. |
| HLS ingestion | YouTube’s current HLS requirements and encoder support | Segment delivery can suit certain format needs, but it is not a generic repair for a failed RTMPS connection and has higher latency. |
The table is not a list of interchangeable destinations. Follow the endpoint and protocol that YouTube presents for the selected ingestion method. YouTube documents HLS for particular codec or HDR needs when the encoder supports it; because it sends segments rather than a continuous RTMP-style stream, latency is higher. If you do not have a requirement that calls for HLS, changing protocols adds another variable instead of clarifying the connection failure.
Inspect Hetzner Cloud Firewall outbound rules
Check whether a Hetzner Cloud Firewall is attached to the instance that runs FFmpeg, then inspect its outbound rules. Do not look only at inbound rules: an inbound allowance does not itself permit the VM to open an outbound session to YouTube.
Hetzner documents an important default distinction in its Cloud Firewall FAQ. If no custom firewall rules are configured, outbound new connections are allowed by default. When custom rules exist, outbound new connections are dropped unless an appropriate rule permits them; established and related traffic is handled separately. That means the mere presence of a firewall does not prove it is blocking the stream, and a custom rule set can behave differently from the default.
Inspect the rules attached to the correct server, not just a firewall you remember creating. If the endpoint is RTMPS on port 443, confirm that outbound traffic needed for that destination and port is allowed by the effective rules. Keep the change narrow and consistent with your security policy. There is no universal firewall change that fits every server, and an inbound port rule is not a substitute for the necessary outbound permission.
If you adjust a rule, record the old state and the new state, then retry the same command against the same active broadcast. Do not simultaneously alter the URL, key, protocol and media settings. If nothing changes, revert an unnecessary rule change and proceed to the next branch. The useful evidence is the attached firewall’s actual outbound policy and the timestamped result of a controlled retry, not an assumption that every cloud firewall blocks streaming.
Confirm the FFmpeg build and protocol support
The word “FFmpeg” does not identify one identical binary. Builds can differ in enabled libraries and protocols, and a system can have more than one executable installed. First establish which binary your service or shell invokes, then capture its version and build configuration. Compare that evidence with the command that actually starts the stream.
FFmpeg’s protocol documentation describes the available protocol families and their URL forms. It cannot tell you what a particular installed binary was compiled to support. Check the build’s configuration and protocol listing, and make sure the output path uses a supported workflow for the selected YouTube destination. Also check that the output is mapped and muxed as intended; a valid input file alone does not guarantee a valid publishing command.
Review the output URL construction carefully. Shell quoting, variable expansion and special characters in a key can change what FFmpeg receives. Do not paste the unredacted URL into a public issue. Preserve the command structure when sharing it, substituting a placeholder for the key, so someone can see the scheme, hostname, port and relevant output options without receiving the credential.
A complete, sanitised stderr log matters more than a paraphrase such as “FFmpeg hangs”. Include the point at which the process stops and whether it prints a DNS, connection, TLS, authentication, muxer or write error. Include the FFmpeg version/build configuration as well. Without these, it is not possible to distinguish unsupported protocol support from a malformed command or a network failure.
If your file is intended to loop as a continuous broadcast, troubleshoot the first connection separately from playlist or looping behaviour. The guide to keeping a prerecorded sleep-sounds stream running overnight deals with continuity after a stream is configured; a session that never opens needs the endpoint, egress and build checks first.
Read YouTube encoder and stream-health signals
Once the connection appears to establish, use Live Control Room to determine whether YouTube is receiving and processing media. A connected session, an incoming signal, a playable preview and healthy stream indicators are related but distinct observations. Note exactly which appear and when. A preview that remains unavailable while FFmpeg is still failing to open the output is not evidence of a codec problem.
If YouTube receives media but reports poor stream health, inspect FFmpeg’s ongoing output, its error messages, CPU load and outbound connection as YouTube advises in its troubleshooting material. Then review the encoder settings that apply to the actual content. YouTube’s general guidance covers supported codecs and settings such as H.264 video, AAC or MP3 audio, constant bitrate, and keyframe intervals no longer than four seconds. These are media-path checks: they do not establish that a TCP connection or TLS handshake succeeded.
Use the boundary between transport and media to choose the next test. If there is no incoming signal and FFmpeg reports a connect timeout, return to the hostname, port and egress checks. If there is incoming media but the preview is black or unstable, inspect stream mapping, codec, timestamps and encoder load. If YouTube shows an authentication-related error, re-check the active stream key and destination rather than changing a video bitrate.
This is also where a 24/7 operator should keep the operating arrangement in view. If your workflow depends on a computer remaining on just to relaunch a file-based YouTube stream after interruptions, StreamNeo removes that particular need by taking an uploaded video and running the YouTube broadcast without your computer switched on. It does not diagnose a Hetzner command, change your firewall, or make a YouTube connection issue disappear; it is relevant when the specific ongoing burden is keeping your own machine running and restarting the broadcast.
Retest and record the result
Retest with a short, controlled procedure. Keep the selected broadcast, endpoint, key, FFmpeg binary and input unchanged while testing one suspected cause. Note the UTC time, the exact redacted command, FFmpeg version/build, firewall state, the last relevant stderr lines and what Live Control Room displayed. A brief record prevents you from repeating the same guess later or confusing one run with another.
A useful sequence is to confirm the active URL and key, verify RTMPS hostname and port, inspect the attached outbound rules, and confirm the binary’s protocol support. After each check, retry once and note whether the failure point changed. If it did, that is evidence that narrows the issue; it is not, by itself, proof of a lasting fix. Observe the channel after the retry and confirm that YouTube continues to receive media rather than merely showing a momentary connection.
When the standard checks do not isolate the fault, gather the missing evidence before asking for help: sanitized command and complete stderr, FFmpeg version/build configuration, URL scheme plus redacted hostname and port, relevant DNS/TLS/connectivity test results, the attached firewall’s outbound rules, and Live Control Room status. Keep the stream key secret throughout. Those details make diagnosis possible; the title of the problem alone does not.
If you are deciding whether to keep operating the stream from your own VPS or use a different workflow, make that decision separately from the diagnosis.
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 “connecting” prove Hetzner is blocking the stream?
No. It only describes the visible symptom, and the cause cannot be named without the actual command and logs. Check the active endpoint, protocol and port, attached outbound rules, and FFmpeg build before drawing that conclusion.
Should I change RTMPS to RTMP to get past a timeout?
Not as a blind fix. Verify the active endpoint and use the protocol and hostname YouTube supplies; RTMPS uses port 443 and relies on the hostname for TLS/SNI. Changing protocol adds a variable and does not show whether the original problem was the endpoint, firewall or binary.
Does a healthy connection mean the stream is healthy?
No. YouTube receiving a connection is different from receiving playable media with healthy encoder settings. If data reaches YouTube, use its stream-health indicators and inspect codec, mapping, bitrate behaviour, keyframes and encoder output.
What should I share if I still need help?
Share the complete FFmpeg command with the key redacted, the full relevant stderr, FFmpeg version and build configuration, the endpoint scheme/hostname/port, outbound firewall rules and Live Control Room status. Include DNS or TLS test results if you have them, and do not include credentials.