A basic NGINX RTMP relay receives a stream from your encoder on an Ubuntu machine, then forwards it to YouTube Live. Your encoder connects to the relay’s local RTMP address; the YouTube RTMPS address and stream key belong in NGINX’s outbound configuration, not in the encoder’s destination field.
The RTMP module is third-party software, so a standard Ubuntu NGINX package may not include the directives this guide uses. The practical Open Source route is to build NGINX with the community module, test the configuration, and then send a private test stream before relying on the relay. HLS, recording, playback, and transcoding are not needed for this basic path.
How the relay flow works
Think of the setup as two separate connections. First, OBS, FFmpeg, or another encoder publishes to an RTMP application on your Ubuntu host. Second, NGINX forwards that incoming feed to YouTube’s current RTMPS ingest address using the stream key for the intended broadcast.
Encoder ── RTMP publish ──> Ubuntu NGINX relay ── RTMPS push ──> YouTube Live
The local URL commonly has this shape: rtmp://relay-host/live/stream-name. In that example, live is the application name, which must match an application live {} block in your NGINX configuration. The final path component is the stream name. The module README documents the general rtmp://host/app[/name] format and explains the relationship between a URL’s application component and its configuration block (nginx-rtmp-module README).
The YouTube destination is different. You obtain the RTMPS URL and key from YouTube Live Control Room for the stream you are preparing. NGINX uses both when forwarding; your encoder should not publish directly to YouTube in this relay design. YouTube explains that RTMPS is RTMP over a TLS/SSL connection in its guide to encrypting a stream using RTMPS.
A relay does not automatically improve an unstable source connection or repair a bad encoder output. It adds another machine and network leg, which can be useful when you need a public relay endpoint or want the encoder separated from the outbound YouTube connection. But it also introduces another configuration and another place to inspect when a stream fails. For encoder-side questions, the FFmpeg interruptions guide for streams hosted in India discusses symptoms that can originate before a relay ever receives the feed.
Choose the Open Source build route
The community nginx-rtmp-module is not the same thing as an official Ubuntu package guaranteed to be present in every NGINX installation. The module project describes building it alongside NGINX source. NGINX’s own Open Source documentation describes third-party modules as either statically linked with --add-module=<PATH> or, where supported, built dynamically with --add-dynamic-module=<PATH> (NGINX Open Source installation and module guidance).
For a first relay, use one intentional build path. A source build that includes the community module is straightforward to reason about because the NGINX binary and module come from a matching build. A dynamic module can be convenient if you already manage NGINX modules that way, but the module must be compatible with the NGINX version and build options, and the resulting configuration must load it correctly. Do not assume a binary from one repository can use a module compiled against unrelated source.
There is also a commercial route, but it is distinct: NGINX documents nginx-plus-module-rtmp in the context of NGINX Plus packages. That is not a generic substitute for the Open Source module build. If your organisation already runs NGINX Plus, check the official package instructions and licensing context; if not, do not follow a Plus-only package recipe as though it applied to ordinary Ubuntu NGINX.
| Route | What you need to match | When it makes sense |
|---|---|---|
| Open Source, static module | NGINX source and module source in the same build | A self-managed relay where you can maintain the NGINX build |
| Open Source, dynamic module | Module compatibility, build options, and a correct load_module directive |
An existing module-management workflow that supports dynamic modules |
| NGINX Plus module package | An NGINX Plus installation and its official package path | An operator already using the commercial product |
This guide gives the Open Source source-build direction rather than a release-pinned apt recipe. The research basis does not establish a tested package matrix for every currently supported Ubuntu release, and module packaging changes over time. Before building, record your Ubuntu release, the NGINX version you intend to run, and the module revision or release you choose. Avoid copying old version numbers from an undated tutorial.
Install NGINX and the RTMP module
Start on an Ubuntu host you can administer. It may be an existing machine or an Ubuntu server reachable by your encoder and able to make outbound connections to YouTube. If the host is behind a firewall or cloud network policy, you will need to permit the encoder’s incoming connection to the RTMP listener while allowing the host to make the outbound YouTube connection. Restrict who can reach the publishing port where practical; a relay endpoint should not be an open publishing point for unknown clients.
The module project’s build guidance names common build prerequisites such as a compiler toolchain, PCRE development files, SSL development files, Git, and zlib development files. Package names and versions should be checked against your chosen Ubuntu release before installation. The project’s getting-started material is dated, so treat it as historical context rather than a current, release-specific recipe. Likewise, choose matching NGINX source and module source rather than assuming the latest branch and an arbitrary installed binary will work together.
The overall build sequence is: obtain the NGINX source version you have selected, obtain the nginx-rtmp-module source, configure the NGINX build with the module path, compile, and install according to the chosen build plan. The module README’s documented pattern is to run NGINX’s ./configure with --add-module=/path/to/nginx-rtmp-module, then run make and make install. Use the actual local source directory in place of the placeholder. If following the dynamic route instead, use the NGINX-supported dynamic-module option only if the module and your build plan support it, and arrange for the installed NGINX configuration to load the resulting module.
Do not casually overwrite a working system NGINX installation. Decide whether this relay will be maintained as a source-built NGINX, how updates will be handled, and where its configuration and logs will live. If you already have a production web server on the same host, inspect its existing NGINX configuration and ports before introducing a second build or listener. A separate Ubuntu host can reduce collisions, but it also adds a machine to maintain.
After installation, confirm which NGINX binary will run and which configuration file it reads. This sounds mundane, but it catches a common failure: editing one configuration while a different service instance starts. NGINX’s -t option tests configuration syntax; use the binary and configuration path that match your deployment. Do not reload or restart until the test succeeds.
Configure a minimal RTMP application
A basic relay needs an RTMP listener and an application block. The application name in the encoder URL must match the block name exactly. The following is a structural example for the RTMP portion of an NGINX configuration; it does not include HLS, recording, transcoding, or playback features.
rtmp {
server {
listen 1935;
chunk_size 4096;
application live {
live on;
record off;
push rtmps://YOUTUBE_INGEST_URL/YOUTUBE_STREAM_KEY;
}
}
}
Treat the push line as a placeholder example, not as a universal YouTube URL. You must copy the current RTMPS ingest URL and the stream key from the relevant stream’s Live Control Room settings. The exact placement of the key depends on the RTMPS URL YouTube provides; do not append a key to an endpoint by guesswork. If you prefer to keep secrets out of the main configuration file, use an access-controlled include file or another private configuration mechanism supported by your deployment. Never commit a real key to a public repository, paste it into a public support post, or leave it in shell history.
Some module examples show a push directive inside an application, so each publisher to that application is forwarded to the configured destination. Your first test should have one intended publishing source and one intended YouTube stream. If you later add multiple applications or different destinations, give each a clear configuration boundary and verify which incoming application triggers which push.
The record off; line makes the intent explicit, but recording is not a relay requirement; it is simply not enabled here. HLS and DASH are also not required to forward RTMP to YouTube. Avoid copying a large sample configuration full of features you do not need: every extra directive is another behaviour to understand and maintain.
After editing, run the NGINX configuration test. If it reports an unknown rtmp directive, the running NGINX binary does not have the module available or a dynamic module was not loaded. If it reports a syntax issue, fix that before restart. A successful syntax test does not prove that the network path or YouTube credentials are right; it only removes configuration parsing as the first failure point.
Set the encoder’s local destination
In OBS, choose the custom server or custom RTMP service option and enter the Ubuntu relay’s address as the server. If the server is 203.0.113.20 and your application is named live, the shape is rtmp://203.0.113.20/live. Put a simple stream name such as main in the stream key or stream name field, producing the full publish path rtmp://203.0.113.20/live/main. The example address is reserved for documentation and will not reach your host.
With FFmpeg, the output URL uses the same local publishing shape. For example, an input file could be sent to rtmp://relay-host/live/main, with the appropriate video and audio encoding options chosen for your source. The point here is the destination: FFmpeg sends to your Ubuntu relay, not to the YouTube address in this topology. If you are adapting a NAS-based workflow, the Synology NAS FFmpeg guide provides a different arrangement; make sure you do not accidentally keep its direct-to-platform destination when inserting a relay.
The listener port shown in the structural example is conventional for RTMP, but the important requirement is that your encoder can reach the port configured in NGINX. If the encoder is on the same machine, a loopback address may be appropriate. Across a network, use the Ubuntu host’s reachable private or public address as appropriate, and configure host firewall and network rules deliberately. Do not expose a publishing listener to the public internet without deciding who is permitted to publish.
The encoder’s stream name is not the YouTube stream key in this example. It is the name NGINX receives under the live application; the outbound push configuration supplies YouTube’s separate destination and key. Keeping those values separate is useful both for security and diagnosis. If the encoder cannot connect, inspect its local URL, the application name, listener port, firewall, and NGINX log before changing YouTube settings.
Configure the YouTube push destination
Open YouTube Live Control Room and select the stream you intend to test. In the stream settings, reveal and copy the current stream URL or RTMPS URL and the stream key associated with that stream. YouTube’s instructions for secure streaming describe how to reveal the RTMPS details and explain the encrypted protocol. Use the values from the current Control Room rather than a URL copied from an old guide, another channel, or a previous event.
RTMPS is the outbound leg from your Ubuntu relay to YouTube. It is distinct from the local RTMP connection between your encoder and NGINX. The word “secure” here describes encryption in transit; it does not make a leaked stream key harmless. Anyone with a valid key may be able to send to the associated stream, so store it privately and rotate it through YouTube’s controls if you believe it has been exposed.
YouTube’s troubleshooting guidance advises checking that the protocol is rtmps when dealing with SSL errors; it also notes that trying port 443 may help in some cases. This is troubleshooting advice, not a guarantee that changing ports will resolve every network or certificate problem. First copy the exact current endpoint, then check whether your host’s egress policy permits the required connection. Do not replace the endpoint with a hard-coded tutorial value.
Some operators prefer to avoid placing the key directly in a broadly readable main NGINX configuration. Keep any file containing the key accessible only to the account and administrators who need it, and exclude it from source control and public backups. If the module syntax requires a push URL in configuration, use a private include or deployment secret-handling method and verify the resulting effective configuration without printing the secret into shared logs or screenshots.
For a one-channel relay, a single application and one push target are easier to audit than a general-purpose relay. If you need more than one YouTube output, confirm the module’s push behaviour and each target separately, and consider whether separate application blocks would make the mapping clearer. The goal is not to make the configuration clever; it is to know which input is forwarded to which stream.
Test the relay and check stream health
Test in stages rather than changing both legs at once. First validate configuration syntax with nginx -t using the NGINX binary and configuration file you intend to run. Then reload or start the service using your installation’s service arrangement. Start the encoder with the local relay URL and watch the NGINX error log for a successful publisher connection or a useful failure message.
Next, check YouTube Live Control Room’s preview for the test stream. Use a private or unlisted test where that suits your channel workflow, and verify that the preview receives audio and video before scheduling a public broadcast. A connection accepted by local NGINX only proves that the first leg reached the relay; it does not prove YouTube accepted the outbound push or that the key belongs to the selected stream.
| Symptom | Check first | What the result suggests |
|---|---|---|
| Encoder cannot connect | Local address, application name, port, firewall, NGINX listener | The encoder-to-relay leg is not established |
| Encoder connects, but YouTube preview is empty | NGINX push configuration, RTMPS endpoint, key, outbound network access | The relay-to-YouTube leg may be failing |
| YouTube preview appears but media is wrong | Encoder output, audio/video tracks, source file, stream settings | Transport may work while the feed itself needs attention |
| Stream drops after starting | NGINX logs, encoder logs, host and network interruptions | Check which leg dropped before changing configuration |
Use timestamps to correlate encoder messages, NGINX logs, and the Live Control Room preview. If the encoder reports a connection failure, changing the YouTube key is unlikely to help. If the local publisher remains connected but NGINX reports an outbound push error, inspect the RTMPS URL, key, certificate or network error, and egress rules. If both legs appear connected but the content is interrupted, investigate the encoder’s source and output separately. For channel-level latency and DVR choices, see the guide to YouTube stream-key settings in Live Control Room.
Do not infer reliability from a short test alone. Run a test long enough to observe the actual pattern of your source and network, then decide what monitoring and restart procedure you need for your own channel. The module can forward a stream, but it cannot ensure a stable camera, file, encoder, power supply, or internet connection. Make a note of the working local URL shape, the configuration file location, the safe method for updating the key, and the exact log location so a later restart does not become guesswork.
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 basic NGINX RTMP relay need HLS or recording?
No. A basic relay receives an RTMP publish and forwards it to the configured YouTube RTMPS destination. HLS, DASH, recording, playback, and transcoding are optional module capabilities, not prerequisites for this job.
Should my encoder use the YouTube stream key?
Not in this relay arrangement. The encoder publishes to the Ubuntu host’s application and local stream name; NGINX uses the YouTube RTMPS endpoint and stream key for the outbound push. Keep the two destinations distinct when troubleshooting.
Can I install the module with Ubuntu’s ordinary NGINX package?
Do not assume so. The community module is third-party, and the ordinary package may not contain its RTMP directives; use a compatible source build or a supported dynamic-module workflow, and verify the NGINX configuration before starting it.
What should I do if YouTube reports an SSL error?
Check that the destination copied from Live Control Room uses rtmps, then review the exact error and your host’s outbound network rules. YouTube says port 443 may help in some cases, but use the current official guidance and do not treat a port change as a universal fix.