A black OBS preview or recording on an Oracle Cloud VPS usually points first to the capture source or the graphical session OBS can see. If the preview is working but YouTube receives no video, investigate the output and network path separately; OBS sends directly to the selected streaming service and does not relay your stream.
Start with a local test before changing OCI firewall rules, encoder settings or instance shape. The operating system, display session, source, instance and logs determine which cause is plausible, so there is no single fix that can be confirmed from the symptom alone.
Identify where the picture disappears
Look at the OBS preview, then make a short local recording and play it back. This distinguishes an image that OBS never captured from a working local image that fails somewhere between OBS and YouTube. If both preview and recording are black, begin with the scene, source and display session. If they contain the picture but the remote stream does not, move to the connection branch below.
A black preview is not proof of a network fault. OCI ingress rules are especially unlikely to explain a black local recording: recording does not depend on YouTube receiving the broadcast. Conversely, an intact preview does not prove that YouTube is receiving the stream. It only shows that OBS can render the local scene.
Use the symptom as a sorting clue, not a diagnosis:
| What you observe | Check first | What it does not establish |
|---|---|---|
| Preview and local recording are black | Scene visibility, capture method, display session, permissions and graphics | That OCI networking is broken |
| Preview and recording work, but YouTube has no picture | Service destination, stream state, credentials, outbound path and OBS log | That the capture source is broken |
| Preview works but OBS reports dropped frames | Network stability to the streaming endpoint and bitrate suitability | That a black preview is a network symptom |
| Hardware encoder is unavailable | GPU shape, drivers, OBS build and encoder compatibility | Whether display capture works |
If you are preparing a prerecorded channel rather than troubleshooting a live camera, the distinction still matters: a playback source can be visible locally while output is failing, or the source itself can be absent. The practical checks in a guide to continuously streaming prerecorded store adverts are useful context for separating content playback from delivery.
Check the VPS graphical and display session
On a Linux VPS, establish what desktop or display session actually exists, and whether the OBS process is running inside it. A remote desktop connection can make a desktop visible to you without proving that a separately launched OBS process shares that display. Likewise, logging in over SSH does not by itself create a screen containing pixels for Display Capture to read.
Record the details before changing anything: distribution and version, how you start OBS, whether you use X11 or Wayland, whether a remote desktop or virtual display is involved, and whether the session remains active after you disconnect. These details are more useful than a guess that the VPS needs a GPU. A visible desktop session and the graphics capability used to render it are related but distinct requirements.
OBS's Linux installation guidance lists OpenGL 3.3 or later and discusses X server prerequisites. Treat that as a compatibility check, not as proof that every OCI image or display setup will work. If OBS launches into a session that cannot initialise its graphics stack, the preview can fail before YouTube or its network path is relevant.
Check whether the desktop continues rendering when the remote session is closed or disconnected. Some configurations stop or change the display session when the client exits; others keep it running. Do not assume either behaviour. Reconnect, inspect the desktop, and test a local recording while the session state is known. If the image disappears only after disconnecting, document that timing and investigate the session manager or virtual-display configuration for your particular distribution.
If you have selected an OCI GPU shape, verify in the OCI console that the instance is actually using that shape and that it is available to your tenancy and region. Oracle documents compute shape availability and GPU limits; its GPU workstation tutorial is an example configuration, not a universal OBS recipe. A generic VPS should not be presumed to include a GPU, and having a GPU does not guarantee a usable desktop session.
Verify the selected OBS capture source
Open the scene that is meant to be live and inspect its sources. Confirm that the intended source exists, is enabled, is not hidden, and is selected in the scene you are viewing. In OBS, a source can be present in one scene while the active scene is another. A source may also be covered by an opaque image or colour source higher in the scene stack.
Open the source properties and check that they point to the intended display or window. Names can be ambiguous on a VPS with a virtual display, multiple monitors, or a remote desktop. If the source refers to a display that is no longer present, selecting it again may be necessary, but do that only after identifying the active display session. Otherwise a change of source can conceal the real session problem without resolving it.
Capture methods are not interchangeable. Display Capture targets a desktop; Window Capture targets a particular application window; a media source or browser source supplies its own content. Choose the source type that matches what you want viewers to see. If the goal is a looping video, a media source is conceptually different from trying to capture the desktop that happens to be playing it. The OBS capture troubleshooting notes describe source and capture-specific checks; apply the parts relevant to your OS and source rather than assuming a laptop-specific setting applies to an OCI VM.
Make one small test: add or select the intended source, confirm its visibility, then record briefly. Avoid changing the encoder, bitrate and display settings together. If the preview becomes visible, you have narrowed the issue to something in the source or scene path, but have not yet established why the prior source was black. If it remains black, note the source type and properties for the OBS log review.
This distinction is also useful when comparing two kinds of continuous video workflow. A MediaMTX and Raspberry Pi streaming setup uses a different path from desktop capture, so a black display source should not automatically lead you to alter a media-delivery workflow that is not in use.
Check scene sources and graphics support
Check the scene from the bottom upward. A hidden source, an eye icon turned off, a transform placing the source outside the canvas, or an opaque layer can make a valid source appear black. Confirm the canvas and source dimensions are sensible for the content, then use the preview to see whether the source is present but positioned or cropped unexpectedly.
Graphics support is another layer. OBS must initialise the graphics stack used by the session before it can render a preview. On Linux, consult the OBS installation guidance for its OpenGL requirement and applicable X server prerequisites. If the log reports graphics initialisation or context errors, capture that text and compare it with the operating system and display-session details; do not treat an encoder selection as a substitute for graphics support.
A GPU encoder and a display source solve different problems. OBS's hardware encoding guidance concerns encoding frames already available to OBS. It cannot create a desktop image if there is no accessible display to capture. Once capture works, choose an encoder supported by the actual hardware, drivers and OBS build. If no GPU is provisioned, software encoding may be the available path, subject to the workload and quality you need.
OCI GPU shapes may depend on availability and tenancy service limits, and an image may require compatible drivers. Oracle's platform images documentation and shape documentation are more appropriate references for those questions than an assumed universal instance recommendation. Compare configurations by whether the shape actually includes the GPU you need, whether it is available to your tenancy, whether drivers suit the image, and whether your workload needs GPU rendering or only encoding. None of those comparisons can establish that a capture source is fixed.
If you would rather avoid keeping a desktop session and OBS process available on your own VPS for a prerecorded YouTube channel, StreamNeo removes that specific burden: you upload a video and provide your YouTube stream key, then the broadcast can run without your computer staying on. It is YouTube-only, so it does not address a need to capture an interactive desktop or send the same stream to another platform.
If the preview works, diagnose the connection separately
When preview and recording show the intended picture, inspect OBS's selected service and destination settings. Confirm that the stream is configured for the correct platform and account, that the stream key is current, and that the YouTube stream is in the expected state. Do not include a stream key in screenshots or logs you share publicly. OBS's Help Portal explains its connection and dropped-frame categories; use the messages OBS actually reports rather than treating every failed output as a capture problem.
If OBS cannot connect or drops frames, then review outbound connectivity from the instance to the configured streaming destination. OCI identifies multiple relevant rule layers: network security groups, subnet security lists and the operating system firewall. Oracle's VCN troubleshooting documentation describes these layers. Check the rules that apply to your instance and the protocol and destination actually in use. Do not open broad ports speculatively.
Oracle Linux images may use firewalld, but the active OS firewall depends on the image and configuration. Confirm which firewall is running before changing rules. A connection timeout, authentication error and dropped-frame warning suggest different lines of investigation; preserve the exact OBS status and log messages. If the preview is black as well, return to capture checks rather than assuming a network change will produce pixels in the local scene.
If you run a YouTube playlist stream from a changing residential connection as a comparison, recovery options for a stream that goes offline after a JioFiber IP change discuss a different failure context. A VPS connection and a home connection have different network controls, so use the example to think about reconnection symptoms, not as a diagnosis of OCI rules.
Collect OBS logs and test one change at a time
Before changing settings, note the OBS version, Linux distribution, OCI shape, source type, encoder, display session type, and whether the preview and local recording are black. Then capture the OBS log from the session in which the symptom occurs. The useful evidence is often in the sequence of source initialisation, graphics or display errors, encoder initialisation, and output connection messages. A log from a different desktop session may not describe the failing run.
Change only one relevant setting between short tests. For example, if the selected capture source is wrong, correct that source and retest before changing the display session. If the source is correct but OBS reports graphics initialisation errors, investigate the graphics session before editing network rules. Keep a brief record of the original value, the single change, and the resulting preview, recording and output status. This makes it possible to undo an unhelpful change and avoids attributing an improvement to several simultaneous edits.
OBS notes that some security or firewall products can affect capture or connectivity. That possibility is not a reason to disable protection wholesale. Look for a relevant message in the log or a reproducible change in behaviour, and review the product's own documentation before altering it. For a 24/7 channel, make tests during a maintenance window or with a separate test scene where possible, so troubleshooting does not unintentionally interrupt the live programme.
For a useful support request, include the log, the source type and properties, the session details, and the exact point where the picture disappears. Redact credentials, stream keys and private account details. Without the OS, source, instance and logs, the root cause remains unresolved; a report that says only “OBS black screen on OCI” does not distinguish a missing display from a hidden source or a graphics error. General YouTube live-streaming checks before going live can help you verify the platform side once the local picture is confirmed.
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 is OBS black on an Oracle Cloud VPS?
There is not enough information to name one cause. A black preview and recording point first to the selected scene or source, the display session OBS can access, or graphics initialisation; the OS, source, instance and logs are needed to narrow it down.
Can I fix a black screen by changing my OCI firewall rules?
Not if the local OBS preview and recording are black: those symptoms occur before delivery to YouTube. Firewall and OCI network-rule checks belong to the separate branch where the local picture works but the stream cannot connect or drops frames.
Does a GPU encoder make Display Capture work?
No. An encoder handles frames that OBS has already captured; it does not create a display session or supply pixels to a capture source. Confirm the display and source first, then check encoder compatibility with the actual shape and installed drivers.
What should I send when asking for help?
Include the OBS log, OS and version, OCI shape, OBS version, display session type, source type, encoder, and whether preview and local recording work. Remove stream keys and other credentials before sharing anything.