Closing Remote Desktop does not always mean the same thing as signing out, and neither action tells you by itself whether an OBS stream is still usable. The answer depends on what OBS is capturing: test the stream after disconnecting RDP, and check the picture and sound from another device.
If OBS keeps streaming but its desktop or window capture freezes, an OBS startup option will not repair that capture path. Establish whether the problem is the OBS process, the interactive desktop, or the network before changing how the server is managed.
Identify what OBS is capturing
Open the scene that is live and inspect each source. A display capture records a desktop; a window capture records a particular application window. Browser sources, media files, cameras, capture devices and other inputs each have their own dependencies. The source name is only a clue: what matters is whether its actual output stays current after the remote session changes.
A loop made from a media file may not depend on the RDP desktop in the same way as a browser window showing a dashboard. But do not assume that every file or browser source is independent of the logged-in session. Observe its output during the test. Overlays, clocks, browser pages and audio devices can fail or change separately from the main picture.
Make a small source inventory before testing. Note the source that provides the main video, any text or graphics that update, and the source used for audio. If your channel uses a podcast archive, for example, the guide to streaming a video archive on YouTube may help with the content workflow, but it does not answer whether an RDP-dependent OBS source survives disconnection.
OBS's Quick Start Guide describes common video and audio sources and recommends testing a setup for a few minutes. Treat that as a starting point, not as evidence about your particular Hetzner machine. Your own scene, Windows configuration and remote access path decide the outcome.
Disconnecting is not signing out
There are several different actions people describe as “closing Remote Desktop”. You might close the RDP client window, choose Disconnect from its menu, sign out of Windows, or restart the server. They are not interchangeable. Disconnecting generally leaves a user session available to reconnect to; signing out ends that session and its applications may close. Exact behaviour also depends on the Windows and session configuration.
For the first test, disconnect the client without signing out. Do not choose Sign out, and do not restart. When the test ends, reconnect to the same session if possible and see what OBS reports. If you sign out during the initial experiment, an OBS process ending may simply show that the user session ended, not that an RDP disconnect alone caused the failure.
Closing the RDP window may itself send a disconnect, but confirm the choice shown by your client rather than relying on the window's close button. Avoid changing multiple variables at once. If you change session policy, launch method and capture source together, you will not know which change made a difference.
If the stream does stop after a disconnect, first distinguish that from a sign-out or reboot. Record the precise action, the time, and whether OBS was visible when you reconnected. A brief written note is more useful than a vague conclusion such as “Remote Desktop kills OBS”.
Run a controlled short test
Use a test stream that will not disrupt viewers. Set the YouTube broadcast to private or unlisted where that suits your channel, or use another safe test arrangement. Make sure you know how to stop the test and that you have access to the OBS scene and stream key. Do not expose the stream key while sharing screenshots or logs.
Start OBS and confirm that the intended scene is live. From a separate phone or computer, open the destination stream. Check the picture and sound before disconnecting RDP; this establishes a baseline. Then disconnect the remote client without signing out or restarting the host. Leave the test running long enough to see whether the actual content changes, rather than checking only immediately after the click.
Watch the destination from the separate device, not only OBS's local preview. A preview can look normal before disconnection and remain misleading if the outgoing feed has frozen. Check that moving elements still move, that a clock or ticker changes if one is present, and that the expected audio continues. A static scene may be hard to assess, so include an obvious motion or audio check in a temporary test scene if necessary.
Reconnect only after the observation period, then inspect OBS and the destination again. Repeat the test if the result is unclear, changing one thing at a time. This is not a benchmark or a guarantee about what will happen overnight; it is a practical check of the exact session and sources you intend to use.
Check the stream, not just its indicator
There are at least three useful outcomes. OBS may close or stop streaming; OBS may remain live while the captured image freezes or changes; or OBS and the content may both remain correct. These outcomes point to different next steps. The timer or “live” indicator alone cannot distinguish them.
If OBS is no longer running, investigate how it starts and which Windows session owns it. Check whether you disconnected or signed out, whether the application raised an error, and whether the server restarted. If OBS remains open but the source is black, stale or missing, focus on the capture and display path rather than reconnect settings.
If the image is right but sound is absent, check the audio source and device selection separately. If both picture and sound are correct but the stream accumulates dropped frames or disconnects, investigate network conditions and the connection to YouTube's ingest service. OBS's stream connection troubleshooting guide explains that dropped frames can indicate an unstable connection or an inability to sustain the configured bitrate. That is a different failure from a frozen desktop capture.
For a continuous channel, also consider whether the test scene represents the real one. A simple file loop could pass while a production scene with a browser overlay fails. Test the actual scene and the same audio path you plan to leave running. If you use podcast audio, the advice on normalising audio before a 24/7 YouTube stream concerns levels, not RDP persistence, so keep those checks separate.
What OBS startup options can and cannot do
OBS supports launch parameters including --startstreaming, --scene, --profile and --collection. They can open OBS with a selected configuration and, with --startstreaming, begin a configured stream. The OBS launch parameters documentation describes these controls. They automate application startup; they do not promise that a desktop or window source stays valid when an RDP display or session changes.
On Windows, if you use a scheduled task or another automation method, the OBS guide says to set “Start in...” to the folder containing obs64.exe. Verify the account, working directory, scene, profile and collection in a test before relying on unattended startup. A task that launches OBS is not proof that Windows will provide the same interactive display, source permissions or audio devices as an RDP session.
OBS WebSocket can provide remote control of OBS. It has been built into OBS Studio since version 28, and OBS advises enabling authentication and setting a password in its remote control guide. That can help you control or inspect the application, but it does not itself preserve a Windows desktop source. Keep control access separate from capture continuity.
For a file-based channel that repeatedly fails because an always-open desktop is part of the workflow, a managed cloud broadcast can remove the need to leave your own computer connected to an RDP session. StreamNeo turns an uploaded video into a YouTube live stream, so it avoids the specific problem of an OBS desktop capture changing when you disconnect from that computer; it is YouTube-only and does not solve a scene that requires live desktop interaction.
Understand Hetzner access paths
First establish what you rented. Hetzner documents a Windows Server add-on for dedicated servers with RDP access, while Windows installed on a Cloud server follows a separate path with licensing and architecture constraints. The relevant starting points are Hetzner's Windows Server 2025 information and its Windows on Cloud guide. The available configuration depends on your account and current product offering; do not infer it from the word “Hetzner” alone.
The provider's Cloud Console VNC access is a separate console function, not a promise that a Windows desktop session used by OBS will persist. Hetzner describes using the console for access and says in its FAQ that the console is intended for emergencies, with SSH recommended for routine management. Those pages do not establish that the VNC console preserves an OBS desktop session. Do not switch to it expecting a capture fix.
RDP is a way to access the Windows system; OBS's capture source and the display it sees are a separate matter. Some community reports describe capture changes after RDP disconnect, but a report about one machine is not a universal rule or a guarantee that another remote-access tool will help. If you have a physical dedicated server with a suitable graphics and display path, a tool that mirrors the existing console may be worth evaluating. On a cloud VM, verify that the required display path exists before planning around it.
Choose a configuration from the test
Use the observed failure to choose the next action. Avoid purchasing display hardware or changing server architecture until you know which source fails and whether your host is a cloud VM or a physical dedicated server.
| Test result | What it suggests | Practical next step |
|---|---|---|
| OBS closes or stops after you sign out | The user session or launch arrangement may be ending with the application | Test disconnect without signing out; then review startup and session settings |
| OBS remains live but desktop or window content freezes | The capture depends on a display or session state that changed | Test the specific source and display path; do not expect a startup flag to repair it |
| Picture and audio remain correct, but frames drop | The capture may be intact while the stream connection is unstable | Follow OBS network and ingest troubleshooting; review bitrate and connection conditions |
| File-based scene works, interactive overlay fails | Different sources have different dependencies | Replace, simplify or separately validate the dependent overlay |
If the channel requires a live desktop, browser interaction or a device attached to the host, keep that dependency visible in your design. Test any alternate remote-access or mirroring approach on the exact machine and source. A method that works with a physical GPU computer may not be available or behave the same way on a cloud VM.
If the channel is a prepared video loop with stable overlays, consider whether OBS is necessary for the whole workflow or whether a file-based broadcast method better matches the content. A different pipeline still needs testing for audio, overlays, looping, stream-key handling and YouTube ingest. A guide about FFmpeg continuing after an SSH session ends covers a different process and session type; it is not a drop-in answer for OBS desktop capture.
Keep access security in the decision as well. A stream key grants the ability to broadcast to the associated channel, so store it carefully and rotate it if exposed; the stream-key rotation walkthrough explains that separate issue. After testing, document the working scene, source types, launch method and exact disconnect action. Recheck after Windows, OBS or source changes rather than assuming a past test covers a new configuration.
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
Will OBS keep streaming if I close Remote Desktop?
It may, but the stream indicator is not enough to tell whether the captured content remains valid. Disconnect without signing out, then watch the output from another device and verify both picture and sound.
Should I sign out so the server can keep OBS running?
No: signing out ends the Windows user session and may close applications in it. Test a disconnect without signing out first, and use the exact action you intend to use in normal operation.
Does --startstreaming fix a frozen capture?
No. It can start OBS streaming as part of launching the application, but it does not ensure that an RDP-dependent desktop or window source survives a display or session change.
Can Hetzner's VNC console keep my OBS desktop session alive?
Hetzner documents the Cloud Console VNC facility as console access, not as a way to preserve an OBS graphical session. Verify your host type and capture path; do not treat emergency console access as an RDP persistence fix.