To restart an Nginx RTMP YouTube stream after a crash, supervise the process that actually owns the outbound publishing connection. That may be an FFmpeg child launched by nginx-rtmp, a relay managed by the RTMP module, or a standalone FFmpeg process; restarting a different layer will not recover it.
A restart can relaunch an exited process, but it cannot restore a dead source, correct a bad key or route, or make invalid encoder output compatible. First locate the publisher, then check each part of the path after it comes back.
Find the process publishing to YouTube
Start with the outbound connection, not the word “Nginx” in your setup notes. An Nginx RTMP server may receive a stream from a camera or encoder and then relay it to YouTube. Alternatively, an exec directive may launch FFmpeg, which publishes directly. In another arrangement, FFmpeg may run independently and Nginx may not own the YouTube connection at all.
Trace the flow from source to destination: source or file, local ingest, any relay, publisher process, then YouTube. Identify which process opens the final connection to YouTube and which configuration starts it. On a Linux host, process listings and command-line arguments can help identify whether FFmpeg is a child of Nginx or a separately managed process. Treat logs and process details as sensitive: avoid copying stream keys into tickets, screenshots or shared chat.
Look at what happens when the stream fails. Does an FFmpeg process exit? Does it remain alive while its output connection times out? Does Nginx log a failed push while its own process continues? Note the process ID, timestamps, exit status where available, and the relevant Nginx and FFmpeg messages. A supervisor that reacts to process exit does not necessarily detect a process that is still running but stuck.
This distinction also explains a common question: “Does restarting Nginx restart the RTMP push?” It only helps if Nginx owns the failed relay or child lifecycle in question. Restarting Nginx is not automatically the same as restarting a separately launched FFmpeg publisher. If you are building a file-based channel rather than maintaining a camera relay, compare the process choices in this guide to automating a YouTube podcast livestream with OBS or FFmpeg.
Put recovery at the owning layer
Once you know the owner, choose recovery there. If nginx-rtmp starts FFmpeg with an exec directive, inspect that module’s child-process and respawn options for the exact fork and version installed. The nginx-rtmp-module project documentation describes its directives, but deployments can differ; verify that the options you plan to use exist and mean what you expect in your build.
If FFmpeg runs independently, use the host’s service manager to supervise that service. Keep the FFmpeg command and its configuration with the service definition so it is clear what is being restarted. Decide which failures warrant a restart and how a retry delay should behave. A permanent error such as an invalid input path or rejected destination can cause repeated failures; automatic retries do not turn it into a transient error.
If the Nginx RTMP module itself owns a push relay, investigate that relay’s documented behavior and logs. Do not assume that this also supervises a separate FFmpeg process. For example, a relay may be configured to forward an incoming stream to YouTube, while an independent FFmpeg process creates the incoming stream; there are two owners and potentially two separate failure points.
| Recovery placement | Appropriate when | What it does not establish |
|---|---|---|
| nginx-rtmp child respawn | nginx-rtmp launches the external publisher | That the source is alive or the child can connect successfully |
| Host service manager | FFmpeg is a separately managed service | That a failed command, route or key will become valid after retrying |
RTMP push relay behavior |
The module owns the outbound relay | That an independent publisher is supervised or upstream media is available |
Pick one clear owner for each publishing process and avoid layering multiple restart policies without understanding how they interact. Two supervisors can obscure which one is launching a process, create duplicate publishers, or make logs harder to interpret. The right arrangement is the one that matches the actual process tree and gives you a useful record of each attempt.
For a channel based on a fixed video file, process recovery is only one part of continuous operation. A file ending, playlist transition or invalid segment can interrupt output even if the publisher remains healthy. See how switching prerecorded videos without interrupting a YouTube stream handles the content-transition side of the problem.
Configure respawn or service restart behaviour
For an nginx-rtmp-managed child, check the installed module’s exec directive documentation rather than pasting a configuration from an unrelated fork. Confirm whether the configured child is launched for the relevant stream event, what conditions trigger respawn, and how the module handles repeated exits. The setting names and behaviour are version-specific; a respawn option is a child lifecycle policy, not a guarantee that an end-to-end stream is healthy.
For a standalone FFmpeg process, configure its service manager to restart it after the failures you want to recover from, with a deliberate delay and access to logs. The exact unit syntax and restart policy depend on the operating system, service-manager release and command. Make sure an operator can distinguish a fresh restart from a process that never exited, and can find the output and error logs without exposing the stream key.
Before applying an Nginx configuration change, use the configuration test appropriate to your installation. NGINX documents nginx -t as a way to test configuration syntax; the NGINX RTMP dynamic module documentation is specifically for NGINX Plus and should not be treated as an installation guide for every open-source package. Follow the documentation for your own package and module, then reload only after a successful check.
Plan what happens if the underlying problem persists. A short retry delay can make logs and connection attempts difficult to follow, while a long delay leaves a stream offline longer after a transient failure. No universal delay fits every host and failure mode. Choose a policy you can observe and adjust, and do not treat a continually restarting process as evidence that recovery is working.
Test the recovery path on a non-critical stream if you can. First observe a normal start. Then deliberately stop the child or service in a controlled way and confirm that the intended supervisor relaunches it, that the process reconnects, and that useful logs are produced. This is a verification procedure to carry out in your own environment, not a claim that a particular setup has been tested here. For ways to arrange a longer-running channel from a single machine, the Streamlabs Desktop setup guide covers a different publishing approach.
Check that the source is still producing media
A publisher restart only helps if it has something valid to publish. Check the input independently: is the camera powered and reachable, is the capture device still delivering frames, is a local relay receiving data, or does the file path still exist and contain readable media? For a playlist, confirm that the current item and next item can be opened. A restarted FFmpeg process pointed at an unavailable device or missing file can exit again or remain connected without useful media.
Separate source failure from publishing failure by checking each boundary. If the source is local, inspect its own application or capture logs. If Nginx receives an upstream stream, verify that the incoming stream is present before testing the outbound push. If the source is a file, check that the process can read it under the account used by the service, not just under your interactive login.
A useful recovery log records when the publisher started, which input it attempted to open, and whether media was read. It should not include the full stream key. If the source process is itself supervised, identify its owner too; restarting the YouTube publisher will not restart a separate capture program that has stopped.
For a prerecorded devotional stream, a file can be readable yet still stop at its end or fail when a playlist advances. Check that the intended loop or playlist behaviour is configured in the process that reads the media. The guide to streaming aarti and bhajans around the clock can help with the content side of a continuous channel, but the source and publisher still need separate checks.
Verify the stream key, endpoint and route
Copy the current server URL and stream key from YouTube Live Control Room, then compare them with the publisher’s configuration. Check the protocol, hostname, path and port as separate values. YouTube recommends RTMPS; its encoder guidance describes supported connection and encoding requirements. Google’s RTMPS ingestion documentation explains that RTMPS carries RTMP over a secure SSL connection and documents the ingestion details for API-based workflows.
The endpoint and key are specific to the stream or account configuration. Do not substitute a remembered URL or copy a key from an old setup without checking the current Live Control Room details. Google’s documentation for RTMPS ingestion identifies port 443; a connection timeout can point to a wrong protocol, endpoint, port, network route or encoder support. Check the error before increasing retries. Repeating an attempt against a wrong destination simply repeats the failure.
Keep credentials out of the public parts of your configuration and troubleshooting notes. A screenshot of an FFmpeg command or service definition can disclose the key even when the rest of the setup looks harmless. If you need to share logs, redact the key and any other private values first. Rotate a key through the appropriate YouTube controls if it has been exposed, then update the publisher’s stored value.
If a relay sits between FFmpeg and YouTube, check both legs. Confirm that the publisher is sending to the intended local Nginx application and that the relay’s outbound destination is the current YouTube endpoint. A healthy local connection does not prove that the relay can reach YouTube. Likewise, a connection from Nginx to YouTube does not prove that it is receiving valid media from the upstream publisher.
Validate encoder output after recovery
A process can restart and establish a connection while still sending output YouTube cannot use. Check the encoder’s input and output logs, then inspect stream health in Live Control Room. Treat connection status and valid media as separate checks: one does not confirm the other.
Compare the output with YouTube’s current encoder guidance rather than relying on an old command copied from another channel. The cited YouTube encoder settings page lists RTMP or RTMPS and H.264, H.265 or AV1 video, supports frame rates up to 60 fps, and recommends a two-second keyframe interval that should not exceed four seconds. These are published guidance values, not a promise that every combination is appropriate for your source or account. Check the current official page when choosing or changing settings.
After restart, confirm that the output actually includes the expected audio and video, at the intended resolution and frame rate, and that keyframes are being produced as expected. If the source is audio-only, verify the video treatment you have configured rather than assuming the encoder will supply a suitable picture. If you changed the encoder command while troubleshooting, compare the exact effective command with the known-good version and inspect errors for unsupported codecs or malformed options.
Keep the layers distinct in your notes: process state, source availability, route and authentication, then media format and health. That makes the next incident faster to diagnose. If a stream connects but Live Control Room reports a problem, do not keep restarting blindly; use the health details and encoder logs to identify whether the fault is in the media, connection or configuration.
Make the recovery arrangement observable
Automatic recovery is useful only when you can tell whether it happened and what happened next. Record the process start time, exit or restart reason where available, connection result and source-open result. Keep logs in a place that survives a process restart, with retention appropriate to the host. Redact credentials before sharing any excerpts.
Create a short incident checklist for the person on duty: identify the publisher, check whether it exited or is stuck, confirm source availability, verify the endpoint and key privately, inspect encoder output, and check Live Control Room health. This prevents a restart command from becoming the only response to every interruption.
If maintaining the host and its process supervisors is the pain point, StreamNeo removes the need to keep your own computer running: you upload a video and provide your YouTube stream key, while the broadcast can be monitored and restarted if it drops. It is YouTube-only, and it does not change the need to have a suitable file, correct channel details and valid output.
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
How do I automatically restart FFmpeg if it crashes?
If FFmpeg is launched by nginx-rtmp, check the installed module’s child respawn options. If it is a standalone process, configure the host’s service manager to restart that service on the failures you intend to recover from. Then verify a controlled restart and confirm that the source, route and output are healthy.
Why does my YouTube stream not reconnect after Nginx restarts?
Nginx may not own the process that publishes to YouTube. Trace whether the outbound connection belongs to an exec child, an Nginx push relay or separate FFmpeg service, and supervise the owner. Also check whether the process exited, whether the source is available, and whether the endpoint and key are current.
Does restarting Nginx restart the RTMP push?
It can affect a relay owned by the Nginx RTMP module, but it does not automatically restart an independent FFmpeg process. Identify which process owns each connection and check the relevant logs after any restart. A restarted relay still needs a working upstream source and valid YouTube destination.
Will a restart loop fix a bad key or unsupported output?
No. A restart loop relaunches a process; it does not correct credentials, repair the route, restore a dead source or make incompatible encoder output valid. Check the private key and endpoint against Live Control Room and compare media output with YouTube’s current official guidance.