A YouTube stream key error from a Hetzner server does not, by itself, show that Hetzner is blocking the stream. Start by separating a stale or mismatched key from a wrong ingest URL, protocol support, outbound filtering, and a YouTube channel or broadcast that is not ready.
Work through those checks in order and change one thing at a time. The exact error text, encoder, server type and effective firewall rules matter; without them, nobody can reliably name the cause from the server location alone.
Check the selected YouTube broadcast and key
Open YouTube Studio and go to Go Live, then the Stream tab for the broadcast you intend to use. Compare the selected stream with the details configured in your encoder. A key from another stream, or a key saved before the current stream setup was changed, can look like an authentication failure even though the server can reach YouTube.
Copy the current key from Live Control Room and replace the saved value in the encoder. Keep the key in the encoder's key field and the Stream URL in its server or URL field; they are separate settings. YouTube describes stream keys as “like your YouTube stream’s password and address” in its live stream settings guidance. Treat the key as a secret: do not include it in screenshots, public logs, or a support request.
If you think the key has been exposed, reset it in Live Control Room and update the encoder with the replacement. This invalidates the old configuration for future use, so make sure you know where the encoder stores its settings before replacing anything. If a key refresh changes nothing, do not keep resetting it; move on to the URL and connection checks rather than treating every startup error as proof of a bad credential.
For an OBS setup, the practical distinction between a stream key and the rest of the broadcast settings is also covered in this guide to setting the YouTube stream key in OBS. The interface differs across encoders, but the same discipline applies: select the intended broadcast, copy its current key, and place it only in the credential field.
Confirm the stream URL and protocol
A correct key cannot compensate for a server URL that points to the wrong ingest destination or protocol. In Live Control Room, copy the Stream URL for the same stream configuration as the key. Check that the encoder has not retained an older URL from a previous session, and inspect whether it expects the URL and key as separate fields or as a combined value.
If you selected RTMPS, use the RTMPS URL shown by YouTube rather than assuming that changing a setting in the encoder also changes the destination address. YouTube's RTMPS instructions explain that RTMPS is RTMP carried over a TLS/SSL connection. The URL, port and encoder protocol support need to agree. The ordinary RTMP URL may be shown by default in the relevant YouTube workflow, so copy the secure URL deliberately when RTMPS is what you mean to use.
An “invalid SSL certificate” message and a rejected key are not the same clue. For that specific certificate error, YouTube's RTMPS guidance suggests trying port 443 in the URL or configuring that port in the encoder. Do not treat that as a universal port setting: follow the current URL in Live Control Room and use the port only in the context YouTube documents. If the error is a timeout after checking the URL, look next at encoder support and outbound reachability.
A connection timeout, a TLS/certificate complaint and an authentication rejection point to different parts of the path, though encoders do not all use identical wording. Record the literal error before changing settings. If you have been editing a URL by hand, restore the current value copied from YouTube and test again before introducing any other change.
Verify outbound connectivity and firewall rules
An encoder on a server initiates a connection out to YouTube's ingest endpoint. That is why opening an inbound port on the server is not a sound first fix for a failed outgoing broadcast. Check the destination and port in the current Stream URL, then inspect the rules that actually apply to that server: the Hetzner product firewall, if present, and the operating-system firewall on the machine.
For a Hetzner Cloud Firewall, the default depends on whether you have added outbound rules. Hetzner's Cloud Firewall FAQ says that when there are no outbound rules, all traffic is allowed. When custom outbound rules exist, new traffic that does not match them is dropped; established and related return traffic is allowed because the firewall is stateful. Confirm whether a custom policy is attached and whether it permits the connection to the destination and port in the current YouTube URL.
Do not guess a fixed YouTube IP address or add a broad rule on the assumption that one address will remain correct. Use the active URL and the firewall's supported way of expressing the required destination. Also check local firewall rules, since a permissive Cloud Firewall does not prove that the operating system allows the encoder's outgoing traffic.
A Hetzner dedicated server is a different case from a Cloud Firewall. Hetzner documents its dedicated-server firewall as stateless. If outbound filtering is enabled, response packets may need to be permitted explicitly as well as the initial outgoing connection. Its documentation discusses TCP acknowledgement and ephemeral-port rules as examples, but those examples are not a copy-and-paste rule for every server. Verify how your actual ruleset treats return traffic before editing it.
The relevant question is therefore not simply “Do I need to open a port?” It is whether the correct outgoing connection and its return traffic are allowed by the firewall layers in use. If a firewall policy changed shortly before the failure, compare the effective rules before and after that change and test the narrowest relevant adjustment. Avoid disabling protections indefinitely as a diagnostic shortcut.
Check encoder support for the chosen protocol
The encoder has to support the protocol named by the URL. A correct RTMPS URL can still fail if the software or its installed version cannot establish the secure connection. Check the encoder's documentation and version, and confirm that its selected output mode matches RTMP or RTMPS as appropriate.
YouTube recommends using the latest encoder version in its encoder troubleshooting guidance. Update only from the encoder's official source, then verify the output protocol and destination again. If the encoder reports a TLS or certificate error, retain that exact wording; it is more useful than labelling the entire problem “bad key”. If it reports timeout, investigate reachability and firewall egress as well.
For an FFmpeg workflow, inspect the command line and the encoder output carefully: an overlooked URL value or protocol option can send you down the wrong diagnostic path. This is distinct from issues such as choppy playback after a stream has connected, which have different clues; the FFmpeg choppy-video troubleshooting guide focuses on that later-stage problem. A connection or authentication failure should be diagnosed before changing bitrate or video quality settings.
If your always-on setup depends on a computer staying on and a local encoder recovering from interruptions, that is a separate operational trade-off from authentication. A comparison of a used desktop PC for a 24/7 stream can help you evaluate the local-computer route without implying that hardware choice determines whether a key is accepted.
Confirm the channel and stream are ready
Once the encoder starts, look at Live Control Room and check whether YouTube receives the feed and displays a preview. YouTube advises waiting for the preview before going live. If no preview appears, the failure is still somewhere in the delivery path: key, URL, protocol support, DNS or network reachability, or firewall policy. A preview is useful evidence that the feed reached YouTube, but it does not by itself prove that the channel can start the live event.
If the feed reaches YouTube but the live event cannot be started or made available, check the channel's live-stream eligibility and any restrictions shown in Studio. YouTube's live-streaming requirements state that a channel must be verified and must not have live-streaming restrictions in the previous 90 days. Check the current official page and the notices in your account rather than assuming that an encoder change can resolve an account-side restriction.
Separate the steps: the encoder connects, YouTube receives enough of the feed to show a preview, and the creator starts or schedules the live event. A problem in the last step should not lead you to repeatedly rotate a key that has already carried video to the preview. Conversely, if the feed never reaches Studio, account eligibility alone will not explain a timeout or TLS error from the encoder.
Use logs to narrow the failure class
Read the encoder's own status and logs around the moment it tries to connect. Preserve the literal message and its timestamp, but redact the key and any other credentials before sharing excerpts. A phrase such as “authentication failed” is worth recording, yet the full surrounding lines may show whether the encoder reached a server, failed TLS negotiation, timed out, or received an application-level rejection.
Use the following comparison to choose the next check, not as a promise that every encoder uses the same wording:
| Clue in the report | First check | Next action |
|---|---|---|
| Authentication or startup rejection | Key belongs to the intended Live Control Room stream and is current | Copy the current key; reset only if needed, then update the encoder |
| Invalid certificate or TLS complaint | URL scheme, copied RTMPS address, and encoder support | Restore the current RTMPS URL; for YouTube's documented SSL error, check its port 443 guidance |
| Timeout or failure to connect | URL host and protocol, DNS/reachability, and outbound policy | Inspect egress and return-traffic rules for the actual firewall product |
| Preview appears but event will not start | Channel status and stream readiness in Studio | Check verification, restrictions, and the current live-stream requirements |
The table is a triage aid, not a mapping from one exact message to one guaranteed cause. Keep the key out of shared logs and screenshots; when asking for help, provide the encoder name and version, operating system, server tier, redacted destination URL, exact message, and relevant egress rules. Those details make it possible to distinguish a credential problem from a network path problem without exposing the secret.
For a continuous channel, the useful test is one that can be repeated after a restart: keep a short record of the active URL type, selected stream, encoder version, and whether Studio showed a preview. Do not include the key in that record. If video reaches YouTube but then has poor health, use YouTube's encoder status and connection guidance rather than restarting the earlier authentication investigation from scratch.
Retry safely with the active stream details
Make one controlled retry after confirming the selected broadcast, current key, URL and protocol. Start the encoder, watch its own connection status, and check Live Control Room for preview. If you changed a firewall rule, note exactly what changed and test again; if you changed the key, ensure that the encoder is no longer using the old saved value. This makes the result interpretable instead of leaving several simultaneous edits to unwind.
If the retry still fails, stop short of repeated key resets or broad firewall changes. Capture the exact error with secrets redacted, the encoder and version, whether you are on a Hetzner Cloud or dedicated product, and the applicable outbound and local firewall rules. Include whether the stream ever appeared in preview. With that evidence, support can address the right layer; without it, a server location alone is not a diagnosis.
For a channel built around a fixed video or playlist, you can also reduce the number of places that hold credentials and machine-specific settings. StreamNeo turns an uploaded video into a YouTube live stream, so it removes the need to keep a local encoder computer running just to sustain that broadcast; the active YouTube key and stream settings still need to be correct. It is YouTube-only, so it does not change the checks for an encoder or destination outside YouTube.
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
Why is YouTube saying my stream key is invalid?
First confirm that the encoder contains the current key for the intended stream in Live Control Room. If the key may be stale or exposed, reset it there and replace the saved value in the encoder; also check that the separate Stream URL is correct.
Do I need to open a port on my Hetzner server?
Not as a general fix for an encoder connecting out to YouTube. Inspect outbound rules and the return path for the actual Hetzner firewall product and local firewall, then follow the destination and port in the active Stream URL rather than guessing a universal port.
Does a Hetzner server location mean Hetzner is blocking YouTube?
No. The server's location does not establish the cause. A key mismatch, URL or protocol mistake, encoder limitation, egress policy, return traffic, or channel readiness could each explain a failure; use the error and connection evidence to narrow it down.
What information should I include when asking for help?
Provide the literal error, encoder and version, server type, redacted target URL, whether YouTube showed a preview, and the effective outbound rules. Never post the stream key, even if a log or screenshot appears to be the easiest way to show the configuration.