What Is rtmp://a.rtmp.youtube.com/live2? Backup & Key Fixes

rtmp://a.rtmp.youtube.com/live2 is YouTube's primary RTMP ingest URL. That part is simple, and it's probably why you're here. The harder parts are the backup server nobody explains, the RTMPS port you need when a network blocks 1935, and the handful of reasons YouTube rejects a stream key that looks perfectly correct.

All four ingest URLs are below, then the fixes.

Every YouTube RTMP and RTMPS URL

YouTube gives you a primary server, a backup server, and secure (RTMPS) versions of both. RTMPS is the same protocol over an encrypted TLS connection, per YouTube's official documentation.

Your stream key goes in a separate field. Never paste it onto the end of the URL.

What is rtmp://a.rtmp.youtube.com/live2?

Each part of the URL has a job:

• rtmp:// is the protocol. RTMP (Real-Time Messaging Protocol) carries your stream from your encoder to YouTube.
• a.rtmp.youtube.com is YouTube's primary ingest server. The a marks it as the main server, not the backup.
• /live2 is the application path that routes your stream into YouTube's live system.
• Port 1935 is the RTMP default and is used automatically unless you specify another.

It's only half the connection. The stream key is the other half, and it's what tells YouTube which channel the video belongs to.

RTMP itself is an ingest protocol originally built by Adobe. Practically every encoder, hardware device, and cloud streaming tool speaks it, which is why YouTube still uses it as the main way to receive a broadcast.

The backup server, and how failover actually works

The b server is not a spare you switch to when something breaks. It's a second ingest that runs at the same time as your primary, fed by a second encoder sending the same content.

That's the part most guides skip. Pointing your only encoder at the backup URL doesn't buy you redundancy. It just means you're streaming to the backup.

YouTube's own testing instruction makes the setup clear: "For test encoder failover, stop the primary encoder (or unplug its Ethernet cable) and make sure the player rolls over to the backup encoder." Two encoders, both running, one of them stopped on purpose to prove the rollover works.

The settings on both have to be identical. YouTube documents a specific failure for this called Mismatched Primary/Backup Streams, triggered by any difference in resolution, codec, interlacing, bitrate, frame rate, keyframe frequency, audio sample rate, or audio channel count. Close isn't good enough.

If the primary drops and a matching backup is already arriving, YouTube rolls over and the broadcast continues. Without a backup feed, a dropped primary is just a dropped stream. And redundancy you've never tested is an assumption, so stop the primary once before the broadcast that actually matters.

For an always-on channel this matters more than for a one-off broadcast, which is one reason 24/7 streams are easier to run from the cloud than from a machine in your house.

When you need RTMPS and port 443

Use RTMPS by default. It's the same ingest with TLS encryption, so your stream and key aren't sent in the clear.

It also solves a specific problem: plenty of corporate, campus, hotel, and mobile networks block outbound port 1935 because almost nothing else uses it. Port 443 is standard HTTPS traffic and is essentially never blocked. If your encoder connects fine at home and fails on another network, that's the cause, and switching to rtmps://a.rtmp.youtube.com:443/live2 fixes it.

To reveal the RTMPS version in YouTube Studio, click the lock icon on the Stream URL field.

Why YouTube rejects your stream key

A rejected key is rarely a wrong key. These are the real causes, in the order worth checking.

One setting catches people out in OBS specifically: pick the YouTube - RTMPS service rather than an older RTMP entry, since RTMPS is the ingest YouTube documents for encoders now.

When the key is fine and YouTube still refuses the feed

This is the other half, and it's where people waste the most time. The key connects, then YouTube rejects what arrives. These are the causes YouTube documents by name:

• Incorrect stream format. YouTube wants H.264 video and AAC audio. Another codec gets refused.
• Incorrect video keyframe frequency. Send keyframes every 2 seconds, using a closed GOP. YouTube's encoder settings recommend 2 seconds and say not to exceed 4.
• Incorrect bitrates. Audio should be 128 Kbps at a 44.1 kHz sample rate, and video bitrate has to suit the resolution. 1080p30 runs 8 to 12 Mbps depending on codec; 1080p60 runs 10 to 12.
• Incorrect audio settings. Exactly one audio stream, no more than two channels. No audio stream at all is a common encoder-checkbox mistake.
• Incorrect video settings. Exactly one video stream, progressive rather than interlaced.
• Incorrect resolution. The encoder output has to match what the stream was set up to ingest.
• Daily live stream limit reached. YouTube caps how many live streams a channel can create in 24 hours. Nothing is broken. You've run out for the day.

Most of these read as "my stream key doesn't work" from the encoder side, which is why the key gets blamed. Match your bitrate to your upload speed and start from sane encoder settings and most of the list disappears.

How to find your stream URL and key

1. Open YouTube Studio, click Create, then Go Live.
2. Confirm live streaming is enabled on your channel. First-time activation can take 24 hours.
3. In the Stream settings tab, copy the Stream URL and the stream key.
4. Click the lock icon on the Stream URL field to reveal the RTMPS version.

Paste the URL and key into separate fields in your encoder, then start the stream.

Skip RTMP entirely

None of this is required. Cloud streaming tools like LiveReacting connect to your YouTube channel directly: upload a video, go live in about five minutes, no encoder, no ingest URL, and no PC left running overnight.

It works the other way too. You can multistream to any custom RTMP destination, run a 24/7 YouTube live channel from the cloud, or stream pre-recorded video as live without touching a stream key. Interactive polls, trivia and giveaways run on top of any of it.

FAQ

What port does YouTube RTMP use? Port 1935 by default. RTMPS uses port 443, which is the one to use if a network blocks 1935.

What's the difference between the a and b RTMP URLs? a is your primary ingest. b is a simultaneous backup ingest fed by a second encoder, not a fallback you switch to after something breaks.

Do I need the backup URL? Only if you run a second encoder to it at the same time as the primary, with identical settings. A single encoder pointed at the backup gives you no redundancy at all.

My stream key is correct but the stream still fails. Why? YouTube rejects the feed rather than the key. The documented causes are the wrong codec (it wants H.264 and AAC), keyframes not sent every 2 seconds, a bitrate or resolution mismatch, more than one audio or video stream, interlaced video, or hitting the daily limit on new live streams.

Is RTMP or RTMPS better for YouTube? RTMPS. Same protocol, encrypted in transit, and it works on networks that block port 1935.

Why does YouTube say my stream key is invalid when I just copied it? Check three things: that you used the copy button instead of typing it, that it went into the key field and not the URL field, and that nobody with owner or manager access has reset the key since you last saved it. YouTube doesn't expire or rotate keys on its own.

Can I stream to YouTube without an RTMP URL or OBS? Yes. Cloud tools connect to your channel directly, so you never see an ingest URL or a stream key.

Go live without the setup

rtmp://a.rtmp.youtube.com/live2 plus your stream key is all an encoder needs. The backup server, port 443 and a clean key are what keep it running once it's live.

If you'd rather not manage any of it, upload a video and launch a 24/7 live stream channel from the browser instead.