For YouTube Live, use the stream-specific ingest URL shown in Live Control Room for the stream you are configuring. If your encoder offers RTMPS, use the RTMPS URL; enter the stream key separately in the encoder’s key field.
IPv4 and IPv6 describe how your network reaches an address, not which kind of YouTube URL you should invent. YouTube’s reviewed documentation does not guarantee that its current RTMP or RTMPS ingest hostnames work over IPv6, so test the exact supplied hostname on your network and confirm support with YouTube or your encoder vendor.
What the ingest URL does
The ingest URL tells your encoder where to send the live audio and video. Think of it as the destination address for a particular stream session. The stream key is a separate credential that identifies the stream to YouTube. In the usual encoder workflow, you provide both: the URL in a server or URL field and the key in a stream key field.
YouTube generates or provides stream information through Live Control Room, and the URL is not a universal address that should be copied from an old tutorial. A remembered example may reflect another stream, protocol, or workflow. Open the control room for the stream you intend to broadcast and use the address presented there. YouTube’s live stream settings help explains where the stream URL and key appear.
This distinction also helps when diagnosing connection failures. A correct key cannot repair a wrong destination URL, and a correct URL does not compensate for an incorrect or revoked key. If you are configuring an always-on channel, keep a note of which encoder profile and stream in Live Control Room correspond to one another. That is more useful than maintaining a generic “YouTube URL” in a document and assuming it will always be current.
The URL is also separate from the network protocol family. RTMP versus RTMPS is about the streaming protocol and whether the connection is encrypted; IPv4 versus IPv6 is about the network address family used to reach the destination. Selecting an RTMPS URL does not itself prove IPv6 reachability, and an IPv6-capable encoder does not make a guessed URL valid.
Find the URL for the stream you are configuring
In YouTube Studio, open Live Control Room and select an existing scheduled stream or create the stream you plan to use. Go to its stream settings and copy the stream URL that YouTube shows. If you want an encrypted connection, use the control to reveal or select the RTMPS URL where it is available. YouTube may show the standard URL by default, so do not assume the displayed choice is RTMPS without checking.
Use the address for the intended stream and the protocol you have chosen. If you are moving from one stream setup to another, revisit Live Control Room rather than assuming that a previously saved address remains appropriate. For a programmatic workflow, the YouTube Live API returns ingestion information for a stream, including primary and optional backup addresses. Its LiveStreams reference describes the relevant fields.
A primary address and a backup address are not interchangeable labels for the same field. The API distinguishes primary from backup, and it separately distinguishes RTMP and RTMPS addresses. If your encoder asks for a primary server and a backup server, match each field to the value YouTube provides for that role and protocol. If it asks for only one server, use the primary address unless your workflow documentation tells you otherwise.
Do not modify the hostname to make it “look like” an IPv4 or IPv6 address. A hostname is intended to be resolved by DNS, and the supplied hostname is also relevant to TLS certificate and server-name checks when using RTMPS. Replacing it with a numeric literal can change which endpoint is reached and interfere with the identity checks expected for a secure connection.
For a local news loop, for example, you might schedule a broadcast in Studio, take the RTMPS URL from that stream’s settings, and paste it into the encoder profile called “evening bulletin”. If you later create a separate stream for a devotional playlist, retrieve that stream’s details rather than copying the earlier profile’s URL and key without verification.
Choose RTMPS when your encoder supports it
RTMPS is RTMP carried over TLS, which encrypts the connection between encoder and ingest endpoint. YouTube states, “You can stream to YouTube Live with RTMPS, a secure extension to the popular RTMP streaming video protocol.” Its RTMPS help page describes choosing the RTMPS URL and checking the protocol and port when troubleshooting.
If your encoder has a YouTube RTMPS preset, it may populate the protocol and other connection fields for you. Still check that the chosen stream and key are the ones you mean to use. If there is no preset, paste the RTMPS URL from Live Control Room into the server or URL field and use the key separately. Do not change rtmps to rtmp by hand to see whether it connects; choose the matching address YouTube provides.
YouTube’s RTMPS integration guidance describes using port 443 and the server hostname for SNI, the server-name information used during TLS negotiation. The exact settings depend on the encoder’s interface, but an error involving TLS, protocol, hostname, or port is a reason to compare the profile against YouTube’s RTMPS ingestion guide. Keep the hostname from YouTube intact when checking those fields.
If your encoder or intermediary device does not support RTMPS, use the protocol and URL that YouTube makes available for that workflow, and understand that RTMP does not provide the same encrypted transport. The right choice is the secure option your encoder can actually handle, not a URL selected solely because it appears familiar. For a larger setup decision, the trade-offs between a local encoder and a cloud-based workflow are covered in YouTube 24/7 streaming software versus a cloud streaming service.
Protocol choice is not a way to choose IP family. RTMPS can still depend on the network, DNS, routing and encoder’s socket support. Likewise, an IPv6 route alone does not establish that the destination hostname offers a reachable IPv6 address on your particular path.
Enter the stream key separately
Most encoder workflows present a server or URL box and a separate stream key box. Put the YouTube-provided ingest URL in the first and the matching key in the second. Treat the key like a password: it can allow someone to send a broadcast to your stream, so do not publish it in screenshots, support posts or shared setup notes.
YouTube’s encoder setup instructions describe entering the stream URL and stream key into encoder software. Follow the labels and format required by your encoder rather than assuming every product arranges the fields identically. If your encoder exposes a stream name or application name as another field, consult its documentation before combining values.
An API-oriented encoder may represent the server URL and stream name separately, or expect them joined in a particular format. The LiveStreams API describes ingestion address fields and a stream name/key; an encoder may assemble them according to its own conventions. Do not append the key to the URL unless the encoder’s instructions explicitly require that format. If you are unsure, start from a YouTube preset or the encoder’s YouTube-specific setup guide.
Keep a record that identifies the profile without exposing the key. For example, note “evening bulletin, RTMPS, key ending in [private note]” only if your own security process permits such a reference; avoid recording the key itself in plain text. If the key is exposed, reset it in YouTube Studio and update the encoder. Changing the key does not fix a URL or network problem, but it prevents continued use of a compromised credential.
When changing encoder software or handing the setup to another operator, verify both fields independently. A key copied from an old stream may be valid but belong to the wrong broadcast, while a current key paired with an outdated URL can also fail. This simple separation makes troubleshooting clearer: confirm destination first, then the authentication value, then the network path.
Check the encoder’s URL and protocol settings
Before testing, compare the encoder profile with the values in Live Control Room. Confirm the hostname was copied exactly, that the URL uses the intended RTMP or RTMPS protocol, and that the key is in the field intended for it. If the profile contains primary and backup destination fields, check that each is populated with the corresponding address rather than duplicating one by habit.
If the encoder offers a YouTube preset, inspect rather than blindly trust it. Presets can simplify setup, but may select a protocol or field format that differs from the stream settings currently shown in Studio. If you entered the URL manually, check for a missing character, pasted whitespace, or an accidental protocol change. Do not add a guessed port, path or address suffix.
For RTMPS connection errors, check the protocol prefix and the port expected by the YouTube instructions. The RTMPS guide identifies port 443 and notes the importance of the hostname for SNI. Some encoders hide such details behind a preset; if so, use the encoder’s connection diagnostics and documentation to learn what it is attempting, rather than changing values at random.
Once the connection is accepted, check the preview and stream health indicators in Live Control Room. YouTube recommends testing with representative audio and movement and monitoring the event. A still image with quiet audio may not reveal issues that appear in a full devotional playlist, a changing news bulletin, or a lofi visual with continuous motion. For broader failure patterns, see the practical guide to why FFmpeg may stop sending video to YouTube after a few hours.
Keep URL diagnosis separate from media-quality diagnosis. If the encoder connects but the picture judders or the audio and video drift, bitrate, keyframe, frame-rate and encoding settings may need attention. YouTube’s encoder settings guidance covers those media settings. A network address-family change is not a substitute for tuning an overloaded encoder or correcting an unsuitable output profile.
For an always-on channel, do the test before the stream matters to viewers. Start with the actual file or playlist, let the encoder run long enough to confirm stable sending, and check both the encoder’s status and YouTube’s preview. If you are building a bulletin-based channel, the article on building a 24/7 news channel from your own bulletins can help with the content side; it does not change the need to use the current stream-specific URL.
What to verify on an IPv6-only connection
The honest answer to “Does YouTube RTMP work over IPv6?” is that the reviewed official YouTube material does not establish a universal guarantee either way for current RTMP or RTMPS ingest hostnames. Do not infer support from the fact that the URL contains a hostname, and do not infer non-support from an error on one encoder or network. Compatibility depends on the exact hostname, DNS response, routing, local firewall policy, encoder support and destination reachability.
On an IPv6-only connection, test the exact hostname copied from Live Control Room using the encoder and network that will carry the stream. Check whether the encoder can resolve the hostname and establish the selected protocol connection on that network. A DNS lookup by itself is not a full streaming test: it does not prove that the encoder can open the connection or that the broadcast will remain stable.
Ask YouTube or the encoder/network vendor for a definitive statement about the specific product and network path if IPv6-only operation is a requirement. In a support request, provide the protocol, the exact hostname (not the secret key), encoder model or software version, and the nature of the network restriction. Do not include your stream key in an ordinary support ticket unless the vendor has a secure, explicit process that requires it.
Do not replace the supplied hostname with a guessed IPv4 or IPv6 numeric address. YouTube’s RTMPS guidance relies on the server hostname for SNI, and a numeric substitute can prevent the expected TLS identity from being presented. A guessed address is also not evidence that YouTube has assigned or supports that endpoint. If an official source supplies a different address or a vendor documents a supported configuration, follow that source rather than a forum post or old command example.
If your connection is not IPv6-only, a useful comparison is to repeat the same test over a network path known to provide IPv4, without changing the URL or key. If it works there but not on the IPv6-only path, that narrows the investigation towards address-family reachability, DNS, firewall or encoder support; it still does not prove a universal YouTube limitation. Record the test conditions and ask for vendor guidance before a planned event.
If you must deliver continuously and cannot validate the encoder path before launch, consider whether the present connection is suitable for the operational risk you can accept. Some operators need a network or encoder configuration that they can test reliably before going live; others can wait for a vendor-confirmed answer. For a home devotional stream, the practical fix may be to test on the actual broadband router and encoder rather than assume the laptop’s IPv6 status tells the whole story. The guide to preventing buffering in a 24/7 worship stream covers adjacent stability checks, not a promise about IPv6 ingest.
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
What is the YouTube RTMP ingest URL?
It is the stream destination URL provided for the broadcast in YouTube Live Control Room. Copy it for the specific stream you are setting up; do not reuse a sample hostname from an old guide. If RTMPS is available in the stream settings and supported by your encoder, use that URL.
What server URL do I use for YouTube Live?
Use the URL shown for the intended stream in Live Control Room, with the protocol that matches your encoder setup. Enter the stream key in the separate key field unless your encoder documentation explicitly specifies another format. For API-driven tools, follow the tool’s handling of the primary address, backup address and stream name.
Does YouTube RTMP work over IPv6?
The reviewed official sources do not guarantee that current YouTube RTMP or RTMPS ingest hostnames work over IPv6, nor do they establish that they cannot. Test the exact hostname on the actual IPv6-only network and encoder, and ask YouTube or the vendor to confirm support. Never substitute a guessed numeric address.
Should I use RTMP or RTMPS for YouTube?
Use RTMPS when YouTube provides the URL and your encoder supports it, because it encrypts the RTMP connection through TLS. Keep the supplied hostname intact and check the encoder’s protocol and port settings if the connection fails. If your encoder cannot use RTMPS, follow YouTube’s available URL and the encoder’s documented setup.