If your Nginx RTMP stream is not appearing in YouTube Studio, first confirm that the relay is sending to the current Stream URL and stream key shown in Live Control Room. Then use YouTube’s preview and status to establish whether YouTube is receiving data before changing Nginx or encoder settings.
A running local process is not proof that YouTube has a feed. Work from observable evidence: Studio’s received-data status, the relay’s upstream connection and publish results, and the media output reaching the service. That sequence separates a wrong endpoint or key from a connection failure or a feed YouTube cannot use.
Confirm the active YouTube stream URL and key
Open the stream’s settings in YouTube Live Control Room and check the current Stream URL and stream key. The encoder or relay needs both: the URL identifies the ingest endpoint, while the key identifies the stream. YouTube’s encoder setup guidance describes entering these values in the software that sends the feed.
Compare the Studio values with the values Nginx’s upstream publisher actually uses. Do not rely on an old configuration file, a saved terminal command, or a key copied from another broadcast. If a key was reset, any sender still using the previous key must be updated. YouTube’s stream troubleshooting guidance specifically recommends obtaining a new key in Studio and updating a third-party encoder when it reports a startup error.
Treat the stream key as a credential, much like a password. Avoid pasting it into a public support post, sharing an unredacted screenshot, or including it in a log excerpt you send to someone else. When asking for help, mask the key and share only the useful surrounding configuration, error text and timestamps.
The comparison should be exact, not approximate. Check for a stale server address, a missing or extra path component, accidental whitespace, or a key that belongs to a different scheduled stream. Avoid changing several values at once: if you replace both URL and key without recording what was there, a successful reconnect will not tell you which value was wrong.
One useful way to isolate the fault is to enter the current Studio URL and key in the sender that is meant to publish to YouTube, then check whether that sender reports an upstream connection and publish. If Studio still shows no data, that alone does not prove the key is wrong. A network, protocol, relay, authentication or media problem may prevent a usable feed as well. The sender’s own logs and YouTube’s view of the stream are the next evidence to collect.
Read the stream status in Live Control Room
Once the URL and key have been checked, look at the relevant stream in Live Control Room while the relay is running. For a scheduled encoder stream, YouTube’s workflow is to start the encoder, wait for the preview to appear, and then select Go live. A stream can therefore be receiving a feed in Studio without yet being publicly live; the preview and the separate Go live action are distinct steps.
If a preview appears, YouTube is receiving enough of a feed to display it. That points away from a completely failed connection, but it does not establish that the stream is live to viewers. Check the scheduled event, its status and privacy setting. A private or unlisted broadcast may not be visible to the audience you expect, even if its preview is present. YouTube explains the available stream settings in its live stream settings guide.
If the preview is absent, take note of the exact status text Studio displays and whether it changes after the sender starts. Avoid repeatedly restarting Nginx before noting this: a restart can erase useful evidence about the first connection attempt, and it does not identify which side failed. A brief wait may be needed for a feed to be recognised, but a persistent absence should send you to the sender and relay evidence rather than to guesswork.
For API users, Google’s LiveStreams reference defines active as a stream receiving data and inactive as one not receiving data. The API also distinguishes states such as ready, created and error, and provides health information. These are YouTube-side observations, not diagnoses of a particular Nginx setting. An inactive state tells you that data is not reaching YouTube as a stream; it does not tell you whether the cause is the endpoint, key, connection or outgoing media.
Record what Studio shows alongside the time of the test. If the relay reports a successful upstream publish while Studio remains inactive, keep both observations: they are in tension and worth investigating, but neither should be silently discarded. If Studio becomes active while the preview remains blank or unhealthy, the connection may be established while the media still needs attention.
Verify Nginx is publishing to the intended endpoint
Nginx can be running and accepting a local publisher without successfully publishing upstream to YouTube. Establish the direction of each connection in your setup. A local encoder may send to an Nginx RTMP application, and a separate relay process or configuration may send onward to YouTube. Confirm which component is responsible for the second connection and whether it is attempting to publish to the exact Studio-provided endpoint.
Inspect the active configuration, not only a sample file or an older copy. Identify the upstream destination, protocol, stream name or key field, and any variable or include that supplies them. Keep secret values redacted when sharing configuration. The aim is to establish what is in use; the title of the problem does not provide enough evidence to name a directive as faulty, and a particular Nginx module version or command cannot be assumed.
Pay particular attention to RTMP versus RTMPS. These are not interchangeable strings to swap casually. If you choose RTMPS, use the RTMPS URL supplied in Live Control Room and confirm that the relay supports the required TLS connection. Google’s RTMPS ingestion guide documents TLS to port 443 and hostname/SNI requirements. YouTube also recommends checking the RTMPS URL and port when SSL errors or connection timeouts occur in its RTMPS help page.
A hostname mismatch, an incorrect protocol, a network restriction, or a TLS handshake failure can prevent the relay from reaching the service even when the key is current. Conversely, a successful TCP connection alone does not establish that the RTMP publish was accepted or that usable media followed. Read the connection and publish evidence together, and compare it with Studio’s status at the same time.
If your relay uses a separate local ingest and upstream publish, test each leg independently where your setup permits. Confirm first that the local encoder is reaching the intended Nginx application. Then confirm that the upstream publisher is using the Studio endpoint and receiving a publish result rather than merely opening a local listening port. This is a diagnostic division, not an assertion that every Nginx deployment has the same layout.
Inspect Nginx and encoder logs
Gather a short log window covering one controlled attempt: when the encoder starts, when it connects to Nginx, when the relay tries YouTube, and when Studio status is checked. Preserve timestamps and the full error message, but remove the stream key, tokens and other credentials before sharing it. A line that only says a process started is not evidence that the upstream publish succeeded.
Look for separate evidence of the local publisher connection and the upstream destination connection. Does the encoder connect to the expected local address? Does Nginx or its RTMP component attempt an upstream connection? Is there a response or error at publish time? If the log indicates DNS resolution, refused connection, timeout or TLS negotiation trouble, that describes a different class of failure from an authentication or publish rejection. Do not infer a cause from a generic disconnect line alone.
Log formats differ by Nginx build, RTMP module, wrapper and encoder, so there is no single line that proves every YouTube publish succeeded. The official YouTube documentation describes its own ingestion and stream states; it does not define Nginx-specific directives or log signatures. Obtain the actual configuration, component versions and corresponding logs before attributing the failure to a particular local setting.
Compare the log times with Studio. For example, if the relay records a connection timeout and Studio remains inactive at the same time, the evidence points to a connection path worth checking. If the relay records an accepted publish but Studio remains inactive, verify that the log refers to the current endpoint and stream, then inspect the actual publish and media path. A local “connected” message can refer only to the encoder-to-Nginx leg.
Keep one copy of the original configuration and note every change with its test result. This is especially useful for always-on channels: an undocumented late-night edit can make the next failure harder to distinguish from the one you were trying to fix. For a broader distinction between a dropped broadcast and other interruptions, see the 24/7 stream troubleshooting guide.
Check encoder connection and media output
The sending encoder must deliver a media feed, not merely establish a socket. Check that it is producing the expected audio and video output and that the relay is receiving it. If Nginx is intended to relay an incoming feed, confirm that the local input is active and not ending immediately. If it is restreaming a file or playlist, confirm that the source opens and continues rather than failing at startup.
Use the sender’s status panel or logs to distinguish “connected” from “publishing”. A connection to the local relay shows only that the first leg is alive. The feed can still fail on the relay-to-YouTube leg, or arrive with media problems that leave Studio without a useful preview. Check for errors opening the source, absent audio or video, a process exit, or a stream that stops producing output, then compare those observations with Studio’s preview and health information.
Do not change encoding settings just because the preview is missing. First establish whether any data reaches YouTube. If Studio reports inactive and the relay has no successful upstream publish, investigate the endpoint, credentials and connection path before treating the media format as the lead suspect. If Studio reports active but preview or health information indicates a media issue, then inspect what the encoder is actually sending and whether it continues to send it.
A practical test is to run a short, controlled send using the same endpoint and key, while observing both the sender and Studio. Keep the source simple and known to open, and avoid editing unrelated bitrate, frame-rate or codec settings during that test. If the controlled feed appears but the regular programme does not, that narrows attention towards the regular source or its encoder output; it still does not prove a universal fix for the original configuration.
If your normal arrangement relies on a desktop staying awake to keep the source and relay running, that is a separate operational dependency from the current ingest diagnosis. For channels that are deciding how to run a prerecorded loop, the options for scheduling prerecorded streams may help frame that separate decision. StreamNeo removes the need to keep your own computer running for a file-based 24/7 YouTube broadcast, which can address the specific burden of maintaining a local machine overnight; it does not identify or repair an Nginx relay configuration.
Test one change at a time
Make a record of the initial evidence before changing anything: Studio status, preview state, active URL and key source, relay logs, encoder logs, and whether media is reaching Nginx. Then change only the item supported by that evidence. If you update a reset key, leave the protocol and media settings alone for that test. If you correct an RTMPS endpoint, do not simultaneously change the encoder’s output format.
After a change, restart only the relevant sender or relay component if required by its configuration, and repeat the same observation sequence. Check whether the upstream connection result changed, whether Studio’s status changed, and whether a preview followed. A favourable result is evidence that the change helped in that test; it is not proof that the same adjustment applies to another deployment or that it will prevent future interruptions.
When a test fails, revert a speculative change before trying a different hypothesis, unless the change is required to preserve security, such as replacing an exposed key. Keep the successful and unsuccessful test notes together. This avoids ending up with several unverified edits whose combined effect is harder to reason about than the original failure.
If you cannot see enough detail to tell which component is publishing, simplify the test rather than adding settings. Run one sender, one known source, and one clearly identified upstream path. The guide to streaming prerecorded videos with Wirecast covers a different sending workflow, but its distinction between the sending application and YouTube’s Studio-side preview is useful when documenting the path you are testing.
If the logs are inconclusive, share a redacted configuration excerpt, component versions, timestamps, Studio status and the exact connection or publish errors with a knowledgeable maintainer. Do not include the live key. If you suspect an account or ingest-side problem, consult current YouTube Help or official developer documentation rather than relying on a forum post written for a different endpoint or software version.
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
Why does Nginx say it is running when Studio shows no stream?
A running Nginx process proves only that the process started. Your local encoder may connect to Nginx while the upstream connection to YouTube fails, or the relay may connect without successfully publishing media. Compare the local and upstream log evidence with Studio’s status.
Studio shows the stream but viewers cannot see it. Is the relay still failing?
Not necessarily. For a scheduled encoder stream, YouTube expects you to wait for the preview and then select Go live. Also check that the event is not private or unlisted if you expect it to be public; a preview is not the same as a public broadcast.
Should I switch from RTMP to RTMPS?
Only if your sender supports RTMPS and you can configure the exact RTMPS endpoint supplied in Live Control Room. RTMPS has TLS, port and hostname requirements, so changing the protocol string without confirming the endpoint and handshake can create another failure rather than explain the current one.
When should I reset the stream key?
Reset it if it may have been exposed, or if the encoder reports a startup error and YouTube’s troubleshooting guidance points you to a new key. Update every sender that uses it, keep the replacement private, and then check whether YouTube receives data; a new key does not by itself diagnose connection or media problems.