“Encoder disconnected” tells you that YouTube stopped receiving a usable feed; it does not explain why. To diagnose a disconnect on a Contabo VPS, match the exact Live Control Room error and its timestamp with the encoder log, then check the destination URL and protocol before changing firewall settings.
That order matters because an incorrect address, unsupported RTMPS connection, timeout, encoder issue or network interruption can all stop a feed. Preserve the evidence first, make one targeted change at a time, and confirm recovery in Live Control Room rather than assuming a restart fixed the cause.
Treat “Encoder Disconnected” as a Symptom
YouTube receives a stream from an encoder; it does not see every detail of how your VPS is configured. When its Live Control Room reports that the encoder is disconnected, you know the incoming feed has stopped or become unusable, but not whether the encoder exited, lost its connection, used an incorrect destination or encountered another problem. The label is a signal to investigate, not a diagnosis.
A VPS can remain powered on while its streaming process stops. The reverse is also possible: the encoder process may still be running while its outbound connection to YouTube is stalled. A restart might restore the feed in either case, but it can also erase useful evidence or simply mask a recurring problem. Before restarting, note what YouTube says, when it says it, and what the encoder was doing at that moment.
This is different from a viewer-side playback problem. If the encoder remains connected but YouTube flags the stream’s format or health, check the specific health message and media settings. If the stream disappears entirely, look for a matching connection event in the encoder log. The distinction can keep you from changing bitrate when the actual issue is a destination or connection timeout.
If you are deciding where a continuous broadcast should run, compare the practical trade-offs in keeping OBS streaming after shutting down your computer. That is a separate operating decision from diagnosing an individual disconnect: whichever machine runs the encoder, you still need to identify where the feed stopped.
Read YouTube’s Error Text and Timestamps
Open the stream in YouTube Live Control Room and look beside the stream-health indicator for the error text and its timestamp. YouTube’s troubleshooting guidance for live-streaming errors explains that messages appear next to the health indicator and are timestamped. Record the wording as shown, not just a summary such as “it went red”. The exact category can point towards a format issue, a connection timeout, or an SSL problem.
Write down whether the preview received data at all, when the error first appeared, whether it cleared, and whether the encoder process was still running. For a short investigation, a simple record is enough:
| What to note | Why it helps |
|---|---|
| Exact YouTube message | Separates a named format or connection error from a general symptom |
| Error timestamp and any recovery time | Lets you compare Control Room events with log entries |
| Whether preview received data | Distinguishes a feed that never arrived from one that later stopped |
| Encoder process state | Shows whether the software exited or continued running |
| URL scheme and port, without the key | Helps check RTMP/RTMPS and the destination safely |
YouTube distinguishes critical errors, which can prevent an event starting or cause viewer problems, from moderate errors that may reduce quality. Treat that classification as useful context, not proof of a particular fault on the VPS. A critical label does not itself establish a Contabo outage, and a moderate warning does not mean the stream is healthy enough to ignore.
Keep the stream key out of notes that you share. It is a credential used with the stream URL, and anyone who obtains it may be able to send a feed to your channel. If you need to ask for help, redact the key from screenshots, encoder configuration and logs. The troubleshooting examples in avoiding duplicate-content problems with a 24/7 YouTube stream concern channel content rather than connectivity, but they are a reminder that an always-on channel needs care beyond simply keeping the encoder running.
Match the Errors with Encoder Logs
After recording YouTube’s timestamp, inspect the encoder log around that time. Look for a clear event, such as a connection attempt, an authentication or handshake failure, a timeout, a reconnect, or the process ending. The wording varies by encoder, so do not assume that a phrase from one application will appear in another. The aim is to find whether the encoder’s account of the failure fits YouTube’s message and timing.
A useful timeline might read: the encoder begins sending, YouTube receives preview data, the log reports a failed connection, and Live Control Room shows a timeout at roughly the same time. That points you towards the outbound connection path. If YouTube reports an incorrect format while the encoder continues sending, focus first on the selected video and audio settings. If the log stops because the process exited, investigate the encoder and VPS operating state before editing network rules.
Timestamps need not be perfectly identical. The encoder and YouTube may record events at different stages of delivery, and their clocks or displayed time zones may differ. Compare the sequence and the interval around the event, and check that the VPS clock is sensible. One isolated log line is not enough to prove a cause; a recurring pattern across attempts is more informative.
Keep the useful portion of the log and note the encoder version, operating system and recent configuration changes. Redact the stream key, account tokens and any other credentials before sharing it. If you operate a continuous FFmpeg-based channel, the advice on reducing CPU use in a 24/7 ambient stream can help distinguish a process or resource problem from an ingestion failure, but lower CPU use alone does not establish that the network path is working.
Verify the Ingestion URL and Protocol
Copy the current stream URL from the Live Control Room rather than trusting an address saved in an old configuration. Check it carefully against the encoder’s destination field: a typo, stale address, missing port or wrong URL scheme can prevent the encoder reaching the intended ingestion endpoint. Confirm that the stream key is the current one, but keep it private while checking.
YouTube recommends RTMPS, an encrypted extension to RTMP. The encoder must support the protocol you select, and the URL scheme must match. A timeout is not automatically a firewall fault: YouTube’s documented checks include verifying the URL and confirming that the encoder supports RTMPS. If you have a specific error, use the corresponding guidance rather than changing several unrelated settings.
Be deliberate about the port too. Do not copy a port from an old tutorial or add one simply because another encoder configuration uses it. Check the current YouTube address and the encoder’s own field descriptions. If you edit a URL, change only the part you intend to test, then record what changed and whether Live Control Room receives data afterwards.
This step is particularly important on a remote VPS, where the sending encoder may be software rather than a locally connected hardware device. An inbound port used by another service is not necessarily relevant to the encoder’s outbound connection to YouTube. The Tata Play Fiber example in troubleshooting OBS reconnect loops also illustrates why a reconnect symptom needs to be read alongside the actual connection context, not treated as a universal diagnosis.
Check RTMPS Support and SSL Errors
If Live Control Room or the encoder reports an SSL error, start with the destination scheme and address. YouTube’s RTMPS setup instructions say to verify that the URL uses rtmps and is the correct server address. If the URL appears correct but the SSL error remains, YouTube advises trying port 443 in the URL or the encoder’s port setting. Apply that check only to the SSL-error case described by YouTube; it is not a general instruction to change ports whenever a stream disconnects.
For a timeout, follow a different branch: check that the URL is correct and that the encoder supports RTMPS. A legacy encoder or an incorrectly selected output mode may not establish the connection expected by the chosen address. Check the encoder documentation for the supported protocols and any relevant update or configuration notes. Do not infer that the SSL-specific port check will resolve a timeout or an unrelated process failure.
When you make a change, keep a short before-and-after note: the error text, URL scheme and port (without the key), encoder setting changed, and whether preview data arrived. If the error persists, restore the previous value before trying a different hypothesis. This avoids accumulating configuration changes that make the next log harder to interpret.
Investigate Timeouts and Network Interruptions
Only after confirming the destination and protocol should you inspect the VPS and network path. Check the Contabo Customer Panel to see whether the VPS is running, and consult Contabo’s status page for a relevant incident. If ordinary access to the VPS fails, Contabo recommends trying VNC. When VNC works but normal access methods do not, its guidance points to possibilities including firewall configuration, incorrect ports or network misconfiguration. That is a reason to investigate the path, not evidence that every YouTube disconnect is a provider outage.
Keep the two firewall layers distinct. Contabo describes its network firewall and the operating system’s firewall as separate controls. Its network firewall, when assigned, blocks inbound traffic by default and does not restrict outbound traffic; operating-system rules can govern inbound and outbound traffic. For an encoder sending a feed from the VPS to YouTube, inspect the relevant outbound policy in the operating-system firewall. Do not assume that opening inbound RTMP port 1935 fixes an outbound connection. First establish the actual protocol and destination port from the encoder and Live Control Room settings.
The practical question is whether the VPS can maintain an outbound connection to the selected YouTube endpoint. Review applicable OS firewall rules and recent changes, then compare the event time with any local network or system logs you have. If access works from another network or device, that comparison may help separate a VPS-side issue from a local access problem. Avoid broad firewall changes: they can expose services without addressing the failure, and they make it harder to know what corrected the stream.
If the URL is correct and the VPS is reachable but the connection still drops, collect observations before blaming capacity: egress performance, packet loss if you can measure it, and the timing or duration of interruptions. A published port speed is not the same as sustained throughput from your VPS to YouTube. Ask Contabo to investigate if your VPS or provider-side checks point to a host or network problem; ask the encoder vendor if logs point to protocol support or the software itself. Do not present a guess as a confirmed cause.
Check Media Settings After the Path Is Reachable
If YouTube receives the feed but reports a format or health problem, check the media settings against its current encoder guidance. The YouTube encoder settings and bitrate recommendations cover supported video codecs including H.264, H.265 (HEVC) and AV1, audio codecs including AAC and MP3, constant bitrate encoding, frame rate and keyframe interval. YouTube recommends a two-second keyframe interval that should not exceed four seconds. Match the selected settings to the format your encoder actually sends rather than changing everything at once.
Bitrate recommendations depend on codec, resolution and frame rate. For example, YouTube’s current H.264 recommendations include 14 Mbps for 1080p at 30 fps and 17 Mbps for 1080p at 60 fps. These are YouTube ingestion recommendations, not a guarantee that a particular Contabo VPS has that much spare outbound capacity. If you change resolution or frame rate, revisit the matching recommendation and check the encoder’s measured output rather than relying on a saved profile’s label.
An “incorrect stream format” message should lead you to inspect the settings named by YouTube, including whether the video and audio formats fit that configuration. If you alter codec, bitrate and keyframe interval together, a successful retry will not tell you which change mattered. Make a focused adjustment, test it, and compare the result in Live Control Room. YouTube also recommends testing before an event with similar motion and audio, then monitoring stream health during transmission.
A devotional loop with a still image and a news loop with frequent scene changes may place different demands on encoding, even when their chosen output resolution is the same. That is a reason to test the material you will actually broadcast, not to assume that one bitrate or preset suits every channel. If a format warning is absent and logs instead show a network timeout, return to the connection checks rather than lowering quality without evidence.
Confirm Recovery in Live Control Room
A process that says “connected” is not sufficient confirmation by itself. Check that Live Control Room receives preview data and that the health indicator improves; then compare the recovery time with the encoder log. If the original error clears but returns at the same point later, preserve the new timestamp and log excerpt. A repeated pattern is useful evidence for deciding whether the next investigation belongs in configuration, the encoder process or the network path.
For a controlled test, make one change at a time and give the connection enough time to demonstrate whether it remains stable under the stream conditions you expect. Keep the same file and output profile where possible, and record when the test begins and ends. Do not claim a permanent fix from a brief reconnection: an intermittent fault may need longer observation, and no single test guarantees that future disconnects will not occur.
If you need to escalate, provide the exact YouTube message and timestamp, the relevant encoder log section, encoder and operating-system versions, URL protocol and port with the key redacted, relevant firewall rules, and evidence of VPS status. This gives Contabo or the encoder’s support team something specific to investigate. If you cannot identify a likely cause, say so; the official guidance does not diagnose an individual VPS without its configuration and evidence.
Once the diagnosis is clear, the operating method matters too. If keeping your own computer on is the recurring burden, StreamNeo can take that specific task out of your routine: upload the video, add the YouTube stream key, and the channel can continue without your computer running. It is YouTube-only, so it does not replace the troubleshooting steps here or identify the cause of an error in an existing VPS setup.
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 “Encoder Disconnected” mean Contabo is down?
No. It means YouTube is no longer receiving the expected feed, and the message alone does not locate the fault. Check Contabo’s VPS status and provider notices, then match the YouTube timestamp with the encoder log before attributing the problem to the VPS or its network.
Should I open inbound port 1935 on my VPS?
Not as a first response to an outbound encoder disconnect. Establish which URL, protocol and destination port the encoder uses, then check the applicable operating-system firewall rules for that outbound connection. Contabo’s network firewall and the OS firewall are separate controls, so changing one does not necessarily change the other.
What should I do if YouTube reports an SSL error?
Verify that the destination uses the correct rtmps URL and server address, as YouTube documents. If the URL looks correct and the SSL error remains, YouTube advises trying port 443 in the URL or encoder port setting; keep a note of the change and check whether the error clears.
What evidence should I send to support?
Share the exact Live Control Room error and timestamp, a relevant encoder log excerpt, VPS status evidence, and the URL scheme and port with the stream key removed. Include relevant firewall rules and software versions if they help explain what you tested. Never send or publish the stream key.