A Contabo VPS YouTube stream that keeps disconnecting can be caused by the stream bitrate, the VPS configuration, a firewall, the network route, or the streaming service. The title alone does not identify which layer has failed, so start by collecting evidence rather than changing several settings at once.
Watch OBS Stats and logs during the failure, then follow the evidence through the server, firewall, route and service status. This gives you a repeatable way to distinguish a connection that cannot sustain its configured bitrate from a VPS or provider-side problem.
Start with OBS Stats and logs
Begin at the point where the failure is visible. Open OBS Stats while the stream is running and note the time when the stream becomes unstable or disconnects. Record the configured bitrate, dropped frames, skipped frames, missed frames, the current connection state and any visible warning. Also save the relevant part of the OBS log rather than relying on memory.
The OBS Stream Connection Troubleshooting guide explains that dropped frames or intermittent disconnections indicate a network issue between the streaming computer and the remote stream ingest server. In a VPS setup, the streaming computer is the VPS process, but the useful distinction remains the same: the encoder may be producing data while the connection cannot deliver it reliably to the selected YouTube ingest destination.
Look for a pattern rather than a single number. A brief rise in dropped frames followed by recovery is different from a counter that continues increasing until the broadcast disconnects. A stream that stops while dropped frames remain at zero points towards a different branch of the investigation, such as the streaming process, server state, authentication, or a service-side event.
The log can also show whether the process closed, lost its connection, failed to reconnect, or was interrupted by the operating system. Do not treat a generic reconnect message as proof of a Contabo fault. It tells you what OBS experienced, not necessarily where the underlying interruption began.
If you use OBS on a local computer to test the same channel, keep the local test separate from the VPS evidence. A local test can help show whether the issue follows the destination, but it does not reproduce the VPS's egress route. Similarly, a clean local stream does not prove that the VPS is misconfigured.
Use dropped frames to choose the first checks
Network-dropped frames should move network stability to the front of your checklist. OBS says frames are dropped when the connection to the remote server is unstable or cannot keep up with the configured bitrate, and that too many dropped frames can lead to a disconnection. This is a connection signal, not a verdict against a particular provider.
Compare the configured bitrate with what the VPS connection can sustain to YouTube over time. Do not confuse a provider's advertised port speed with measured, sustained upload performance to a particular ingest route. As listed on Contabo's site in September 2026, VPS and VDS port speeds range from 100 Mbps to 1 Gbps, but that specification does not establish the speed available to your stream at every moment or on every route.
If dropped frames rise, make one controlled change at a time. You could first test a lower bitrate, select another available YouTube ingest option if YouTube presents one, or run a short comparison to a different streaming destination. The purpose is to see whether the symptom changes, not to declare the first successful test a permanent cure.
A lower bitrate may reduce the amount of data the connection must sustain, but it can also reduce picture quality. If the stream carries a static devotional image, a lofi visual or a local news loop, the required bitrate may differ from a stream with rapid motion. Choose a setting that matches the content and encoding configuration rather than reducing it indefinitely.
OBS also notes that security software or firewall rules can interfere with its connection to a streaming server. A different-destination test may narrow the problem to a destination or route, but it is not conclusive by itself. If one destination works and YouTube does not, preserve the timestamps and settings, then continue with route and firewall checks.
For a separate explanation of the viewer-facing symptom, see this guide on how to stop OBS from buffering while streaming to YouTube. Buffering, dropped frames and a full disconnection are related but not identical observations, so keep the exact OBS symptom in your notes.
Check the VPS state and recent changes
Before changing network rules, confirm that the VPS is running in the Contabo customer panel. Check whether the instance has been stopped, restarted, recreated or placed into a different state. If the stream process is managed by a scheduled task, service manager or terminal session, confirm that the process still exists after the interruption.
Review what changed shortly before the first failure. Useful entries include:
- operating-system updates
- kernel or network-interface changes
- firewall edits
- changes to the default route or gateway
- changes to the stream key or YouTube broadcast settings
- encoder, bitrate or resolution changes
- a new monitoring, backup or security process
- a restart of the VPS or streaming service
The timing matters. A network problem that began immediately after a firewall edit deserves a different first test from a problem that began without any configuration change. Neither timing proves causation, but it helps you choose the safest comparison.
Contabo's guidance for an unreachable server recommends checking the server state, trying another access network, and considering local VPN, firewall or corporate restrictions. Those checks are especially useful when you cannot connect to the VPS, although management access and the stream's outgoing route are not the same path. Being able to log in does not prove that the VPS can maintain a connection to YouTube.
If you cannot reach the VPS over the usual method, use the provider's documented console or management access method instead of making blind changes through an uncertain connection. Keep a copy of the current configuration before editing it. A recovery console can help you regain access, but commands differ between operating systems and network managers, so do not copy a command without checking which system is installed.
For readers building a long-running process rather than diagnosing OBS, the Ubuntu FFmpeg 24/7 stream guide covers a different operating pattern. It should not be used as evidence that OBS, FFmpeg or Contabo is responsible for your current disconnection.
Review the interface and firewall direction
A VPS can be powered on while its network interface or route is incorrectly configured. Check that the active interface is up and that the server has the expected address, subnet and gateway. Compare the current values with the configuration recorded when the stream was working. If the address or gateway changed, stop and verify the intended configuration before restarting networking.
A firewall can exist at more than one layer. Review the Contabo product firewall, the guest operating system firewall and any rules supplied by a security tool. Look for rules that affect outbound connections, established connections, DNS resolution or the traffic used by the streaming process. Also check whether a recent rule was applied to the wrong interface or network profile.
Direction matters. As documented by Contabo in September 2026, its firewall drops inbound traffic by default after activation, while outbound traffic is unrestricted by default. That documented default does not mean every guest operating system is open, and it does not remove the need to inspect the active rules. It does mean you should not describe the provider firewall's documented default as an outbound block without evidence.
The Contabo firewall documentation is the primary reference for the product firewall's behaviour. Check the current documentation before changing a rule because the relevant controls may differ from the rules inside your operating system.
Make changes narrowly. If a rule is suspected, record its existing state, alter only the relevant rule, restart or reload the firewall using the method appropriate for the operating system, and observe the stream. If ordinary access depends on the firewall, keep a recovery path available before applying the change.
A rule that allows one connection does not prove the whole stream path is healthy. DNS, routing, packet loss and sustained upload can still cause dropped frames. Conversely, removing a firewall rule may appear to help while hiding a broader configuration problem. Restore unnecessary test changes after the comparison and document what happened.
Test route stability and preserve the evidence
If the VPS remains running, its interface and firewall appear correct, and dropped frames still rise, investigate the route between the VPS and the remote ingest service. A route can be usable for login traffic yet unstable for a long-running upload. It can also vary by destination, so a test to a general website is not a direct substitute for evidence about the YouTube path.
Run a route test from the VPS when the symptom is occurring or as close to the failure as possible. Depending on the tools available and your operating system, this may include traceroute or MTR. Record the destination, start and end time, VPS location, and the complete output. Do not edit out intermediate hops that look unfamiliar.
An intermediate hop that does not respond to probes is not automatically a fault. Some routers deprioritise or filter diagnostic traffic while forwarding ordinary traffic. Look for a pattern that continues to a later responding hop, loss that appears only at one intermediate point, or instability that corresponds with the stream timestamps. Interpret the output cautiously rather than treating every asterisk as a failed link.
Contabo's unstable-connection guidance identifies routing problems as one possible area and recommends providing traceroute or MTR results when a routing fault is suspected. Keep the output unchanged, with its timestamp, so support can compare it with their own information. A second test at another time can be more useful than a single dramatic-looking result, but do not invent a pattern from tests you did not run.
Do not repeatedly run aggressive diagnostics against an unfamiliar destination. Use a reasonable test interval and follow the provider's guidance. If the stream is carrying a live event, take a copy of the logs first and avoid restarting the VPS merely to obtain a cleaner result.
The route evidence is most useful when paired with OBS Stats. A high dropped-frames count at 02:14 UTC, followed by an MTR run at 02:16 UTC, gives support a relationship to investigate. An undated route output copied days later is much harder to connect to the actual interruption.
Check Contabo's current status information
Check Contabo's official status information for incidents affecting the relevant service, location or data centre. A status page that shows an incident is important context, but it may not describe every individual connection problem. A status page with no matching incident also does not prove that your VPS, route or firewall is healthy.
Use the status result as one part of the timeline. Note when the stream failed, when dropped frames began, when the VPS became unreachable if it did, and whether a status notice overlaps those times. If the status page later changes, preserve the original observation rather than rewriting your notes.
Contabo's unstable server connection guidance covers several possible fault locations, including local network or VPN restrictions, server network configuration, firewall rules, bandwidth overload and routing. This is why a provider status check should not replace the earlier evidence collection.
Contabo also states that its VPS, VDS and dedicated servers have no default bandwidth limit subject to its fair-use policy, and that it may take action in cases of exceptionally high or disruptive use. As listed on Contabo's site in September 2026, this is provider policy context, not a measurement of your stream's sustained upload and not proof of a good route to YouTube.
If your notes point towards a provider route or service issue, contact Contabo with the VPS identifier, location, failure timestamps, OBS evidence and preserved traceroute or MTR output. Avoid sending only the sentence “YouTube keeps disconnecting”. The more precisely you describe the symptom and time, the easier it is to distinguish a route problem from a guest configuration problem.
Match the fix to the evidence and retest
Once you have evidence, choose the smallest fix that addresses that evidence. Use this as a working map:
| Observed evidence | First area to check | Controlled retest |
|---|---|---|
| Dropped frames rise while the VPS stays reachable | Bitrate, sustained upload and route to the ingest service | Run at a suitable lower bitrate or compare a different destination, then monitor OBS Stats |
| The stream process stops but dropped frames do not rise | Encoder, service manager, process logs and VPS resources | Restart only the stream process and compare the next log |
| The VPS becomes unreachable after a network or firewall change | Interface, address, gateway and firewall configuration | Use documented console access, restore the last known-good setting, then test access and streaming separately |
| One destination fails while another remains stable | Destination-specific route, security rule or ingest path | Repeat with timestamps and preserve both sets of logs |
| MTR or traceroute shows a time-correlated route concern | Provider route or upstream path | Capture a second test and send the results to Contabo support |
| A matching Contabo incident overlaps the failure | Provider service or location | Wait for current provider guidance, then retest without assuming the incident explains every symptom |
Retest one change at a time and keep the original settings available. A successful short run is evidence that the symptom did not recur during that test, not a guarantee that the fault is permanently fixed. For an overnight channel, leave the monitoring and logs in place after the retest so you can tell whether the same symptom returns.
If bitrate changes affect the result, document the old and new settings and check the picture quality. If a firewall change affects the result, identify the precise rule rather than leaving a broad temporary allowance in place. If the route appears responsible, keep the diagnostics and support correspondence together.
You can also test the content pipeline separately from the network pipeline. A looped file with a clean transition helps remove playback interruptions from the diagnosis. The guide on creating a seamless loop for a YouTube nature live stream is relevant when a visible loop or black frame is being confused with a network disconnection.
For operators who want the home computer switched off after the file and channel are prepared, StreamNeo removes the need to keep that local machine running and provides automatic monitoring and restart of the cloud broadcast. It does not turn an unidentified VPS fault into a confirmed diagnosis, so preserve the evidence if you are investigating an existing Contabo stream.
If your main requirement is simply to keep a prepared video running without using your home electricity, compare the operating model described in how to run a YouTube stream 24/7 without using electricity at home. The right choice depends on whether you need direct control of the VPS and its network, or a simpler upload-and-channel workflow.
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 Contabo VPS port speed prove that YouTube will stay connected?
No. The port-speed range listed by Contabo describes a provider specification, not measured, sustained upload performance to your selected YouTube ingest route. Use OBS Stats, timestamps and route evidence to assess the connection your stream actually uses.
What do rising dropped frames mean in OBS?
They indicate that the connection to the remote ingest server is unstable or cannot keep up with the configured bitrate, according to OBS guidance. They do not, by themselves, identify Contabo, YouTube, the firewall or the route as the cause.
Should I disable the firewall to test the stream?
Do not make a broad change without recording the existing rules and keeping a recovery method available. Review provider-level and guest operating system firewalls, pay attention to traffic direction, and make the narrowest controlled change that tests the suspected rule.
What should I send Contabo support?
Send the VPS identifier and location, exact failure times with time zone, OBS Stats and log evidence, recent configuration changes, and preserved traceroute or MTR output if routing is suspected. Include whether the VPS remained reachable and whether another destination behaved differently, while avoiding claims about the root cause that the evidence does not support.