Es adecuado en estos casos:

• Usas RustDesk con frecuencia para acceder en remoto a tus propios ordenadores.
• No quieres depender de los servidores públicos predeterminados.
• Tienes varios dispositivos que necesitan mantenimiento remoto a largo plazo.
• Quieres que el nodo de retransmisión esté más cerca de ti, por ejemplo Hong Kong, Japón, Singapur o la costa oeste de EE. UU.
• Puedes aceptar abrir algunos puertos específicos de RustDesk.

No es adecuado en estos casos:

• Solo ayudas a un amigo en remoto de forma ocasional.
• No tienes un VPS público y solo quieres ejecutarlo en un NAS doméstico.
• No puedes abrir puertos UDP.
• Esperas cuentas completas, permisos, auditoría y gestión de equipos como en un producto comercial de control remoto.

Si solo necesitas control remoto temporal, usar los servidores predeterminados de RustDesk es más sencillo. El valor del autoalojamiento es: estabilidad, control y latencia más predecible.

El punto donde más fácilmente se producen errores con RustDesk Server son los puertos.

Según la documentación oficial, el servicio autoalojado OSS implica principalmente estos puertos:

Si no usas el Web Client, los puertos principales son:

TCP: 21115, 21116, 21117
UDP: 21116

21118 y 21119 no son puertos necesarios para el cliente de escritorio; están relacionados principalmente con el Web Client. Al empezar a diagnosticar, puedes abrir primero el conjunto completo de puertos y, una vez que todo funcione, restringirlos según las necesidades reales.

RustDesk Server no consume mucha CPU ni memoria, pero sí consume calidad de red.

Configuración mínima:

Lo que realmente importa es:

• La latencia del VPS hasta tu ubicación.
• Si es estable en las horas punta de la noche.
• Si el ancho de banda de subida y bajada es suficiente.
• Si UDP funciona correctamente.
• Si la cuota de tráfico es suficiente.

Si principalmente accedes en remoto a un ordenador de casa desde China continental, Hong Kong, Japón, Singapur y la costa oeste de EE. UU. suelen ser más adecuados que Europa. Los VPS europeos son muy baratos, pero cuando la latencia del control remoto es alta, mover el ratón resulta muy incómodo.

Este artículo asume:

• Ubuntu 22.04 / 24.04 o Debian 12.
• Docker y Docker Compose ya instalados.
• Tienes un dominio accesible desde el exterior, por ejemplo rustdesk.example.com, o puedes usar directamente la IP pública del VPS.
• El firewall y el grupo de seguridad del proveedor cloud son configurables.

Confirma Docker:

docker version
docker compose version

Crea el directorio:

sudo mkdir -p /opt/rustdesk-server
sudo chown -R "$USER":"$USER" /opt/rustdesk-server
cd /opt/rustdesk-server
mkdir -p data

El directorio data es importante; en él se guardan las claves generadas por RustDesk Server. Si se pierde este directorio, la Key configurada en los clientes dejará de coincidir y tendrás que reconfigurar todos los dispositivos después.

Crea docker-compose.yml:

nano docker-compose.yml

Escribe el siguiente contenido, sustituyendo rustdesk.example.com por tu dominio público o la IP pública del VPS. No pongas un nombre de contenedor, un nombre de host interno ni una dirección que solo se resuelva en el propio servidor; el cliente debe poder acceder desde la red externa.

services:
  hbbs:
    image: rustdesk/rustdesk-server:1.1.15
    container_name: hbbs
    command: hbbs -r rustdesk.example.com:21117
    volumes:
      - ./data:/root
    ports:
      - "21115:21115"
      - "21116:21116"
      - "21116:21116/udp"
      - "21118:21118"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    image: rustdesk/rustdesk-server:1.1.15
    container_name: hbbr
    command: hbbr
    volumes:
      - ./data:/root
    ports:
      - "21117:21117"
      - "21119:21119"
    restart: unless-stopped

Aquí hay varios puntos clave:

• hbbs -r rustdesk.example.com:21117 indica al cliente la dirección del servidor de retransmisión.
• ./data:/root se usa para persistir las claves.
• 21116 necesita tanto TCP como UDP.
• hbbs y hbbr comparten el mismo directorio data.
• El ejemplo fija rustdesk/rustdesk-server:1.1.15; al actualizar más adelante, puedes consultar primero Docker Hub / GitHub Release y luego cambiar manualmente el número de versión.

Si usas una IP simple, también puedes escribir:

command: hbbs -r 1.2.3.4:21117

La ventaja de un dominio es que, si cambias de VPS en el futuro, solo tienes que cambiar el DNS y no rellenar la IP en cada cliente.

Ejecuta:

docker compose up -d

Comprueba los contenedores:

docker compose ps

Consulta los logs:

docker compose logs -f --tail=100

Normalmente, hbbs generará un conjunto de claves. Puedes leer los archivos directamente:

ls -l data
cat data/id_ed25519.pub

También puedes buscar la Key en los logs:

docker logs hbbs 2>&1 | grep -i key

La Key que los clientes deben rellenar después suele ser el contenido de id_ed25519.pub.

Si UFW está activado en el VPS:

sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcp
sudo ufw reload

Si confirmas que no usas el Web Client, puedes no abrir 21118 y 21119. Pero en la fase de diagnóstico para principiantes es más sencillo abrir el conjunto completo de puertos; restringe después de confirmar la conectividad.

No olvides el grupo de seguridad del panel del proveedor cloud. Algunas personas configuran correctamente ufw allow dentro del VPS, pero el panel cloud sigue bloqueando, y al final nunca consiguen conectar.

Comprueba los puertos en escucha:

ss -lntup | grep 211

Deberías ver puertos como 21115, 21116 y 21117.

Abre el cliente RustDesk:

Settings -> Network -> ID/Relay Server

Formas habituales de rellenarlo:

ID Server: rustdesk.example.com
Relay Server: rustdesk.example.com
API Server: 留空
Key: 粘贴 data/id_ed25519.pub 的内容

Si no tienes dominio, rellena la IP pública del VPS. Aquí debes poner una dirección pública a la que el cliente pueda acceder; no pongas hbbs, localhost, 127.0.0.1 ni una dirección de red interna de Docker.

Ambos dispositivos deben tener el mismo servidor y la misma Key. Después de rellenarlos, reinicia el cliente RustDesk o desconecta y vuelve a conectar.

Si la configuración es correcta, el cliente normalmente muestra un estado de conexión al servidor normal en la parte inferior. Luego usa un dispositivo para conectarte al otro y probar.

RustDesk usa conexión directa cuando puede y solo pasa por la retransmisión cuando la conexión directa falla. El hbbs del servidor autoalojado coordina primero el hole punching y, si falla, reenvía a través de hbbr.

Puedes determinarlo de varias formas:

• Mira la información de conexión del cliente.
• Comprueba si los logs de hbbr tienen registros de conexión.
• Observa si el tráfico del VPS aumenta claramente durante el control remoto.
• Usa iftop o nload para ver el tráfico del puerto 21117.

Instala nload:

sudo apt update
sudo apt install -y nload
nload

Si el tráfico saliente del VPS aumenta claramente durante el control remoto, lo más probable es que esté pasando por la retransmisión.

Esto también te recuerda algo: si retransmites con frecuencia transferencias de archivos grandes, el tráfico del VPS se consumirá rápido. El escritorio remoto en sí no está mal; las transferencias de archivos y las imágenes de alta resolución son lo que realmente consume tráfico.

Los puertos principales de RustDesk no son servicios HTTP normales, así que no puedes simplemente hacerles reverse_proxy 127.0.0.1:21117 como a un sitio web y listo.

Si solo despliegas OSS RustDesk Server, se recomienda abrir directamente los puertos principales 21115-21117 y no forzar un proxy inverso HTTP normal sobre ellos.

Los escenarios opcionales 21118, 21119 y Web Client son donde entra el proxy WebSocket / HTTPS. La mayoría de usuarios individuales no necesitan tocarlo al principio; es más importante conseguir que funcione el cliente de escritorio.

Si tu red solo permite salida por 443, RustDesk también tiene una solución 443 más compleja, pero eso ya no es un despliegue de nivel inicial. Este artículo cubre primero el método de puertos estándar, el más estable y fácil de diagnosticar.

Esto es muy importante.

Haz copia de seguridad del directorio data:

cd /opt/rustdesk-server
mkdir -p /opt/backups/rustdesk-server

tar czf /opt/backups/rustdesk-server/rustdesk-server-$(date +%F-%H%M).tar.gz data docker-compose.yml

Lo más seguro es hacer copia de seguridad de todo el directorio data. Como mínimo, conserva el archivo de clave privada:

data/id_ed25519

data/id_ed25519.pub es la clave pública que rellenan los clientes, y es importante, pero lo que realmente determina la identidad del servidor es la clave privada id_ed25519. Si se pierde la clave privada, el servidor genera un nuevo conjunto de claves, la Key que los clientes tenían configurada deja de ser válida y tendrás que reconfigurar cada dispositivo. Con pocos dispositivos no pasa nada, pero con una docena es muy molesto.

Se recomienda sincronizar la copia de seguridad a un segundo lugar, como otro VPS, un NAS, almacenamiento de objetos o un disco en la nube cifrado.

Haz copia de seguridad antes de actualizar:

cd /opt/rustdesk-server
tar czf /opt/backups/rustdesk-server/before-upgrade-$(date +%F-%H%M).tar.gz data docker-compose.yml

Luego busca una nueva versión y modifica la etiqueta de imagen en docker-compose.yml, por ejemplo de 1.1.15 a una nueva versión estable.

Descarga la nueva imagen:

docker compose pull
docker compose up -d

Consulta los logs:

docker compose logs -f --tail=100

Después de actualizar, conecta realmente una vez con dos dispositivos; no des por hecho que todo está bien solo porque el contenedor esté Up.

No recomiendo usar latest a largo plazo en un tutorial. Para pruebas personales vale por comodidad, pero en uso real es más estable fijar una versión y también es más fácil revertir si algo falla.

RustDesk Server existe para que los clientes se encuentren entre sí; no es un sistema backend tradicional, pero tampoco conviene ignorar por completo la seguridad.

Recomendaciones:

• No dejes expuesto el inicio de sesión con contraseña root del VPS.
• Abre en el firewall solo los puertos necesarios.
• Si no usas el Web Client, no abras 21118/21119.
• Actualiza puntualmente las imágenes de Docker y los parches del sistema.
• Haz copia de seguridad del directorio de claves data, especialmente de la clave privada id_ed25519.
• No envíes la clave privada del servidor a otras personas.
• Activa contraseñas fuertes y confirmación de conexión en los clientes.
• No des acceso desatendido a largo plazo a desconocidos.

Si lo usas con familiares o un equipo, es mejor acordar de antemano: qué dispositivos permiten acceso desatendido y qué dispositivos deben confirmarse manualmente. Las herramientas de escritorio remoto son realmente cómodas, pero conceder permisos equivocados también es realmente peligroso.

Revisa una vez antes del uso formal:

• Los contenedores hbbs y hbbr están en ejecución.
• 21115/tcp, 21116/tcp, 21116/udp, 21117/tcp están abiertos.
• Si usas el Web Client, 21118/tcp, 21119/tcp están gestionados; si no, permanecen cerrados.
• hbbs -r contiene un dominio público o la IP pública del VPS accesible por los clientes.
• El ID Server, el Relay Server y la Key del cliente están rellenados.
• Todo el directorio data está respaldado, especialmente la clave privada data/id_ed25519.
• Se ha probado una conexión real entre dos dispositivos.
• La transferencia de archivos y el acceso desatendido se han probado según sea necesario.
• El tráfico y el ancho de banda del VPS son suficientes.

Si solo accedes en remoto de vez en cuando, los servidores públicos predeterminados de RustDesk son suficientes.

Si accedes con frecuencia en remoto a tus propios ordenadores, NAS o equipos familiares, o no quieres dejar la calidad de la conexión a los servidores públicos, autoalojar RustDesk Server merece mucho la pena. No exige mucho del VPS; lo realmente clave es la ruta de red, la apertura de puertos y la copia de seguridad de las claves.

Mi consejo: primero ponlo en marcha en un VPS barato pero con ruta estable y pruébalo durante 3-5 días. Si el control remoto va fluido incluso en horas punta, entonces ve migrando poco a poco los dispositivos de casa y de la oficina. No cambies todos los dispositivos de golpe; verifica primero y migra después.