A YouTube stream going offline after you change OBS from RTMP to RTMPS does not, by itself, identify the cause. First compare OBS with the current RTMPS server URL and stream key in YouTube Live Control Room; then use the exact OBS error to choose the next check.
RTMPS changes how the connection is made, so the protocol and endpoint must match. YouTube’s guidance distinguishes SSL errors from timeouts: for an SSL error, check the URL and try port 443; for a timeout, verify the URL and confirm the encoder supports RTMPS.
Confirm the current YouTube server URL and stream key
Start in the Live Control Room rather than relying on an endpoint copied from an old OBS profile, an earlier broadcast, or a generic setup note. Open the stream’s settings and deliberately reveal or copy the RTMPS URL. YouTube says the ordinary RTMP URL may be shown by default, so make sure you select the RTMPS value rather than assuming a familiar-looking address is the right one. Its RTMPS setup guidance explains where to find the secure endpoint.
The server URL and the stream key do different jobs. The URL directs the outgoing feed to YouTube; the key identifies the stream YouTube should accept. In OBS, compare both fields with the values currently shown for that stream in Live Control Room. The YouTube guide to live stream settings covers these settings and key management.
Treat the key as a current credential, not as a permanent part of the server address. If you have changed or reset the key in YouTube, an OBS profile holding the earlier value may still appear configured but fail to deliver an accepted feed. Copy the current key carefully into OBS, taking care not to add a space at either end. Do not paste it into a public screenshot or support forum; share the exact error text instead.
It helps to inspect the two fields separately. A correct RTMPS URL with an old key is not the same failure as an RTMP URL with a current key. If OBS connects but YouTube does not accept the feed, revisit both values before changing bitrate, resolution, or other encoder settings. The title of this issue does not tell you which field, if either, is wrong.
If you keep a profile for a continuous channel, note which YouTube stream and key it is meant to use. A profile copied for another broadcast may retain a valid-looking but unsuitable endpoint or key. For broader operational planning around a dropped connection, see how a YouTube loop stream can handle a cloud-service reconnect; reconnect behaviour is a separate concern from confirming the destination and credentials.
Verify that the URL uses RTMPS
Look at the beginning of the server URL entered in OBS. For this configuration, it must use the rtmps protocol and the RTMPS endpoint supplied by YouTube. Do not edit an old address by guesswork or substitute a hostname that looks similar. YouTube’s official RTMPS article says both the protocol and server in the URL need to be RTMPS.
If OBS offers a YouTube RTMPS preset, it can reduce the chance of typing the protocol or destination incorrectly. Check that the selected service and server actually indicate RTMPS, then compare the result with the URL available in Live Control Room. A preset is a convenience, not evidence that every setting in an existing profile is correct.
A useful check is to compare the full URL, not just the scheme. Confirm that the value in OBS is the one supplied for the stream, including any path or endpoint details, and that the stream key remains in its separate field. Avoid combining the key and URL unless the encoder’s documented interface explicitly expects that format. OBS can retain values from an earlier setup, so opening the settings and checking them is more reliable than assuming the last change saved as intended.
If the connection starts after you correct the URL, leave unrelated settings alone for that test. Changing several things at once makes it harder to know what resolved the problem. If it still fails, classify the displayed message before moving on: an SSL or certificate error points to a different next step than a timeout or a feed YouTube rejects.
Understand RTMPS as RTMP over TLS/SSL
RTMPS is RTMP carried over a TLS/SSL-protected connection. It is not simply a label for a more reliable stream, and switching the setting does not guarantee that disconnections will stop. The encoder must make the right kind of connection to a compatible endpoint, and the network must allow that connection to complete.
This distinction matters when diagnosing an immediate failure. If OBS was previously configured with an RTMP URL, changing only a protocol selector may leave the server field pointing at the wrong endpoint. Conversely, entering the correct secure URL does not resolve an outdated key or prove that the installed encoder supports RTMPS. The title tells you that a change preceded the failure, but not which of those conditions applies.
Keep transport checks separate from video-output checks. Bitrate, keyframe interval, resolution and audio affect the stream you send, but they do not replace the requirement for the correct RTMPS destination. YouTube’s encoder settings guidance lists RTMP/RTMPS among supported protocols and provides other encoding recommendations. Use those recommendations as secondary checks once the endpoint and key have been verified.
For a 24/7 channel, this separation is useful when recording what changed. Write down whether the offline event began immediately after changing the URL, after changing a preset, or after restarting OBS. A sequence of events can direct the next test, but it still is not a confirmed cause until the exact error and settings support that conclusion. If your stream uses a prepared video loop, the connection issue should also be distinguished from the playback setup described in guidance on choosing a playlist for pre-recorded live streaming.
If OBS reports an SSL error, check the port 443 suggestion
When OBS displays an SSL or certificate error, first recheck that the full server URL is the RTMPS URL supplied in Live Control Room. YouTube’s documented guidance for this failure includes trying port 443. Apply that suggestion to the supplied URL or the encoder’s port setting where the interface allows it; do not invent a replacement hostname or endpoint.
The exact error wording is useful. Record or copy it before changing the setting, including whether OBS names a certificate, SSL handshake, or another failure. A generic report that the stream stopped is not enough to conclude that the issue is SSL-related. If the message does not identify SSL or a certificate problem, follow the diagnostic route that matches the message rather than changing the port speculatively.
After checking the URL and applying the documented port suggestion, make one test connection. Note whether the error changes, disappears, or remains identical. If it persists, restore or retain only settings you can verify against YouTube’s supplied values, and consult the current official guidance. Port 443 is a troubleshooting suggestion for the SSL-error case, not a universal fix for every RTMPS disconnection.
If OBS times out, verify the URL and encoder support
A timeout is a different clue from an SSL error. YouTube advises checking that the server URL is correct and confirming that the encoder supports RTMPS. Verify the endpoint in Live Control Room, then check the OBS version and the selected service or protocol options. If support is unclear, consult the current OBS documentation or update to a supported version before treating the timeout as a network fault.
Also consider whether OBS can reach the outbound internet connection at the time of the test. A firewall, network policy, or interrupted connection may affect an outbound stream, but the title alone does not establish that any one of these is happening. Avoid trying random ports or unrelated protocol combinations. Keep the test to YouTube’s URL, the documented RTMPS configuration, and an encoder that supports it.
If you are using a local OBS scene, check that the encoder is actually attempting to stream and that its status or log reflects a connection attempt. A timeout before YouTube receives a feed is different from a feed arriving and then being rejected. If the encoder starts but the stream does not appear as expected in Live Control Room, recheck the current key and inspect the local audio and video output. YouTube’s live-stream troubleshooting page includes broader checks such as updating the encoder and examining the stream locally.
When the protocol configuration appears correct but the connection remains unstable, bandwidth is a later check, not a substitute for resolving a URL or compatibility error. YouTube recommends keeping total streaming bitrate within available outbound bandwidth and leaving about 20% additional room, as described in its streaming tips. That is operational guidance; it does not prove that bandwidth caused this particular failure. Compare the combined audio and video bitrate with the connection available while the channel is live, preferably under the same conditions you expect overnight.
Retest methodically and record the exact error
Make a controlled retest after the URL, key, and protocol have been checked. Keep the scene and output settings unchanged for the first attempt. Start OBS, watch its status, and check Live Control Room to see whether YouTube receives the feed. Note the time and whether the failure occurs before connection, during connection, or after YouTube has begun receiving video.
Use the result to choose the next branch:
| What you observe | What to check next |
|---|---|
| SSL or certificate error | Confirm the YouTube-supplied RTMPS URL and try port 443 as YouTube advises. |
| Connection timeout | Verify the full URL and confirm the encoder version supports RTMPS. |
| OBS connects but YouTube does not accept the feed | Re-copy the current stream key and inspect the encoder’s local output. |
| Feed begins, then drops | Record when it drops, then investigate connection stability and available outbound bandwidth. |
These are diagnostic prompts, not guaranteed mappings from message to cause. The same visible symptom can have more than one explanation, and a changed message after a test is information rather than proof. Keep a short record of the OBS version, the selected protocol, whether the URL came from Live Control Room, the error wording, and what changed between attempts. Do not include the stream key in that record.
Once a short test works, test the same audio and motion workload your channel will use. A static screen and a busy video loop put different demands on encoding, and an overnight channel should not be judged only by a momentary connection. YouTube recommends testing streams and provides encoder settings to guide output configuration. For a continuous programme, also consider what viewers see when the stream returns; ways to switch videos in a live YouTube stream without disconnecting address programme transitions, which are distinct from diagnosing an RTMPS handshake.
Avoid changing bitrate or keyframe settings simply because the stream went offline immediately after a protocol change. If the URL, key, compatibility and error path check out, then review the encoder output settings against YouTube’s current recommendations and test again. YouTube lists CBR and a recommended two-second keyframe frequency, with a maximum of four seconds, on its encoder settings page. Treat these as configuration checks, not as a diagnosis of an endpoint or SSL problem.
If the issue cannot be reproduced, retain the notes rather than assuming it is fixed for good. A later test during a different network condition may behave differently. For a stream you rely on overnight, run a representative test at the time and on the connection you intend to use, and make sure you know how to read OBS’s status and Live Control Room’s incoming-feed state.
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 switching from RTMP to RTMPS always stop disconnections?
No. RTMPS is RTMP over TLS/SSL, and it requires a matching endpoint and encoder support. It does not guarantee that a connection will remain uninterrupted; diagnose the exact error and check the URL, key, and connection conditions.
Where do I get the correct RTMPS URL?
Open the stream settings in YouTube Live Control Room and reveal or copy the RTMPS URL. YouTube may show the ordinary RTMP URL by default, so deliberately select the secure endpoint and compare it with the full server URL in OBS.
What should I do if OBS gives an SSL error?
Check the URL against the one supplied by YouTube and try port 443, following YouTube’s RTMPS guidance. Do not substitute an endpoint you found elsewhere, and do not apply the port suggestion as a fix for a timeout unless the documented error calls for it.
What should I check for a timeout?
Verify the RTMPS URL and confirm that your installed encoder supports RTMPS. If those checks pass, record the exact message and examine whether OBS can make an outbound connection; do not assume the title alone identifies the cause.