If FFmpeg repeatedly reports Connection refused while publishing to YouTube, it has not established a TCP connection to the host and port in its configured destination. Check the ingest URL and protocol first, then check whether the machine running FFmpeg can reach that destination through its network and firewall.
That message identifies a failed connection stage, not the exact fault. It does not by itself prove that the stream key is wrong, that YouTube is unavailable, or that you need to change bitrate or encoding settings. Work through the checks below in order, changing one thing at a time.
What “Connection refused” indicates
A publishing session starts by connecting from the computer or hosted machine running FFmpeg to the ingest destination. Only after that connection is established can YouTube accept the stream and report on such things as the incoming feed’s health. A refusal means the attempted TCP connection was not established; the wording alone cannot tell you why.
The configured destination may contain a wrong or stale host, a mismatched protocol, or a port that cannot be reached from the machine. A firewall or network policy can also affect whether outbound traffic reaches the destination. Those are possibilities to investigate, not conclusions about your particular setup.
It helps to separate four stages that are often collapsed into the phrase “the stream is not working”:
| Stage | What to check | What it does not establish |
|---|---|---|
| Destination and protocol | The current YouTube Stream URL and whether you intend RTMP or RTMPS | That the network allows a connection |
| Network connection | DNS, routing, outbound rules and reachability from the FFmpeg host | That YouTube will accept the stream key |
| Stream acceptance | The current stream key and the selected live event | That the incoming video has healthy bitrate or format |
| Stream health | Bitrate, keyframes, resolution, audio and YouTube’s health messages | The cause of a prior TCP refusal |
This ordering prevents a common detour: changing video settings to fix a connection that has not yet been made. If you are also tuning a working encoder, keep that as a separate task; the FFmpeg bitrate and keyframe guide is relevant after the connection stage is past.
Verify the ingest destination and protocol
Open the current stream’s settings in YouTube Studio’s Live Control Room. Copy the Stream URL shown for that stream and place it in FFmpeg’s server or destination field. YouTube describes the Stream URL as the address that tells the encoder where to send the feed; it is distinct from the stream key, which is entered separately. See YouTube’s guide to managing live stream settings.
Do not rely on a hostname remembered from an older setup, a URL copied from another platform, or a destination from an unrelated scheduled stream. If you have several streams or encoder profiles, check that FFmpeg is using the URL for the event you intend to broadcast. A correct key paired with the wrong destination is still a configuration mismatch to resolve.
Read the complete destination, not just its familiar-looking hostname. Confirm the scheme (rtmp:// or rtmps://), host and any port shown. Also check that the destination field has not picked up an extra space, a line break, or command syntax that belongs in a separate field. The appropriate format depends on the exact URL YouTube provides and the FFmpeg command you are using.
Keep the key out of screenshots, shared logs and public posts. It functions like a password for sending to the stream. When sharing a command for troubleshooting, redact the key and any other private tokens while preserving the scheme, host and port if those are needed to understand the connection attempt.
For long-running channels, save a note of which profile uses which current stream URL, but do not treat an old note as the source of truth. The practical comparison is between what the active Live Control Room shows and what the running FFmpeg process actually uses. If the channel runs an automated playlist, a change in that process’s input does not necessarily change its destination; see how to schedule playlist rotation with Cron on Debian for the separate scheduling side of an always-on setup.
Use the exact RTMPS URL when using RTMPS
YouTube recommends RTMPS, a secure extension to RTMP. If you choose RTMPS, use the actual RTMPS URL supplied in Live Control Room rather than substituting a generic RTMP address or assuming that changing rtmp to rtmps is sufficient. YouTube’s RTMPS encryption instructions explain how to obtain the RTMPS URL using the lock control in Live Control Room.
Compare the scheme and endpoint character by character with the supplied RTMPS destination. Confirm that the FFmpeg build and selected protocol handler support the connection you configured. A command that works with a plain RTMP endpoint is not proof that the same command or build will handle RTMPS correctly. If you use URL options, make sure they are supported by the protocol handler in your build rather than assuming every RTMP-related option works with every handler.
YouTube’s RTMPS troubleshooting page mentions trying port 443 for the SSL error case it describes. That is a specific troubleshooting suggestion, not a universal remedy for every Connection refused message. Do not replace the port or host arbitrarily: use the exact destination and follow the current guidance for the error you actually see.
If your intended protocol is plain RTMP, do not label it RTMPS merely because it sounds more secure; set the destination and protocol consistently with YouTube’s current stream settings and your FFmpeg build. If you are unsure which mode the active event expects, return to Live Control Room instead of testing guesses against old URLs.
Check the machine’s network and firewall reachability
Once the URL and protocol match, investigate the network path from the machine that runs FFmpeg. The relevant question is not whether a browser on another device can open YouTube, but whether this host can make the required outbound connection to the configured host and port. A home router, office or venue network, hosting provider, VPN, proxy, DNS setup or firewall policy may affect that path.
Start with the least disruptive checks. Confirm the host has an active network connection, the system clock and DNS are functioning as expected, and the process is not being forced through an unintended VPN or proxy. If you manage the firewall, inspect its outbound rules for the destination and port; on a managed workplace or hosted network, ask the administrator whether outbound RTMP or RTMPS traffic to the supplied endpoint is allowed. Do not disable a firewall wholesale as a first test.
If the destination resolves to an address but FFmpeg still cannot connect, that does not settle whether the route or remote endpoint is reachable. Likewise, a timeout and a refusal are different reports: YouTube’s documented RTMPS troubleshooting example includes failed to connect to server — connection timed out, which should not be confused with the TCP refusal you are investigating. Record the exact error and the stage where it occurs.
YouTube also recommends reliable connectivity and enough upload capacity for the chosen stream. Upload bandwidth matters for maintaining a stream once it is being sent, but a shortage of bandwidth does not by itself prove the cause of a TCP refusal. If a connection succeeds and the preview later becomes unstable, then check the available upload capacity and YouTube’s encoder settings and bitrate guidance. Keep that investigation separate from whether FFmpeg can establish the initial connection.
A useful comparison is to run the same configuration from the same host on a different permitted network, if one is available and testing there is appropriate. If it connects there, that points you towards a difference in network path or policy, but it still does not identify a precise rule without further evidence. Avoid moving a production channel between networks during a critical broadcast just to test a theory.
Refresh the stream key from Live Control Room
After confirming the destination, check the key as a separate setting. YouTube’s live-stream troubleshooting guidance recommends copying a stream key from Live Control Room into the encoder when startup trouble persists. Select the intended event or stream, copy the current key, and paste it into FFmpeg’s key field or the corresponding command value.
Refreshing the key is sensible because a stale or mismatched key can prevent YouTube from accepting a feed. It is not a guarantee that a refused TCP connection will be fixed: the connection has to reach the ingest endpoint before YouTube can assess the key. If the same refusal remains after you replace the key, return to the destination and network checks rather than cycling keys repeatedly.
When using a persistent stream key, confirm that FFmpeg is using the key assigned to that stream and not a value left in a different profile or environment variable. If a key has been exposed, handle it through YouTube’s current account controls and replace it as appropriate; do not paste it into a forum or include it in a diagnostic report. A redacted command can still show whether the URL scheme, host and port are set as intended.
Test the connection and inspect the next error
Make one controlled attempt after checking the destination, protocol, network path and key. Use a test stream or a scheduled stream that is safe to preview, then check Live Control Room to see whether YouTube receives the feed. For a 24/7 channel, plan tests so you do not unexpectedly interrupt the current audience or replace the active event’s settings.
Save the full FFmpeg output around the failure, but redact the stream key. Note the FFmpeg version and build, operating system, exact URL scheme and port, and whether the attempt came from a home, office or hosted network. These details help distinguish a protocol-handler or configuration issue from a network-path question; without them, no one can reliably identify your exact cause from the single phrase Connection refused.
Interpret the next result by stage. If the same refusal appears before a connection is established, focus on the endpoint, protocol and reachability. If FFmpeg connects but YouTube does not accept the feed, check the stream key and selected Live Control Room event. If YouTube previews video and then flags stream health, move on to bitrate, codec, keyframe interval, audio and resolution using the current official guidance.
YouTube recommends testing with representative motion and audio and checking the preview and stream health. A still image or silent test may not reveal problems that appear in the intended programme. For a continuous music or devotional channel, test with a representative section of the actual programme before leaving the broadcast unattended; the practical continuity concerns are also covered in keeping a Kannada songs stream running on YouTube.
When repeated local restarts consume time and leave you uncertain whether the computer will remain available overnight, a cloud-run option such as StreamNeo can remove the specific burden of keeping that computer on: you upload the video and provide the YouTube stream key, while the stream runs with monitoring and restart handling. It is YouTube-only, so it does not change the need to use the correct destination, protocol and key.
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 “Connection refused” mean my YouTube stream key is wrong?
Not necessarily. The message indicates that FFmpeg did not establish the configured TCP connection; it does not identify the exact cause. Check the URL, protocol and network path first, then refresh the key from Live Control Room if stream acceptance remains an issue.
Can I use a generic RTMP URL when FFmpeg is set to RTMPS?
No. When using RTMPS, use the exact RTMPS URL supplied in Live Control Room, including its scheme and endpoint. Do not substitute a generic RTMP destination or assume that changing only the scheme will produce the right URL.
Should I change the port to 443 whenever the connection is refused?
No. YouTube mentions port 443 in its guidance for a particular SSL error case, not as a universal fix for all refused connections. Match the current supplied destination and consult the relevant official guidance for the specific error.
When should I adjust bitrate or encoding settings?
After FFmpeg connects and YouTube is receiving the feed, use Live Control Room’s preview and stream-health messages to assess the format and delivery. Bitrate or codec changes are not a diagnosis for a TCP connection that has not yet been established.