RustDesk Connected Waiting for Image: Full Fix Guide

If RustDesk says “Connected, waiting for image” and then shows a black screen, the good news is that the hard part already worked: the two ends found each other and the session is established. What’s missing is the picture. Something on the remote machine isn’t producing a screen image to send. This guide walks through every known cause, from the single most common one to the edge cases, with a concrete fix for each.

The short answer

The session connected, but there is no framebuffer to capture. On a remote machine with no monitor, an asleep or locked display, or a screen the OS won’t let RustDesk record, the video stream has nothing to encode. Give RustDesk a real, awake display to capture — a monitor, an HDMI dummy plug, the right permission, or a compatible codec — and the image appears.

Start here: is there anything to capture?

By far the most reported cause is a headless machine — a server, mini-PC, or workstation running with no monitor attached, or with the display asleep. With no active display, the GPU produces no framebuffer, so RustDesk connects but has nothing to send. This pattern shows up repeatedly in the RustDesk issue tracker, including reports of black screens specifically when the target’s monitor is off and the long-running “Connected, waiting for image” thread.

Three ways to give it something to capture:

• Attach a monitor and make sure it’s powered on and awake.
• Use an HDMI (or DisplayPort) dummy plug. These inexpensive adapters make the GPU believe a display is connected, so it keeps rendering a framebuffer for RustDesk to grab. This is the standard fix for headless desktops and home servers.
• On Linux, use the documented headless path. RustDesk supports headless Linux setups, but the configuration differs from a normal desktop session — see the Headless Linux Support wiki.

If a monitor is attached, the next suspect is that it went to sleep.

Fix by cause

Screen sleep, lock, and screensavers

If it worked earlier and went black after the machine sat idle, the display went to sleep.

• Windows: set the power plan so the display and the machine never sleep during the hours you need remote access, and disable the screensaver (or set it not to require a password mid-session).
• macOS: stop the display from sleeping during the hours you need remote access — set it in System Settings → Displays (or Lock Screen / Energy settings), and keep the Mac on a power adapter, since sleep behaves differently on battery.
• Android: the screen must be on to be shared, so touch the display to wake it before connecting. Connecting from iOS to a dozing Android device with the screen off is a known “waiting for image” case — wake the target first.

macOS permissions

macOS refuses to let any app record the screen without explicit consent. If RustDesk connects but stays black on a Mac, open System Settings → Privacy & Security → Screen Recording and enable RustDesk, then restart the app. A black screen specifically at the login window means the RustDesk service/helper isn’t installed to run before a user logs in — install it for pre-login capture.

Video codec mismatch

RustDesk can encode the stream several ways, and the default doesn’t always suit the remote hardware. In the session toolbar (or Settings), switch the codec — VP8, VP9, AV1, or H.264/H.265 where hardware supports them — and watch for the image to appear. If a hardware codec produces a blank image on a particular GPU, dropping back to a software codec such as VP9 is the reliable move.

Hardware acceleration and GPU drivers

Some GPUs — NVIDIA configurations come up most often — clash with RustDesk’s hardware-accelerated capture and render paths. Two levers help:

• Turn off the hardware codec. In the session toolbar (or Settings), disable Use hardware codec so encoding falls back to a software path — this clears the black screen on many problem GPUs.
• Update the GPU driver. A black screen that started after a driver or OS update is frequently fixed by moving to a current driver, particularly on NVIDIA hardware.

Linux and Wayland

On Linux, Wayland screen capture goes through PipeWire and the xdg-desktop-portal: it prompts for consent to pick a display the first time — in most cases the choice is remembered, so it does not prompt again — and works inside an active login session. That is a Wayland security design, so by itself it does not cover the greeter or a truly headless box — though unattended Wayland capture is in active development (PR #15420). If you get a blank screen on Wayland, the fix is usually to accept the portal’s screen-share prompt and confirm xdg-desktop-portal and PipeWire are installed and running; on a headless box, use the documented headless configuration. Logging into an X11/Xorg session also avoids the portal path where a distribution still offers one — but as many distributions move to Wayland-only, fixing the portal/PipeWire path is the more future-proof approach.

Network and relay

Because the message contains the word “connected,” the session is usually already up — but the video can still stall if the relay is overloaded or a relay port is blocked. For the standard server path, make sure TCP 21115-21117 and UDP 21116 are reachable end to end. Open TCP 21118-21119 only if you use WebSocket clients. The public demo server is shared and its throughput isn’t guaranteed, so if you rely on RustDesk daily, self-hosting your own relay gives you far more consistent behavior. If the session itself is dropping or never establishing, that’s a different problem — see the RustDesk Server Pro FAQ.

Keep everything current

Old builds carry old capture bugs. Update both the controlling client and the controlled client to the latest release, and if you self-host, update the server too. Several black-screen reports simply disappear after an update on both ends.

The open-source advantage

When a black screen defies the checklist, RustDesk gives you something closed-source tools don’t: the actual capture code under an AGPL license. You (or a contractor) can read exactly how capture works on your platform, reproduce the issue, and file a precise report against the public repository — instead of waiting on a vendor’s support queue.

Fewer variables when the server is yours

Run your own relay and ID server, and the shared public infrastructure drops out of the picture — one less unknown when you are chasing a capture problem, and full control over the parts you can tune. That is a quiet bonus on top of keeping the data.