A stream that drops after a few hours does not, by itself, identify a timeout or a faulty component. To find the cause, establish which connection fails first: your encoder to NGINX, NGINX’s push to YouTube, or YouTube’s ingest session.
Compare timestamped logs from both ends of each leg with YouTube Live Control Room’s stream-health messages. Then make a change that matches the evidence. NGINX’s HTTP keepalive_timeout is not a fix for an RTMP publishing session.
Identify the first failing connection
Start by drawing the actual path your video takes. There are two common arrangements: an encoder publishes directly to YouTube, or the encoder publishes to an NGINX RTMP application and NGINX pushes the stream onward to YouTube. A third arrangement may include a managed relay or another proxy, so write down every hop rather than assuming the diagram.
Record the encoder and NGINX versions, the nginx-rtmp-module version if applicable, the destination host and application, and which machine initiates each connection. Do not put a stream key in a shared document, screenshot or support ticket. If you need to show a URL, redact the key and any other credential.
The important question is not merely whether the stream is down. It is which event happens first. If NGINX continues receiving the encoder’s publish while the YouTube-facing push reports a disconnect, investigate the relay-to-ingest leg. If the encoder reports a send failure or stops publishing to NGINX first, begin with the encoder-to-relay leg and its network path. If both legs appear active but YouTube reports no incoming data, examine the destination and ingest session as well as the timing and meaning of the health message.
These are ways to organise evidence, not conclusions about your setup. A log line recorded after a drop may describe a consequence rather than the initiating failure. Keep local clocks synchronised where possible, and note any clock offset between the encoder, relay host and YouTube status display. A difference of a few minutes can make an otherwise useful comparison misleading.
Also distinguish a stream ending cleanly from a connection disappearing. A planned encoder stop, a process restart, an expired credential, a host reboot or a network interruption may leave different traces. Write down the observed symptom and exact time, including whether the picture froze, the live event ended, or the encoder began a new publishing session.
Correlate encoder and NGINX logs
Collect logs before changing settings. At minimum, keep the encoder’s streaming log, NGINX’s RTMP error log, service-manager or system logs for the relay, and any available connection or network events covering the period around the interruption. Preserve a period before and after the event: the last successful publish, the first warning, the disconnect, and any reconnect attempt all matter.
Create a short timeline with one row per event. Include timestamp and time zone, component, message, and what the component was doing. For example, an encoder may report that it is still sending to the local NGINX application while the RTMP module reports a failed outgoing push. That pattern narrows attention to the second leg, but does not yet tell you whether the cause is a route interruption, destination issue, module behaviour or something else.
If the encoder log shows its publish ending first, check whether the process exited, the encoder deliberately stopped, or its connection to NGINX failed. Look for a restart, dropped interface, authentication response, or local resource warning at the same time. If the NGINX process itself restarted, the RTMP session will have been interrupted regardless of the YouTube ingest state.
Do not treat every message containing “timeout” as the answer. Different layers use the word for different events. An RTMP ping or session timeout, a socket-level TCP keepalive probe, an HTTP client keep-alive timeout, and a relay push reconnect setting are not interchangeable controls. Identify the subsystem that emitted the message and the connection it describes before considering a configuration change.
For repeatable tests, retain the same log sources and note one configuration change at a time. A useful record includes the start time, the observed first failing leg, the exact setting changed, and whether the later run stayed connected for a comparable period. A single uninterrupted run is evidence about that run, not proof that a particular setting universally prevents future drops.
Check YouTube Live stream health
Open the event in YouTube Live Control Room and compare its stream-health status and messages with the encoder and relay timeline. Health messages can help distinguish missing incoming data from a stream with incoming data but a quality or configuration issue. Record the message and when it appeared; do not paraphrase “health was poor” without preserving the actual wording.
If YouTube says it is not receiving data, check whether the encoder or relay was still sending at that moment. If it reports a quality concern while data continues, that is a different problem from a disconnected publishing session. A dashboard status may lag the underlying event, so use it alongside local timestamps rather than as the only clock or diagnostic source.
Confirm that the stream is being sent to the intended event and ingest destination, and that the correct key is in use, without copying the key into notes. An event can be healthy at one destination while a relay attempts to publish somewhere else. If you rotate a key as part of a controlled check, update the intended publisher and document the change; avoid exposing the new key in logs that will be shared.
YouTube’s stream-health guidance and encoder settings are useful for validating the outgoing stream, but a recommendation is not evidence that a multi-hour interruption was caused by an encoder setting. Likewise, a health warning may point to an issue worth correcting without explaining why the session ended. Keep diagnosis and quality tuning as related but distinct tasks.
Inspect relay push reconnection settings
This section applies only if NGINX is receiving a stream and publishing a separate push to YouTube. First confirm that the installed build actually includes the nginx-rtmp-module you are configuring. Note its version or package source, and check the configuration syntax and module documentation that correspond to that build. Instructions for one fork or release may not apply to another.
Inspect the RTMP application context in which the source publishes and the relay push is defined. Verify that the destination is correct and that any reconnect directive is supported by the installed module and placed in a context that affects this push. Do not paste a directive from an issue thread without checking the current implementation and testing its behaviour. The module’s directive reference and its discussion of push reconnect behaviour provide context, not a guarantee that the same configuration applies to your build.
Reconnect behaviour has trade-offs. A relay that retries may recover after a transient interruption, but retries do not repair a wrong destination, invalid key, persistent route failure or a source that has stopped publishing. Reconnection may also create a new session or require you to verify what YouTube displays for the event. Observe what happens after a controlled interruption in a test event before relying on that behaviour for a public broadcast.
Keep HTTP and RTMP settings separate. NGINX documents keepalive_timeout as an HTTP client keep-alive setting. It governs HTTP connections handled by the HTTP module, not an RTMP publisher’s session to an application or an RTMP push toward YouTube. Changing it is therefore not a reasoned fix for an RTMP publishing drop.
TCP keepalive at the socket or stream-proxy layer is different again: it uses probes to detect whether a TCP peer appears reachable. RTMP-level pings and session timeouts concern RTMP behaviour, while a push reconnect setting concerns what the relay does after an outgoing publishing failure. A probe may help identify a dead connection, but it does not itself guarantee that the RTMP push is re-established. Choose a control only after the failing connection and the relevant module behaviour are known.
If your arrangement is a VPS relay, capacity and route quality are worth checking only when evidence supports them. Compare sustained upload capacity, network stability, CPU and memory headroom under the actual workload, route to the selected ingest, log visibility and recovery behaviour. The symptom alone does not show that the host is undersized or that buying a different one will help. The VPS setup guide for YouTube Live in India may help you review the relay arrangement, but it cannot identify the cause in your logs.
Verify encoder output recommendations
Once the session path is understood, verify that the encoder is producing a stream YouTube can ingest as expected. YouTube’s current encoder recommendations cover protocol, bitrate mode, resolution and keyframes. The guidance recommends a two-second keyframe frequency and says it should not exceed four seconds. Treat these as YouTube’s recommendations, not a promise that changing them will prevent a disconnect.
Where supported by your encoder and workflow, check YouTube’s recommendation to use RTMPS rather than plain RTMP. Confirm that the encoder or relay destination supports the secure endpoint you select; changing protocol at one leg does not automatically change the other. If NGINX receives RTMP locally and pushes to YouTube, verify the protocol and destination used by the outgoing push separately from the encoder’s input connection.
Review whether output is constant bitrate (CBR) as recommended, and whether the configured bitrate fits the content and available upload path. A high-motion devotional video or local news loop may behave differently from a static lofi image, but do not infer a bitrate from the category alone. Use the encoder’s actual output and YouTube’s current guidance, then compare stream-health messages during a representative test.
For a recurring programme, test with the same audio, motion, resolution and schedule pattern that normally runs overnight. A short test with a static image may not represent a playlist with frequent scene changes or high-motion footage. You can also review how a playlist behaves in a continuous YouTube Live stream if changes in playback or file transitions coincide with the interruption.
If output settings are already within the current recommendations and logs show the relay’s outbound connection disappearing, repeated encoder tweaks are unlikely to answer the immediate question. Preserve the working configuration, change only a setting linked to evidence, and keep a note of the old value so you can revert a test that makes the stream worse.
Test the route and ingest session
A route test should be tied to the failing leg. If the encoder-to-NGINX publish fails, check the encoder host’s route to the relay, local firewall rules and whether the RTMP application remains reachable. If the NGINX-to-YouTube push fails while input remains live, check the relay host’s outbound connectivity and the destination selected for the push. A generic speed test from a different device or time may not represent either connection.
During a planned test, capture connection events and resource use on the host, along with the same encoder and RTMP logs used for the original failure. Confirm that the relay has enough upload headroom for the configured stream and any other traffic. If evidence points to resource pressure, investigate the process and host metrics at the relevant time; do not assume CPU or memory exhaustion merely because the stream ran for hours before dropping.
Test the ingest session with a controlled event or private workflow where practical. Verify that the encoder starts the intended event, that the stream-health panel receives data, and that stopping or interrupting one leg produces the expected logs and recovery behaviour. Avoid deliberately disrupting a public devotional, news or business channel during its normal audience hours. A planned maintenance window or test event gives you a safer way to learn whether a retry creates a fresh session and whether the event remains usable.
If you need to change the route, protocol, key or module configuration, change one item, record it, and run a representative extended test. “Extended” should mean long enough to cover the period in which your own stream has previously failed, not an arbitrary universal duration. Compare the new timeline with the original: which leg failed first, what did YouTube report, and did the chosen setting alter that sequence?
If the stream is a prerecorded loop rather than a live encoder output, distinguish the playback mechanism from the publishing connection. A playlist can continue locally while its publishing process loses connectivity. The article on keeping sleep-sounds streams running from a spare PC offers a different operating approach, but whatever approach you use, the point remains to observe the connection that actually failed.
After a confirmed disconnect, a person may need to investigate and restart the chain. For channels where the recurring burden is keeping a computer or relay process running and recovering after a drop, StreamNeo can remove that particular operating task: you upload a video and provide the YouTube stream key, then the broadcast runs with your computer off and is monitored and restarted if it drops. It is YouTube-only, so it is not a replacement for an NGINX workflow whose purpose is broader routing or a custom live contribution chain.
Keep a useful incident record
A small incident record prevents the next troubleshooting attempt from starting over. Keep the topology, software and module versions, relevant redacted configuration, and a concise event timeline. Store credentials separately and redact keys before sharing any log or configuration. Note whether timestamps are local time or UTC, and avoid altering source logs while collecting evidence.
Use a comparison table such as this one after each test. The rows are observations to fill in, not assumed causes.
| Test record | What to note |
|---|---|
| Start and disconnect times | Timestamp and time zone for the test and interruption |
| First failing leg | Encoder to NGINX, NGINX to YouTube, or not yet established |
| Encoder evidence | Publish state, error message, process restart or no change |
| NGINX evidence | Incoming publish state, outgoing push state, relevant error message |
| YouTube evidence | Stream-health message and when it appeared |
| Change made | One exact configuration or route change, with previous value retained privately |
| Outcome | Whether the same failure recurred and what evidence differed |
A useful “no change” result is still informative when the test is comparable and logs are complete. If the first failing leg remains unknown, improve timestamp alignment or collect the missing log source before trying another setting. If the result changes, check whether the change actually affected the relevant connection rather than crediting the first edit automatically.
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 keepalive_timeout fix an NGINX RTMP disconnect?
No. NGINX’s HTTP keepalive_timeout applies to HTTP client keep-alive connections, not RTMP publishing sessions. Identify the failing RTMP leg and inspect its relevant session, socket or reconnect behaviour instead.
What should I check first when the stream drops after a few hours?
Compare timestamped encoder and NGINX logs with YouTube Live Control Room’s stream-health messages. First establish whether the encoder-to-relay connection, relay-to-YouTube push or ingest session changed state first; the symptom alone cannot determine the cause.
Should I add a push reconnect directive to NGINX?
Only if NGINX is making the outgoing push, and only after confirming the installed nginx-rtmp-module supports the directive in the context where you plan to use it. Check the version-specific documentation and test recovery in a controlled event; an arbitrary setting is not a universal fix.
Will YouTube’s recommended encoder settings stop the disconnect?
They are useful checks, not a guarantee. Validate protocol, CBR and keyframe frequency against YouTube’s current guidance, then use logs and stream-health evidence to diagnose why a session ended.