If OBS keeps disconnecting and reconnecting on Ubuntu, treat the reconnect as a symptom, not a diagnosis. Compare OBS’s log, Ubuntu’s system records and YouTube’s stream health at the same time before changing settings.
Repeated reconnects can reflect an unstable outbound connection, a bitrate the connection cannot sustain, an encoder or configuration issue, or a problem reaching the ingest endpoint. The word RTMP in the error does not by itself prove that RTMP is defective. This guide works from the evidence towards a test, one change at a time.
Establish the pattern and timing
First note when the failure happens and what “reconnecting” means in your setup. Does OBS fail immediately when you click Start Streaming, or does it connect successfully and drop later? Does the stream recover by itself, or do you have to stop and start it? A failure at startup and a connection that runs for a while before dropping point to different places to investigate, but neither identifies a cause on its own.
Write down the local time and timezone when each interruption occurs. If the stream has dropped several times, note the interval between them and whether the timing changes. A failure that coincides with a Wi-Fi handover, a scheduled computer sleep, a router restart or a VPN reconnect gives you a useful lead to test; it is still worth checking the logs rather than treating a coincidence as proof.
Keep a short record of what viewers reported, if anything, and whether your local OBS preview continued normally. A viewer seeing a freeze while OBS remains connected is different evidence from OBS itself reporting a dropped connection. For help separating a source-side issue from playback trouble, see the guide to encoder-side and viewer-side buffering.
Avoid changing several things at once. If you lower the bitrate, switch from Wi-Fi to Ethernet and change the ingest server in one go, a successful stream will not tell you which change mattered. Record the original values, make one reversible test, and observe the next comparable session.
Compare OBS status with YouTube stream health
While the stream is live, check OBS’s connection status and dropped-frame information, then open the stream in YouTube Live Control Room and look at the health messages for the same period. YouTube’s live-stream troubleshooting guidance covers both encoder health and outbound internet connectivity. The stream health status reference describes messages that can flag incoming video, bitrate, codec, frame rate, keyframes or backup-stream configuration.
The timing and combination matter more than a single status label. If OBS reports dropped frames before the reconnect, investigate the path from your computer to YouTube and whether the configured bitrate is sustainable. If OBS appears connected but YouTube reports insufficient incoming video, examine the encoder output and the full OBS log. If YouTube flags a codec or keyframe issue, follow that specific message rather than making unrelated network changes.
A stream can have a local problem, a network problem and a YouTube-side health warning at different times. Do not infer that YouTube caused the reconnect simply because a health message appears, or that OBS is broken because its status changes. Save a screenshot or write down the exact message and timestamp so you can compare it with the log later.
For a pre-recorded channel, the source and output still need to remain healthy over time. The choices involved in running an always-on ambient channel with OBS or FFmpeg are discussed in this comparison for Indian creators; here, the immediate task is to determine which part of the current path is failing.
Find and read the OBS log on Ubuntu
OBS’s log for the affected session is usually the most direct record of what the encoder saw. In OBS, use Help → Log Files to open the current or previous log when available. This is preferable to guessing a path: the location can differ according to how OBS was installed, including packaged builds.
A commonly used configuration-based location on Linux is ~/.config/obs-studio/logs, but do not assume that every Ubuntu installation stores logs there. If the directory is absent or does not contain the relevant session, return to the in-app menu and check how your OBS package stores its data. Keep the log from the session in which the problem occurred, not only one from a later test that happened to work.
Read several lines before and after the failure time. Look for connection and send errors, a disconnect or reconnect, output stopping, dropped-frame counts, timeouts, or SSL/TLS messages. An OBS log may show that sending failed after a successful connection, or that the initial connection never completed. That distinction helps choose the next test, but an individual error string is not a complete diagnosis.
If the log shows a rising dropped-frame counter before reconnecting, start with the network branch below. If the first attempt fails with an SSL, certificate or timeout message, verify the endpoint and protocol as described later. If the log instead points to encoding, rendering or output trouble, test the encoder configuration. When asking for help in a public forum, remove or redact stream keys, tokens and other credentials first.
Inspect Ubuntu system records around the failure
Once you have an OBS timestamp, query Ubuntu’s journal for the same window. For a recent event, you can try:
journalctl --since "30 minutes ago" --no-pager
journalctl -k --since "30 minutes ago" --no-pager
The first command requests journal entries available to your user; the second narrows the output to kernel messages. To inspect an older incident, replace the relative time with a precise --since value, and, if useful, add an --until value for the end of the window. Ubuntu’s journalctl manual documents these query options. The precise output depends on your system and permissions.
Look around the event for a network interface going down or up, a driver reset, firmware errors, sleep or resume activity, or signs of system pressure. Compare each candidate event’s timestamp with OBS. A message in the same window may be relevant, but it does not automatically prove that it caused the stream to reconnect. In particular, there is no universal kernel message that diagnoses every OBS disconnect.
Ubuntu also documents /var/log/syslog as a general system log and /var/log/kern.log as a kernel log. These files may not be present or contain the same records on every Ubuntu release or configuration. If they exist, use less or a time-focused search to inspect the incident, but treat a missing or empty file as a reason to check the journal, not as evidence that nothing happened.
If no system event lines up with the reconnect, that is useful too: it makes a visible local link reset less likely, but cannot rule out loss elsewhere between your computer and YouTube. Keep the OBS log and YouTube health result in the comparison rather than concluding that the fault must be remote.
Test bitrate and outbound connectivity
OBS describes dropped frames as a sign that the connection to the ingest server is unstable or unable to sustain the configured bitrate; enough lost frames can lead to a disconnect. Its network troubleshooting guide recommends checking the connection and notes possible interference from Wi-Fi, VPNs and security software. That is a useful starting point, not proof that your internet provider or router is at fault.
If you are on Wi-Fi, run a comparable test over wired Ethernet if practical. Wi-Fi interference or a weak signal can vary with time, so a speed test taken at another moment is not a reliable measure of what the stream could sustain during a drop. Check whether other users or devices are uploading heavily at the same time, and whether the router or connection has general interruptions.
Test a lower video bitrate while leaving other settings unchanged. OBS gives a general rule of thumb to begin around 75% of total upload speed, but that is not a YouTube guarantee or a substitute for testing stable capacity. A brief peak result does not show that the connection can sustain a constant stream. YouTube’s stream settings advice likewise emphasises choosing quality that your connection can reliably deliver.
A lower bitrate can reduce dropped frames, but it may also reduce picture detail. If this change helps, increase cautiously only when you have repeatable evidence of stable headroom; do not tune to the best result from a single speed test. A dynamic bitrate option, where available in your OBS build, may lower quality to keep the connection going. It is a compromise rather than a repair for an unstable path.
For a controlled isolation test, temporarily disconnect a VPN or test whether security software is interfering, then restore your protections. Do not leave a firewall disabled as a permanent fix. Only consider a narrow exception for OBS if the evidence points to that software blocking the connection. You can also try another ingest server if OBS exposes one, or check for wider connectivity trouble before restarting your router. If the problem persists across local tests, contact your ISP with timestamps and the evidence you collected.
Check RTMPS and the endpoint only when the evidence points there
A reconnect does not establish an RTMP defect. Endpoint and protocol checks become more relevant when OBS fails immediately, reports an SSL or certificate error, or logs a timeout while establishing the connection. First copy the current server URL and stream key from YouTube Live Control Room rather than relying on a saved address that may be stale.
YouTube’s RTMPS instructions direct creators to use the RTMPS URL and identify port 443 as relevant to SSL errors. The YouTube ingestion protocol documentation specifies TLS and port 443 for RTMPS and explains that the server hostname is needed for SNI authentication. Confirm that your encoder supports the protocol and that the URL has not been altered or truncated.
Do not switch protocols, edit ports or copy an endpoint from an old setup just because the error mentions RTMP. Follow the current YouTube instructions and the exact message in OBS. A stale stream key can produce a separate start-up error; obtain the current key from the channel’s Live Control Room and enter it carefully. Treat credentials as private and never paste a complete key into a support post.
Test encoder configuration and recovery
YouTube’s health messages can point to source or encoder settings rather than network transport. If Control Room reports a codec, bitrate, frame-rate, resolution, keyframe or primary/backup mismatch, change only the setting that corresponds to that message and then check the next session. YouTube’s live encoder error guide describes common stream errors, including H.264 video and AAC audio for standard live ingestion. Verify the current guidance instead of treating a preset from an old tutorial as universal.
If OBS’s preview is poor, output stops locally, or logs indicate encoder overload, test a less demanding output configuration. Reduce a single load factor, such as resolution or frame rate, and observe whether the local output and YouTube health improve. A reconnect alone does not demonstrate that the CPU or GPU is overloaded; look for corroborating log or preview symptoms before changing encoder settings.
Recovery is separate from diagnosis. If the channel must resume after an interruption, decide what should happen when OBS loses its connection and who will notice if recovery fails. OBS may attempt to reconnect, but a computer that sleeps, loses power or stops running OBS cannot recover the broadcast by itself. For a local setup, disable unintended sleep, confirm the machine remains powered and connected, and test a planned restart while someone can observe the channel.
For a long-running stream, the machine and its network remain part of the operating plan. If overnight interruptions are the recurring concern, the practical checks in this guide to keeping a monsoon ambience stream running overnight can help you review power, connectivity and monitoring beyond the immediate log entry. If you need the stream to continue while your own computer is off, StreamNeo removes that specific dependency by taking an uploaded video and running it as a YouTube live stream, so a local Ubuntu session is not what keeps the broadcast going.
Before choosing an operating approach, decide whether you want to keep diagnosing a local OBS setup or remove the need to leave that computer running.
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 a reconnect prove that RTMP is broken?
No. Reconnects can follow dropped frames, an unstable outbound connection, an encoder issue or an endpoint configuration problem. Use OBS’s full log and YouTube’s health messages to decide which branch to test.
Where are OBS logs on Linux?
Use Help → Log Files in OBS to open the current or previous session log when available. ~/.config/obs-studio/logs is a common configuration-based location, but packaging can change where logs are stored, so verify through the application if that path is missing.
Should I lower the bitrate when OBS keeps reconnecting?
It is a reasonable controlled test if dropped frames rise before the reconnect or the connection may not sustain the current setting. Lower it without changing other variables, then compare OBS status and YouTube health; a lower bitrate can mean a softer picture and does not fix every network fault.
What if system logs show nothing at the reconnect time?
Check that you queried the right time window and timezone, and inspect the journal as well as any traditional log files available on your installation. No matching local event does not rule out a network interruption beyond Ubuntu, so compare the OBS log and YouTube health before drawing a conclusion.