NGINX RTMP configuration for YouTube has two separate links: your encoder publishes to an RTMP application on your NGINX host, and a relay then sends that stream to YouTube. The application block can accept a local publish, but it does not by itself establish that your deployed module can make YouTube’s required secure RTMPS connection.
Treat every configuration example below as conceptual, not tested. The upstream community module, a packaged NGINX Plus module, and other builds may differ; check the exact build and its transport support before choosing a forwarding method.
Understand the two-link streaming path
Think of the setup as publisher → NGINX application → YouTube. On the first link, an encoder such as OBS or FFmpeg sends video and audio to an RTMP address on a machine running NGINX. On the second, a relay component forwards the incoming stream to the ingest address and key for the YouTube broadcast. The component making that second connection must support the transport and TLS details YouTube requires.
The two links can use different protocols. The publisher might send ordinary RTMP to a private or otherwise access-controlled NGINX listener, while the onward YouTube connection uses RTMPS. Do not assume that accepting RTMP locally means the same module can relay securely to YouTube, or that a generic push directive turns a plain RTMP connection into RTMPS.
For YouTube’s secure route, Google specifies RTMPS, port 443, SSL/TLS, and SNI containing the destination hostname. The URL must also contain a valid YouTube ingest server and application path. Google describes RTMPS as RTMP carried through an SSL connection in its RTMPS ingestion documentation.
That separation helps you diagnose failures. If the encoder cannot publish, investigate the local listener, application name, credentials and network access. If NGINX receives the stream but YouTube does not, investigate the onward relay, destination details and TLS support. For a broader look at the choices involved in hosted delivery, see this guide to choosing an AWS live-streaming solution.
Define the RTMP application
The upstream nginx-rtmp-module README shows a minimal arrangement with an RTMP server listening on port 1935 and an application named live. In conceptual form, it looks like this:
rtmp {
server {
listen 1935;
application live {
live on;
}
}
}
This illustrates a listener and a live application only. It is not a complete YouTube relay, nor a tested configuration for your system. The upstream module README documents the module’s examples and optional features; check the revision and build you actually use rather than assuming every installation behaves identically.
An encoder’s publish address follows the shape rtmp://host/app/name. The app segment must match an application {} block, such as live; the final segment is the stream name interpreted within that application. For example, rtmp://stream-host.example/live/service refers to application live and stream name service. The host and name here are illustrative placeholders, not a destination you can use as-is.
The live on; setting enables live publishing for that application in the documented pattern. It does not configure a YouTube destination, define who may publish, or provide a firewall policy. Keep the listening port reachable only by the intended publishers. The module README describes publish allow and deny rules and HTTP callbacks as possible controls; decide on an access policy suitable for your network and build before exposing an ingest endpoint.
A stream key is a credential, not a label to post in a public configuration example. Avoid putting it in shared logs, screenshots or an openly accessible configuration file. If you need to understand what happens when a stream’s picture and sound diverge later in the chain, this guide to audio and video sync issues in a YouTube live stream covers a separate delivery problem; it does not alter how the RTMP application is addressed.
Configure publisher ingest
Start by deciding which program will publish and where it runs. In its streaming settings, configure the local NGINX host and the application path, then provide the stream name or publishing key expected by your setup. The address must agree with the NGINX listener and application block. If the application is live, publishing to a different path such as /studio/ will not reach that block unless you define and use a matching application.
The sample listener’s port, 1935, comes from the upstream example. It is not a requirement to expose that port to the public internet. If the publisher runs on the same machine or within a private network, use an appropriately scoped address and firewall rule. If it is remote, restrict access to the intended source where your network permits, and use the module’s documented controls as an additional measure rather than treating an obscure stream name as protection.
Do not add a second link until the local one is understood. Confirm that the publisher can connect to the listener and that NGINX recognises the application. A successful local publish means the first leg works; it does not prove that YouTube has received anything. Conversely, YouTube’s stream key belongs to the YouTube destination setup and should not be confused with whatever authentication or naming arrangement protects your local publishing endpoint.
If your use case is a repeatable programme rather than a live camera, consider the video source and hand-off separately from server configuration. A guide to scheduling different videos on a 24/7 YouTube live stream can help frame that operational question. NGINX’s RTMP application handles ingest and relay functions; it does not by itself decide your schedule or create a programme rotation.
Set the YouTube destination information
Use the destination information shown for the specific stream in YouTube Live Control Room. YouTube Help directs creators to Stream settings and the lock icon to reveal the RTMPS URL and associated stream key. Its RTMPS setup instructions are the place to check current account-facing steps. Do not copy a sample endpoint from an old post or substitute a generic host for the address YouTube supplies.
The YouTube URL and key are account- and stream-specific. Put them into the relay component that actually makes the outbound connection, using that component’s documented secret-handling method. Avoid hard-coding a real key into an example shared with other people. If you use a YouTube API client to obtain ingest information, Google documents the RTMPS address in cdn.ingestionInfo.rtmpsIngestionAddress; that field supplies an address, while the associated stream information and credentials still need to be handled as intended by the API workflow.
The destination contains more than a hostname. The scheme needs to indicate RTMPS, and the server and application path must be valid. Google also requires port 443, an SSL/TLS connection, and SNI set to the destination hostname. A relay that can open a TCP connection to a host is not necessarily able to satisfy those requirements.
Keep the destination setup conceptually separate from the local application block. The local block names where an encoder publishes; it does not automatically rewrite the address into YouTube’s endpoint or supply YouTube’s key. A relay may be configured elsewhere, or a different RTMPS-capable encoder may read from NGINX and send onwards. Choose based on demonstrated support and on how you can keep the destination key private.
Check module support for the required transport
Before writing a relay rule, identify what is installed. The nginx-rtmp-module maintained in the upstream community repository is a third-party module. NGINX Plus also documents a separately packaged RTMP dynamic module. These are not interchangeable names for one universal build, and you should not assume that their features, compatibility or update paths match.
NGINX’s official Plus instructions explain how to install its packaged RTMP module, load ngx_rtmp_module.so in the main context, run nginx -t, and reload NGINX. Those instructions apply to NGINX Plus. For NGINX Open Source, the installation guide describes compiling third-party modules with --add-module or loading a dynamically built module where supported. The relevant NGINX Open Source module installation guide and NGINX Plus RTMP module instructions describe distinct installation routes.
Compatibility depends on the NGINX version, operating system, package source, module revision and whether a module was built or loaded in a compatible way. Record those details before troubleshooting. A configuration directive documented for one module revision may not be available in your package, and successful parsing does not establish that a relay can negotiate the destination’s required TLS connection.
For the YouTube leg, ask the maintainer or vendor of the exact relay build whether it supports RTMPS output, TLS on port 443, and SNI for the target hostname. Look for documentation that explicitly covers those details or a test on the same build and deployment. Generic stream-relay examples establish that relay functionality exists; they are not evidence that a particular build meets YouTube’s RTMPS requirements.
NGINX’s module documentation also includes optional functions such as HLS or DASH output, recording, callbacks, statistics and FFmpeg integrations. These are not prerequisites for forwarding a stream to YouTube. Add them only to solve an identified need, and verify their behaviour on your build. For example, creating local HLS output adds a separate delivery path; it does not make the YouTube connection secure.
Verify whether RTMPS output is available
A common source of confusion is seeing a generic push example and assuming it provides secure transport. The upstream README’s relay examples demonstrate generic RTMP pushing to a host. That does not prove that the directive or the installed module supports YouTube’s secure destination requirements. Do not use a generic push line as a guarantee of RTMPS, and do not insert an invented endpoint or key into an unverified example.
Check the exact implementation’s documentation and release notes for outbound TLS support, port selection and SNI. If the documentation is silent, ask the maintainer or test the specific build in a controlled environment before treating it as capable. A correct result must reflect the complete connection, not only a configuration parser accepting a directive or a socket opening.
If direct module relay cannot be verified, choose another component that can demonstrably send RTMPS. For example, a separate encoder or relay can consume the local stream and make the YouTube connection, provided its documented configuration covers TLS, port 443 and SNI. That adds another component to monitor and another place where the stream key must be protected. If direct forwarding from NGINX is preferable, confirm the installed module’s support before designing around it.
The practical trade-off is control versus simplicity. A custom relay can fit an existing NGINX workflow and expose controls you need, but it asks you to verify build compatibility, transport support, secrets and failure handling. A separate RTMPS-capable publisher may make the secure hop clearer, though it creates its own configuration and monitoring tasks. Neither route removes the need to confirm the exact YouTube endpoint and credentials.
Test and troubleshoot the actual configuration
This article’s examples are conceptual and have not been executed. Treat the first test as a compatibility check, not as confirmation that an example is ready for production. Record the NGINX version, module package or revision, and the configuration location in use. Then follow the installation procedure for that distribution. When you change configuration, use the appropriate syntax test for the installed NGINX before reloading; NGINX’s Plus RTMP instructions specifically include nginx -t before reload.
Test the two links independently. First make a local publisher connect to the intended host, port and application path. Check the publisher’s status and the NGINX logs for connection or publish errors. Then test the onward route with the exact address and key from Live Control Room, using a relay whose RTMPS support has been established. A local stream visible at NGINX does not confirm a successful YouTube ingest.
When the secure hop fails, work through the transport details rather than repeatedly changing the local application name. Confirm that you used the RTMPS URL, not the ordinary RTMP address; that the connection targets port 443; that the relay creates TLS rather than plain TCP; and that it sends SNI for the destination hostname. Then check the application path and key, followed by the local module and firewall rules that govern the intended outbound connection.
Google’s troubleshooting guidance associates SSL errors with an incorrect endpoint, protocol or port, and notes that a timeout can result from sending cleartext RTMP to an RTMPS server. These symptoms are clues, not unique diagnoses. Compare the observed error with the exact URL and transport configuration, and consult the current YouTube RTMPS troubleshooting guidance before changing settings.
Do not post a live key or a full credential-bearing URL when asking for help. Redact secrets from logs and screenshots while preserving the scheme, hostname, port and relevant error text. If a configuration parses but delivery still fails, return to the central question: does this exact deployed relay implementation provide TLS, port 443 and SNI for its outbound connection? If you cannot establish that, use a component with documented support rather than relying on an assumed push capability.
For a channel built around recurring recorded material, keeping the computer out of the broadcast path can remove one operational task: StreamNeo lets you upload a video once and run it as a YouTube live stream without leaving your own computer switched on. It is a separate route from configuring an NGINX relay, so decide which operating model suits the source and control you need.
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 configure NGINX RTMP to stream to YouTube?
Configure a publisher to connect to an NGINX RTMP listener and an application whose name matches the URL path. Then send the stream onwards using a relay that is verified to support YouTube’s RTMPS requirements, including TLS, port 443 and SNI. A local application block alone does not configure the YouTube connection.
Does a generic NGINX RTMP push directive guarantee RTMPS?
No. A generic relay example does not establish that your deployed module supports secure output, port 443 or SNI. Check documentation or test the exact build before relying on it.
Why is my YouTube RTMPS stream timing out?
One documented cause is using cleartext RTMP against an RTMPS destination. Confirm the RTMPS URL, port 443, TLS and SNI, then verify the destination path and key. A timeout can have other causes, so use the current YouTube troubleshooting guidance alongside your relay logs.
Should I use the NGINX Plus module or a community module?
The answer depends on your NGINX distribution, compatibility needs and the capabilities of the exact build. NGINX Plus documents a packaged dynamic module, while the upstream community module is a third-party project. Compare installation and update paths, then verify outbound RTMPS support rather than assuming either distribution provides it.