RustDesk conectado, esperando imagen: guía completa de solución

Si RustDesk muestra “Conectado, esperando imagen” y después aparece una pantalla negra, la buena noticia es que la parte difícil ya funcionó: los dos extremos se encontraron y la sesión está establecida. Lo que falta es la imagen. Algo en el equipo remoto no está generando una imagen de pantalla para enviar. Esta guía repasa todas las causas conocidas, desde la más común hasta los casos límite, con una solución concreta para cada una.

La respuesta corta

La sesión se conectó, pero no hay ningún framebuffer que capturar. En un equipo remoto sin monitor, con la pantalla en reposo o bloqueada, o con una pantalla que el sistema operativo no deja grabar a RustDesk, el flujo de vídeo no tiene nada que codificar. Dale a RustDesk una pantalla real y activa para capturar: un monitor, un conector HDMI simulador, el permiso correcto o un códec compatible, y la imagen aparecerá.

Empieza por aquí: ¿hay algo que capturar?

Con diferencia, la causa más reportada es un equipo sin monitor (headless): un servidor, un mini-PC o una estación de trabajo que funciona sin monitor conectado, o con la pantalla en reposo. Sin una pantalla activa, la GPU no genera ningún framebuffer, así que RustDesk se conecta pero no tiene nada que enviar. Este patrón aparece repetidamente en el rastreador de incidencias de RustDesk, incluidos informes de pantallas negras específicamente cuando el monitor del equipo de destino está apagado y el extenso hilo sobre “Conectado, esperando imagen”.

Tres maneras de darle algo que capturar:

• Conecta un monitor y asegúrate de que esté encendido y activo.
• Usa un conector HDMI (o DisplayPort) simulador. Estos adaptadores económicos hacen que la GPU crea que hay una pantalla conectada, de modo que sigue renderizando un framebuffer para que RustDesk lo capture. Esta es la solución estándar para equipos de escritorio sin monitor y servidores domésticos.
• En Linux, usa la ruta sin monitor documentada. RustDesk admite configuraciones de Linux sin monitor, pero la configuración difiere de una sesión de escritorio normal; consulta el wiki de compatibilidad con Linux sin monitor.

Si sí hay un monitor conectado, el siguiente sospechoso es que haya entrado en reposo.

Solución según la causa

Reposo, bloqueo y salvapantallas

Si funcionaba antes y se puso en negro después de que el equipo estuviera inactivo, la pantalla entró en reposo.

• Windows: configura el plan de energía para que la pantalla y el equipo nunca entren en reposo durante las horas en que necesites acceso remoto, y desactiva el salvapantallas (o configúralo para que no requiera contraseña durante la sesión).
• macOS: evita que la pantalla entre en reposo durante las horas en que necesites acceso remoto; configúralo en Configuración del Sistema → Pantallas (o en los ajustes de Bloqueo de pantalla / Energía), y mantén el Mac conectado al adaptador de corriente, ya que el reposo se comporta de forma distinta con batería.
• Android: la pantalla debe estar encendida para poder compartirla, así que toca la pantalla para activarla antes de conectar. Conectar desde iOS a un dispositivo Android en reposo con la pantalla apagada es un caso conocido de “esperando imagen”; activa primero el dispositivo de destino.

Permisos de macOS

macOS se niega a dejar que cualquier aplicación grabe la pantalla sin un consentimiento explícito. Si RustDesk se conecta pero la pantalla permanece negra en un Mac, abre Configuración del Sistema → Privacidad y seguridad → Grabación de pantalla y activa RustDesk, luego reinicia la aplicación. Una pantalla negra específicamente en la ventana de inicio de sesión significa que el servicio o ayudante de RustDesk no está instalado para ejecutarse antes de que un usuario inicie sesión: instálalo para permitir la captura previa al inicio de sesión.

Códec de vídeo incompatible

RustDesk puede codificar el flujo de varias formas, y la opción predeterminada no siempre se adapta al hardware remoto. En la barra de herramientas de la sesión (o en Configuración), cambia el códec —VP8, VP9, AV1 o H.264/H.265 donde el hardware lo admita— y comprueba si la imagen aparece. Si un códec por hardware produce una imagen en blanco en una GPU concreta, volver a un códec por software como VP9 es la solución más fiable.

Aceleración por hardware y controladores de GPU

Algunas GPU —las configuraciones NVIDIA son las que más aparecen— entran en conflicto con las rutas de captura y renderizado acelerado por hardware de RustDesk. Hay dos palancas que ayudan:

• Desactiva el códec por hardware. En la barra de herramientas de la sesión (o en Configuración), desactiva Usar códec por hardware para que la codificación recurra a una ruta por software; esto elimina la pantalla negra en muchas GPU problemáticas.
• Actualiza el controlador de la GPU. Una pantalla negra que empezó tras una actualización del controlador o del sistema operativo suele solucionarse pasando a un controlador actual, especialmente en hardware NVIDIA.

Linux y Wayland

En Linux, la captura de pantalla en Wayland pasa por PipeWire y el xdg-desktop-portal: la primera vez solicita consentimiento para elegir una pantalla —en la mayoría de los casos la elección se recuerda, así que no vuelve a preguntar— y funciona dentro de una sesión de inicio de sesión activa. Se trata de un diseño de seguridad propio de Wayland, así que por sí solo no cubre la pantalla de bienvenida (greeter) ni un equipo realmente sin monitor, aunque la captura desatendida en Wayland está en desarrollo activo (PR #15420). Si obtienes una pantalla en blanco en Wayland, la solución suele ser aceptar el aviso de compartir pantalla del portal y confirmar que xdg-desktop-portal y PipeWire están instalados y en ejecución; en un equipo sin monitor, usa la configuración sin monitor documentada. Iniciar sesión en una sesión X11/Xorg también evita la ruta del portal donde una distribución todavía la ofrezca, pero como muchas distribuciones avanzan hacia Wayland exclusivamente, solucionar la ruta del portal/PipeWire es el enfoque más preparado para el futuro.

Red y relé

Como el mensaje contiene la palabra “conectado”, la sesión normalmente ya está activa, pero el vídeo puede seguir estancado si el relé está sobrecargado o un puerto del relé está bloqueado. Para la ruta de servidor estándar, asegúrate de que TCP 21115-21117 y UDP 21116 sean accesibles de extremo a extremo. Abre TCP 21118-21119 solo si usas clientes WebSocket. El servidor de demostración público es compartido y su rendimiento no está garantizado, así que si dependes de RustDesk a diario, autoalojar tu propio relé te da un comportamiento mucho más constante. Si la sesión en sí se corta o nunca llega a establecerse, eso es un problema distinto; consulta las preguntas frecuentes de RustDesk Server Pro.

Mantén todo actualizado

Las versiones antiguas arrastran errores de captura antiguos. Actualiza tanto el cliente que controla como el cliente controlado a la última versión, y si autoalojas el servidor, actualízalo también. Varios informes de pantalla negra simplemente desaparecen después de actualizar ambos extremos.

La ventaja del código abierto

Cuando una pantalla negra desafía la lista de comprobación, RustDesk te ofrece algo que las herramientas de código cerrado no dan: el código de captura real bajo licencia AGPL. Tú (o un contratista) puedes leer exactamente cómo funciona la captura en tu plataforma, reproducir el problema y presentar un informe preciso en el repositorio público, en lugar de esperar en la cola de soporte de un proveedor.

Menos variables cuando el servidor es tuyo

Ejecuta tu propio relé y servidor de ID, y la infraestructura pública compartida deja de formar parte de la ecuación: una incógnita menos cuando estás persiguiendo un problema de captura, y control total sobre las partes que puedes ajustar. Es una ventaja silenciosa, además de conservar los datos.