If YouTube RTMP publish is rejected with error code 2, first capture the exact encoder message and the matching status in Live Control Room. The public YouTube guidance located for this issue does not define that exact code, so treat it as a clue to investigate, not a diagnosis.
Work through the checks in order: refresh the stream key, confirm the active ingest URL and protocol, then use encoder logs and Live Control Room messages to distinguish a connection failure from a stream-ingest problem. Do not assume the key, a port, or a codec is at fault unless the evidence points there.
What YouTube guidance says about error code 2
YouTube’s published troubleshooting material describes errors encountered when starting an encoder, connection issues, and problems with the stream being received. It does not, in the guidance located for this article, assign a specific meaning to the phrase “publish rejected with error code 2”. That distinction matters: an error shown by an encoder or its log is not necessarily a YouTube-defined code with a public explanation.
YouTube’s general recommendation when a third-party encoder reports an error at startup is to get a new stream key in Live Control Room and update the encoder. That is a sensible early check, but it is not evidence that every rejection with a displayed 2 comes from an invalid key. The same general troubleshooting process asks you to check the stream setup, encoder, connection and dashboard messages. See YouTube’s live-stream troubleshooting guidance for its current steps.
There is also a historical OBS forum report whose connection log ends in -2. It concerns an OBS connection failure and a particular configuration; it does not establish what YouTube means by “publish rejected” in another encoder. Treat that report as a reminder to inspect the actual log, not as an error-code lookup table.
For diagnosis, separate three states. The encoder may fail before it connects to YouTube; it may connect but fail to publish; or YouTube may receive the stream and report that its format or health needs attention. The word “rejected” alone does not tell you which of those states occurred. Your next action should follow the complete message and the dashboard, not the number in isolation.
Capture the full error context
Before changing settings, make a short record of what happened. Copy the complete error text, note which encoder or application produced it and its version, and record whether the message says it could not connect, that publishing was rejected, or that the incoming stream has a health issue. Include the time of the attempt so you can match it to the event in Live Control Room.
Open the active stream’s Live Control Room and note its status and any health message. If the encoder reports a rejection while the dashboard has no incoming stream, that is different evidence from a dashboard that shows an incoming stream but flags a format issue. Do not paraphrase both as “YouTube error 2”; preserve the exact wording from each place.
Screenshots can be useful, but keep credentials out of them. A stream key is effectively a publishing credential: do not post it in a public forum, send it in an unredacted screenshot, or include it in a log you share. Mask it before sharing other diagnostic details. If you need to send a report to support, provide the relevant text and timestamps without exposing the key.
Record what changed just before the failure: a new stream or key, a copied URL, an encoder update, a network change, or a change in the output profile. This is not proof that the last change caused the failure, but it prevents repeated trial and error. If the same configuration previously worked, say so and note when it stopped; if this is a first publish attempt, say that instead.
A useful initial note might read: “At the recorded time, the encoder named in the note showed the full message; Live Control Room showed the accompanying status; the encoder version and recent changes are recorded.” Keep it factual. Avoid interpreting the message as a bad key or codec problem until you have checked the relevant branch. If you need to understand where a URL and key belong in one common workflow, the guide on where to paste an RTMP YouTube URL and why it fails covers that distinction.
Get a new stream key and update the encoder
Once you have recorded the original state, try YouTube’s general first-line fix for an encoder startup error: open the correct stream in YouTube Studio’s Live Control Room, go to the stream setup, and copy its current stream key into the encoder. YouTube’s instructions are to obtain a new key in Live Control Room and update the encoder. Follow the current YouTube Help instructions for troubleshooting a live stream, since labels and screen layouts can change.
Make sure you are updating the encoder profile that is actually being used for this broadcast. Some applications keep separate profiles or saved destinations; changing a key in an unused profile will not affect the active publish attempt. After pasting, verify that the field is not truncated and that there are no unintended spaces. Do not place the key in a title, description, or URL field. The key and server address serve different purposes.
If you select a different stream or create a new stream setup in YouTube Studio, take the key and URL from that active setup rather than carrying over old values. A saved encoder configuration can remain stale even when the stream in Studio has changed. Make one credential change, then test once and record the result; changing several unrelated settings at the same time makes it harder to learn what mattered.
If the new key resolves the issue, the earlier failure may have involved a stale or mismatched credential, but that does not retroactively define code 2. If it does not, do not keep generating keys as a substitute for diagnosis. Move to the endpoint, protocol and log checks below. Handle the key as confidential during every further test, especially when you ask someone else to inspect the setup.
For a longer-running configuration, keep a private note of which encoder profile and YouTube stream setup are paired. A simple label such as “main channel, current scheduled stream” is more useful than a key pasted into a shared checklist. The Astra Streaming setup guide using a YouTube stream key illustrates why the destination and credential need to be entered in their intended fields; its product-specific steps are not a substitute for your own encoder’s current instructions.
Verify the endpoint and protocol
The endpoint is the server address to which the encoder sends the stream. Copy the URL from the active Live Control Room setup instead of relying on a saved address, a search result, or memory. Check the whole address, including its scheme and any path, against the encoder’s server or URL field. A correct key paired with the wrong endpoint can still fail to publish, and changing the key will not correct a URL mismatch.
Confirm which protocol the encoder is configured to use. YouTube supports RTMP and RTMPS workflows, but the encoder must support the protocol selected in the setup. For an RTMPS configuration, use the RTMPS URL revealed in YouTube’s setup and choose the corresponding option in the encoder. Do not take an RTMP address and merely change its prefix unless YouTube’s current instructions explicitly tell you to do so. Consult YouTube’s RTMPS setup guidance and follow the values shown for your stream.
If the log reports a connection or SSL error, that is evidence to investigate endpoint, protocol, network access and encoder compatibility. YouTube’s help material discusses port 443 for certain SSL errors; that is a conditional suggestion, not a universal fix for every rejection. Use the official instructions for the precise message you have, and do not infer that a blocked port is the cause merely because the error includes the number 2.
A practical check is to compare the URL shown in Studio with the URL in the active encoder profile, character by character, while keeping the key hidden. Then confirm that the selected protocol matches the URL and that the encoder supports it. If your encoder offers a test or preview mode, use it only if it does not start a second unintended broadcast. Avoid pasting a live key into a public diagnostic tool.
When a connection fails before publishing, investigate this branch first. When the encoder says it has connected and the dashboard sees an incoming stream, move on to the ingest or format messages instead of repeatedly changing the URL. This connection-versus-ingest distinction is also important in an always-on YouTube setup using Docker and FFmpeg: the sender’s output and the platform’s receipt are separate things to observe.
Check encoder logs and local output
The log is often more useful than a short pop-up because it shows what the encoder attempted and in what order. Find the entries around the failed attempt and look for the destination being used, whether a connection was established, and the response or error immediately after the publish attempt. Redact the stream key before sharing any excerpt. The exact words may narrow the branch, but do not treat an undocumented numeric suffix as a complete explanation.
If the log shows that no connection was established, check the copied endpoint, protocol, network path and encoder compatibility. YouTube advises keeping the encoder up to date, checking its output locally, looking at its dashboard errors and CPU load, and testing outbound internet when the encoder appears healthy but the stream is not reaching YouTube reliably. If a local preview is already broken, fix that output before diagnosing YouTube ingest. If the preview is sound but delivery is intermittent, focus on the sending connection and network.
If the encoder connects but reports a publish rejection, compare its response with the Live Control Room status and confirm the key and active stream pairing. If the dashboard receives video but reports an ingest problem, use the dashboard’s specific message to inspect output settings such as codec, container, bitrate, video stream configuration or keyframe frequency. YouTube lists these as categories of live-stream errors; they are not established causes of every rejection. Its live encoder settings guidance is relevant when the evidence points to an output-setting issue.
Check the encoder’s resource and network indicators while making a controlled test. A high CPU load, dropped frames or unstable outbound connection may explain why output that looks correct locally does not arrive consistently, but none alone proves the cause of code 2. If the issue persists after the key and endpoint checks, YouTube’s general advice includes trying another encoder as a diagnostic and contacting your internet provider if outbound connectivity appears faulty. Change one variable at a time and keep the result with the error context.
If you run a continuous channel, distinguish a one-off start failure from a failure that returns after the encoder has been live for a while. Record whether the stream ever appeared in Live Control Room and whether it disappeared or degraded later. A process that never connects calls for a different investigation from a stream that starts and later drops. For a pre-recorded broadcast, the practical trade-offs between keeping a machine involved and using a managed workflow are discussed in the guide to cloud services for pre-recorded YouTube live streams. That choice does not decode this error, but it can reduce the burden of keeping a local computer running and checked overnight.
Compare with Live Control Room details
Treat Live Control Room as a second observation point, not simply a place to copy the key. Look at whether the broadcast appears to be receiving data, whether the health indicator gives a message, and whether the status changes at the same time as the encoder’s attempt. The sequence helps you see if the failure occurred before YouTube received the stream or after receipt.
Use this comparison to choose your next step:
| Encoder and dashboard evidence | Most useful next check |
|---|---|
| Encoder reports it cannot connect; Live Control Room shows no incoming stream | Recheck the active URL and protocol, then examine network and encoder compatibility |
| Encoder reports a publish rejection; dashboard does not show a healthy incoming stream | Confirm the key belongs to the selected stream, then compare the complete encoder response and dashboard status |
| Encoder connects and Live Control Room reports a stream health or format issue | Follow the specific dashboard message and compare relevant output settings with YouTube’s current guidance |
| Encoder preview looks healthy but reception is intermittent | Check encoder load, dropped frames and outbound network stability; preserve logs from the same time |
The table is a diagnostic map, not a guarantee that every encoder and dashboard will use those exact labels. A missing incoming stream can also reflect a status delay, so refresh the control room and match timestamps before concluding that nothing arrived. If the messages contradict one another, preserve both and test again with the same profile rather than silently changing multiple settings.
For format-related alerts, consult the documented stream settings and adjust only the item connected to the dashboard message. YouTube’s recommended keyframe frequency is two seconds and should not exceed four seconds; use this only as a relevant setting check, not as a theory about all publish rejections. The help page on YouTube live encoder settings is the place to verify current supported choices. If the dashboard does not point to a format problem, leave those settings alone while you investigate credentials and connection.
If the issue is not resolved, prepare a concise support report containing the timestamp, encoder and version, full error text, redacted log excerpt, stream status, and checks already performed. Do not include the stream key. This makes it possible for support or an encoder community to reason from observed evidence rather than an ambiguous code. If an alternate encoder succeeds with the same stream setup, that narrows the investigation towards the original encoder’s configuration or compatibility, but it still does not reveal an official meaning for code 2.
For a channel that must keep running, plan the diagnostic window rather than experimenting during an important scheduled broadcast. Make one test at a time, check the control room, and retain the working profile before trying a different one. If you need the channel online while your own computer is switched off, StreamNeo can remove the specific burden of keeping that computer powered and restarting the broadcast yourself; it does not change YouTube’s key, endpoint or ingest requirements, and it is YouTube-only.
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 YouTube define publish rejected with error code 2?
The YouTube public guidance located for this article does not define that exact phrase or assign it a specific cause. Capture the full encoder message and compare it with the status and health details in Live Control Room before choosing a fix.
Does code 2 mean my stream key is wrong?
Not necessarily. YouTube recommends getting a new stream key and updating the encoder for a general third-party encoder startup error, so it is a reasonable early check. If a fresh key does not help, verify the active URL and protocol and use the logs to identify where the attempt fails.
Should I change the codec or open a port?
Only when the evidence points to that branch. A connection or SSL error calls for checking endpoint, protocol, network and encoder compatibility; a dashboard ingest warning may call for checking format settings. YouTube’s documentation does not say that every publish rejection with code 2 is a codec or port problem.
What should I share when I ask for help?
Share the exact message, encoder and version, the time of the attempt, a redacted log excerpt and the corresponding Live Control Room status. Never share an unredacted stream key, since it can be used to publish to your channel.