If OBS reports dropped frames while streaming from a Contabo VPS to YouTube, first confirm that the network-dropped counter is rising; rendering lag and encoding lag point to different problems. Then compare your configured bitrate with repeatable upload-throughput measurements, check YouTube’s ingest guidance and stream health, and preserve route and resource evidence if drops continue.
A VPS port-speed figure is not proof of the sustained throughput or route quality between your particular VPS and YouTube. Lowering bitrate is useful only when the measurements support it, and it cannot correct every route, resource or encoder problem.
Start with the counter that is actually rising
Open OBS’s Stats window while the stream is running. The labels matter: Dropped Frames (Network) indicates that frames are not reaching the streaming server as expected. Frames Missed Due to Rendering Lag and Skipped Frames Due to Encoding Lag describe other stages of the pipeline. Do not treat all three as one generic dropped-frame problem.
Record the counter before and after a representative test rather than relying on a brief glance. Note the test’s start and end time, the stream’s configured video bitrate, and whether the network counter rises continuously, in bursts, or not at all. A counter that stays still while viewers report buffering is a different symptom; OBS’s buffering troubleshooting guide distinguishes sender-side drops from playback problems at the viewer’s end.
If network drops are rising, start with the connection and bitrate path. If rendering lag rises, inspect the scene composition and the VPS’s ability to render it. If encoding lag rises, inspect the selected encoder and available resources. A complicated browser source or animated overlay may burden a VPS that lacks the GPU features you expect from a desktop machine. For those symptoms, follow OBS’s encoding performance guidance, which discusses reducing output resolution or frame rate and simplifying costly scenes.
This distinction is especially useful for a channel intended to run overnight. Changing bitrate in response to encoding lag may reduce picture quality without relieving the encoder. Likewise, switching encoders because the network counter is rising may not help if the encoder is keeping up and the connection is stalling.
Use the OBS log to find the failure pattern
Save the log for the session in which the counter rises. OBS’s connection troubleshooting guidance explains that dropped frames usually relate to connection stability or a configured bitrate the connection cannot sustain; it is not the same diagnosis as an overloaded renderer or encoder. Read the log alongside the Stats window, and note the time when a stall starts and ends.
Look for a repeatable pattern rather than a single alarming line. Do drops begin after the stream has run for a while, only during a busy part of the day, or immediately when the bitrate changes? Do they continue when the scene is static, or only when the VPS is doing more work? A timestamped pattern gives you something to compare with resource readings and throughput tests.
Keep a copy of the full log, not only a cropped screenshot of the last message. Record the OBS version, operating system, output resolution and frame rate, selected encoder, configured bitrate, connection type and any relevant changes you made. If a log contains account identifiers or stream keys, remove those before sharing it. Your stream key is a credential; it should never be included in a public post or support ticket.
When changing a setting, write down the original value, the new value, the time, and what happened to each counter during the next comparable test. This makes it possible to reverse an unsuccessful change and avoids confusing correlation with cause. If the network counter is rising but encoding and rendering counters remain quiet, focus your first tests on throughput and the route to the ingest server.
Measure sustained upload throughput from the VPS
Run the measurement from the VPS itself, not from your home computer. A home connection test says nothing about the VPS’s outbound path. Measure upload throughput to a suitable test endpoint more than once, including during a period that resembles the stream’s usual operating conditions. Record the time, endpoint, result and test method so a later comparison is meaningful.
A single speed-test peak is not a stable stream capacity. Short tests can miss variation, competing traffic and route changes; a test to one destination does not prove equivalent performance to YouTube’s ingest. If other services are using the VPS’s network connection, note that activity as well. A stream must fit below the capacity that remains dependable, not merely touch a best-case result.
OBS suggests starting around 75% of total upload speed in its connection guide. Treat this as a troubleshooting starting point, not a guarantee or a target to force onto every VPS. Repeatable measurements, variation between results, other traffic and the route to the destination all affect how much headroom you need. The OBS stream connection guide is the primary reference for the counter and connection checks.
Do not substitute a Contabo product’s advertised port speed for a throughput measurement. Contabo’s bandwidth policy describes VPS and VDS port speeds ranging from 100 Mbps to 1 Gbps, along with fair-use conditions. That describes the provider’s service terms; it does not establish the sustained capacity of your particular route to YouTube or show that Contabo caused a drop.
For a 24/7 channel, repeat the measurement at different times if the pattern suggests time-of-day variation. Do not leave a high-load test running without considering its effect on a live broadcast or other services. If the only evidence is one result from an unrelated endpoint, gather more relevant measurements before making a permanent bitrate change or attributing the fault to the provider.
Lower bitrate only when the measurements justify it
Compare your configured video bitrate with the stable throughput observed from the VPS. If the bitrate is close to or above what repeated tests can sustain, test a lower value and watch whether the network-dropped counter’s rate changes. Choose a conservative value that leaves room for variation and any other traffic; do not treat the highest test result as a safe constant.
Make one change at a time. Keep resolution, frame rate, scene, ingest selection and test conditions consistent where possible. Note the before-and-after bitrate and the counter behaviour. If the network drops reduce under a comparable test, that supports a capacity mismatch as part of the problem. It does not prove every future drop has the same cause, nor does it prove the new setting is right for the final picture quality.
A lower bitrate can make motion look softer or blockier, particularly in detailed scenes. YouTube’s recommended ranges depend on codec, resolution and frame rate, so a value suitable for a simple static image may not suit a moving devotional video, a news loop or a lofi visual. If picture quality becomes the limiting factor, the article on why a YouTube live stream can look blurry at high bitrate is relevant: bitrate alone does not determine how the result looks.
Dynamic bitrate adjustment can be a temporary congestion workaround, but it is not a diagnosis of the underlying route or service. If a conservative, measured bitrate still produces network drops, do not keep lowering it indefinitely without checking the route, network settings and VPS resource evidence. If the other OBS counters are rising instead, return to the matching rendering or encoding checks.
Match YouTube ingest settings and check stream health
Use the current YouTube Live encoder settings for the codec, resolution and frame rate you have selected. YouTube’s page gives recommended bitrate ranges, specifies CBR, recommends a two-second keyframe interval and says not to exceed four seconds. Treat its bitrate figures as platform guidance, not an instruction to push a stream rate that your measured VPS connection cannot sustain.
For example, YouTube’s current guidance lists H.264 recommendations of 17 Mbps for 1080p60 and 14 Mbps for 1080p30. Those examples illustrate why the selected frame rate matters; they do not establish that either rate is appropriate for your route or your visual material. Check the current table before configuring a new stream, since codec and output choices affect the recommendation.
Check the Live Control Room’s stream-health diagnostics during a test. Use a representative section of your actual material, including its usual motion and audio, instead of judging stability from a static slate. Compare the stream-health status and OBS’s counters at the same timestamps. If YouTube reports a problem while OBS shows no sender-side network drops, keep those findings separate rather than assuming they describe the same fault.
YouTube recommends RTMPS in its encoder guidance. Confirm that OBS is using the intended ingest and connection settings, and do not share your stream key while asking for help. If another ingest server is available, a carefully recorded test to that server can help isolate a route-specific issue. Change only one variable at a time, return to the original setting if the comparison is inconclusive, and do not assume a different ingest will solve a resource problem.
Isolate route, settings and VPS resource variables
If the bitrate sits comfortably below repeatable throughput but network drops persist, check route and local configuration variables before concluding that the VPS provider is at fault. Review the OBS connection guide for supported diagnostic steps, such as trying another available streaming server and ensuring Bind to IP is set to Default. On a Linux VPS, do not apply Windows-only instructions about network optimisations or TCP pacing as if they were universal fixes.
Check what else is running on the VPS and whether it shares the outbound connection. Record CPU, memory and disk readings during a drop period, and note any service restarts or network-interface changes. Resource pressure may coincide with the symptom, but CPU load by itself does not demonstrate packet loss. Compare the readings with the exact time in the OBS log and the Stats window.
Review the operating system’s firewall, VPN or security software, if present, and any network-priority tooling. Make one diagnostic change at a time and record it. Avoid disabling protections or altering production settings broadly just to see what happens; choose a controlled test and restore the prior setting when it makes no difference.
If your wider workflow uses OBS to play a long playlist, a skipped source or restart issue can look like a stream problem while having a different cause. The guide to OBS skipping videos in a 24/7 YouTube study stream covers that separate symptom. For a file-based channel whose main need is restarting a broadcast process after it stops, see how to restart FFmpeg automatically for a 24/7 YouTube music stream; it is a different workflow, not a fix for an OBS route issue.
Build an evidence pack before contacting Contabo
For a persistent issue, assemble evidence that can help distinguish a route problem from a VPS resource or configuration problem. Include the time zone and exact timestamps for a drop period, the affected application, the configured bitrate, output settings, the OBS log, and the Stats-window counters before and during the issue. Say whether a lower bitrate changed the drop pattern, and describe how you tested it.
Add repeated throughput measurements with the test endpoint and times, plus a traceroute to a relevant destination where practical. A traceroute is a record of the path responses you received, not conclusive proof of which network operator is responsible for a fault. Preserve the command or tool used and the complete output. Do not infer an exact YouTube route from a test to a different destination.
Include CPU, memory and disk readings around the event; the VPS operating system; active services and ports relevant to the stream; traffic type; and any network-interface or NIC settings you changed. Contabo’s server slowness troubleshooting guidance asks customers to gather several of these kinds of details when reporting a slow server. Keep the report factual: list the observations and tests, not a conclusion unsupported by them.
You can also note whether the issue occurred on more than one test, whether a different ingest behaved differently, and whether any other outbound service was active. Do not include a password, stream key or other credential. A useful evidence pack lets support investigate a specific time and symptom; it does not guarantee a particular diagnosis or resolution.
When it is reasonable to contact Contabo
Contact Contabo when you have repeatable drops at a conservative bitrate, a relevant throughput or route anomaly, or resource behaviour that needs provider-side investigation. Share the evidence pack and ask a narrow question: for example, whether they can inspect the VPS’s network or resource condition for the supplied timestamps. If your tests instead point to OBS encoding lag or a configuration issue, address that with the matching OBS guidance first.
Contabo publishes port-speed and traffic-policy information, but those service descriptions are not proof of sustained throughput to YouTube. Check the current account policy for your exact product and plan in the customer panel or with support. Contabo also publishes traffic rules that discuss package allowances and possible throttling under stated conditions; those rules should not be confused with a diagnosis of packet loss or routing on your particular stream.
When you write, include the affected application, issue start time, traffic type, active services and ports, relevant NIC changes, traceroute and resource readings. Attach the OBS log with the stream key removed, and state the bitrate and whether lowering it changed the counter. If you have only a single speed test or a general impression that the server is slow, say so plainly and ask what additional measurement they need.
For a channel that must keep running while your own computer is off, moving the stream off a VPS running a locally managed OBS session may remove the burden of maintaining that computer-side broadcast process. StreamNeo turns an uploaded video into a YouTube live stream, so you do not need to keep that local OBS machine running for a file-based channel; it is YouTube-only and does not diagnose a route problem in the VPS you are troubleshooting.
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 every OBS dropped-frame warning mean Contabo is at fault?
No. First confirm that the network-dropped counter is the one rising, then compare the OBS log, measured throughput and route evidence. A provider or route issue is one possibility, not a conclusion from the counter alone.
Should I set the bitrate to 75% of my Contabo port speed?
No. OBS’s 75% suggestion refers to total upload speed as a troubleshooting starting point, not a rule for applying a VPS port-speed figure. Measure repeatable throughput from the VPS and leave headroom for variation and other traffic.
Will lowering bitrate fix dropped frames?
It can help when the configured bitrate exceeds what the connection can sustain, but it may reduce picture quality and does not fix every route, encoder or rendering issue. Compare counters during a controlled test and stop lowering the rate if the evidence points elsewhere.
What should I send Contabo support?
Send timestamps, the OBS log with credentials removed, the configured bitrate, counter behaviour, repeated throughput results, resource readings and a traceroute if available. Explain what you changed and whether it altered the symptom, without presenting an unverified cause as fact.