Why does my YouTube stream keep disconnecting? The interruption may start in your encoder, in SRS, on the connection from SRS to YouTube, or only on a viewer’s side. Work out which part of the chain is failing before changing bitrate or blaming the network.
If you are asking, “Why does OBS keep disconnecting and reconnecting to YouTube?”, treat the reconnect as evidence, not a diagnosis. Compare what the encoder shows with SRS status and logs, then check YouTube’s current ingest URL and the outbound path. No single RTMP or network setting prevents every disconnect, and a reconnect does not guarantee that the YouTube session has been restored.
First establish who sees the interruption
Start by separating a broadcast failure from a viewing problem. Check the encoder’s preview and status, the SRS process, and YouTube Live Control Room. At the same time, ask viewers what they saw and where they were watching. A creator whose encoder and SRS remain healthy may be dealing with a viewer-side problem rather than a failed broadcast.
YouTube’s troubleshooting guidance distinguishes between one viewer reporting trouble, several viewers using the same internet connection, and viewers watching from different connections. A single report points first towards that viewer’s device or connection. Reports from people sharing one network make that network worth checking. Reports across different networks can indicate an encoder-side issue, though they do not prove it. See YouTube’s live-stream troubleshooting guidance for its symptom-based checks.
Keep a short incident record. Note when the interruption began and ended, whether audio and video stopped together, what OBS or another encoder displayed, whether SRS remained running, and whether YouTube showed a status change. Ask whether a viewer was on mobile data, home Wi-Fi or a shared connection. These observations let you compare parts of the chain without guessing.
If the encoder reports a disconnect but viewers say the stream continued, the fault may be between the encoder and SRS, or the display may be stale. If the encoder still publishes to SRS but YouTube stops receiving, focus downstream. If the creator sees a healthy stream and just one person reports buffering, first test that person’s device and connection. Avoid changing several settings between observations: you will lose track of which change affected the symptom.
Inspect the encoder at the time of the drop
Look at the encoder’s own preview and status around the recorded timestamp. Check whether the local picture freezes, audio disappears, the application reports a publishing error, or the output continues normally. A local recording made during the incident can help distinguish a source or encoding problem from a problem that starts later in the chain. It is useful only if it captures the relevant output and time period.
If the preview or recording is also poor, inspect the source files or live inputs, encoder messages and CPU load. Confirm that your encoder software is current, then check whether the issue follows a particular scene, media source or transition. YouTube’s troubleshooting flow suggests trying a different encoder when the local archive looks clean but stream symptoms persist; that is a controlled comparison, not a promise that changing software will fix the problem.
For creators using OBS, compare its reconnect messages with what SRS reports. A reconnect message says that OBS lost or re-established a publishing connection; it does not identify why. Record the exact error text and whether OBS says it is connected to the intended SRS address. If the encoder publishes to SRS successfully throughout the interruption, changing OBS bitrate is unlikely to be the first useful test.
A looped devotional playlist, lofi station or local news video has a slightly different source check from a camera stream: verify that the media keeps advancing and audio does not fall silent at a file boundary. This is separate from transport health. If your issue is a gap between clips rather than a publishing interruption, the guide to looping a playlist stream with FFmpeg on Windows covers that different failure mode.
Check SRS status and logs
SRS sits in the media path between a publisher and a playback destination. A process can be alive while a particular publish session is broken, so check both whether the service is running and what its logs say at the moment the connection drops. The SRS project wiki demonstrates basic process and log checks, including following objs/srs.log, and shows an example RTMP publish. It is an older v3-era overview: use it to understand the kind of evidence to collect, not as version-specific configuration instructions for every deployment.
Exact status commands, log locations and service names depend on how you installed or deployed SRS. A packaged service, container or manually started process may differ. Use the service manager or deployment method you actually use to check whether SRS is running, then locate its configured log output. Do not assume objs/srs.log exists at that path on your system.
Compare the SRS log timestamp with the encoder’s reconnect time and any YouTube status change. Look for the first event in the sequence: publisher disconnected, publish rejected, process restarted, downstream connection failed, or an error in media handling. An error immediately before the visible drop is more useful than a later reconnect notice. Save the surrounding lines, but redact stream keys, credentials, public IPs if they are sensitive, and other private details before sharing a screenshot or log excerpt.
An SRS issue reports a particular case involving repeated RTMP reconnects and an invalid avc sample length=0 message during HLS video handling. The report concerned a specific SRS version and DJI device; it is a reason to search your own logs for relevant errors, not a universal explanation for disconnects. A similar message in a different deployment still needs to be interpreted in context. The incident is documented in this SRS issue report.
If SRS exits or restarts, investigate that event before changing YouTube’s endpoint. If it stays up but logs a publisher loss, look upstream at the encoder-to-SRS connection. If it records a downstream publish failure while the encoder remains connected, look towards the YouTube destination and outbound route. The MediaMTX service guide for an always-on YouTube channel describes another media-server context; the practical point here is to distinguish a running process from a healthy end-to-end stream.
Verify YouTube’s endpoint and RTMPS support
Use the server URL displayed in YouTube Live Control Room for the current stream rather than reusing an address from an old setup note. Confirm that the encoder or SRS publishing configuration points to the intended server and that the stream key corresponds to the active broadcast. A correct-looking key cannot compensate for a wrong endpoint, and a correct endpoint cannot compensate for an incorrect key. Treat stream keys as passwords: do not include them in public logs, screenshots or support posts.
If you intend to use RTMPS, verify the scheme and server shown by YouTube and confirm that the software in the publishing path supports RTMPS. The YouTube help page for streaming with RTMPS explains how to obtain the RTMPS URL and use it with an encoder. In a chain that uses SRS, check which component actually opens the connection to YouTube. The encoder may publish RTMP to SRS while SRS makes the downstream connection, so the RTMPS capability and configuration need to be checked on the relevant link, not assumed from the encoder’s settings alone.
Pay attention to the error type. YouTube’s RTMPS guidance says that for certain SSL certificate errors you should check that both the scheme and server are rtmps; it also suggests trying port 443 in that situation. For a connection timeout, check that the URL is correct and that the encoder supports RTMPS. These are targeted checks for the reported errors, not settings to apply indiscriminately to every interruption.
Change one item at a time and note the result. If an RTMP endpoint works but an RTMPS attempt times out, verify support and the exact URL before concluding the network is at fault. If both protocols fail at the same point, compare SRS’s logs and outbound connection evidence. Do not copy an endpoint from an unrelated tutorial simply because the format looks familiar; YouTube’s current Live Control Room details should be your reference.
Investigate the outbound connection
When the encoder’s local picture and sound are healthy but YouTube still loses the stream, examine the outgoing internet connection from the machine or environment that makes the SRS-to-YouTube connection. YouTube’s troubleshooting page says that a healthy-looking stream may point to an outbound internet connection issue. If its connection test identifies a problem, YouTube recommends contacting your internet provider. This test does not itself tell you which device, route or provider segment caused a drop, so retain the timestamp and compare it with your own logs.
Be precise about which connection you are testing. If OBS publishes to an SRS instance on another machine or network, the encoder’s local internet connection may not be the route used for SRS’s outbound YouTube publish. Check the egress path from the system running SRS, or ask the administrator who manages it. A speed test on the OBS computer may be informative in one setup and irrelevant in another.
A wired-versus-Wi-Fi comparison can help isolate whether the local wireless path is involved. If you can safely test Ethernet, compare the same stream and settings over the alternate path and record whether the symptom changes. This is a general troubleshooting inference, not an official YouTube guarantee or a cure. A different result points to a path worth investigating; no change does not rule out an upstream network issue.
Avoid reflexively lowering bitrate. A bitrate change may alter the amount of data sent, but it does not establish whether the encoder, SRS, endpoint or outbound route caused the original failure. First collect the encoder status, SRS event and connection evidence. If the stream is dropping because the available outbound capacity is unstable, a controlled bitrate test may be useful after you have documented the baseline. For symptoms that are specifically blocky motion rather than a disconnect, use the separate guide to bitrate and resolution choices for blocky YouTube video.
Confirm whether the stream recovers end to end
A reconnect message only confirms that one component attempted to reconnect. Verify what happened across the whole path: did the encoder resume publishing, did SRS accept the publisher again, did SRS resume its downstream connection, and did YouTube return to a live state? Then check playback from a viewer connection. The stages may recover at different times, and a successful reconnect in OBS does not by itself prove that YouTube resumed the same session or that viewers can play it.
After an interruption, write down the observed sequence rather than summarising it as “the stream came back”. For example: OBS reported a publishing disconnect, SRS stayed running, its log recorded a new publisher connection, and YouTube later showed an active stream. If you cannot verify one stage, mark it as unknown. This makes the next occurrence easier to compare and avoids treating an assumption as a fix.
Run only one controlled change at a time: endpoint, RTMPS setting, network path or encoder setting. Keep the previous configuration and note when you changed it. A test that lasts briefly without another drop is not proof that the fault is resolved, especially for an always-on channel whose interruptions may be intermittent. Continue to monitor the stages that showed evidence of failure.
For recurring incidents, gather the SRS version, deployment type, encoder name and version, exact error messages, timestamps, and whether affected viewers share a network. Include whether the local archive was clean and whether the SRS process restarted. That detail lets a maintainer distinguish an encoder issue from an SRS event or a downstream failure without asking you to repeat basic checks.
If a failed overnight setup is taking attention away from the channel itself, StreamNeo can remove the need to keep your own computer switched on for an uploaded-video broadcast. It does not change the fact that YouTube is the destination, nor does it make a particular network or platform session immune to interruptions.
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 does my YouTube stream keep disconnecting?
There is no single cause to assume from that symptom. Check whether the encoder output is healthy, whether SRS stays up and what its logs record, then verify the YouTube endpoint and the outbound connection used by the publishing system. The timing and error messages help identify which link to investigate.
Why does OBS keep disconnecting and reconnecting to YouTube?
OBS may be losing its connection to SRS or to YouTube, depending on how you publish. Compare its exact reconnect message with SRS logs and YouTube’s live status before changing bitrate or transport. A reconnect attempt does not guarantee that the downstream YouTube stream has recovered.
Should I switch to RTMPS or port 443?
Use the RTMPS URL shown by YouTube and confirm that the component making the outbound connection supports it. YouTube recommends checking port 443 for certain SSL errors, and checking the URL and RTMPS support when a connection times out. Those checks address specific error conditions; they are not a universal disconnect fix.
What information should I provide when asking for SRS help?
Share the SRS version and deployment type, encoder and version, relevant log lines with timestamps, and the exact error text. Say whether the local output remained healthy and whether reports came from one viewer, a shared network or different networks. Remove stream keys and other secrets before posting.