Desktop remoto em Linux sem monitor: sessões de desktop reais

Seu servidor é acessível, mas ao conectar você vê uma tela preta, um framebuffer virtual minúsculo ou ausência de aceleração de GPU — porque a máquina não tem monitor conectado. Este guia mostra como obter uma sessão de desktop real e utilizável em Linux sem monitor: opções de hardware e software, comandos passo a passo, unidades systemd, advertências sobre Wayland e como conectar com segurança (incluindo a opção de relay gerenciado da Tenvo).

O que 'desktop real' significa em uma máquina sem monitor

Por 'desktop real' quero dizer uma sessão que se comporta como se um monitor estivesse conectado: resolução em tela cheia, saída GPU adequada (quando aplicável), persistência de sessão entre reinícios, mapeamento previsível de teclado/mouse e a capacidade de rodar ambientes Wayland ou X11 em vez de um pequeno framebuffer 800×600 do Xvfb. Uma máquina headless pode apresentar um display virtual (emulação por software) ou físico (plug HDMI dummy ou KMS virtual). Sua escolha depende se você precisa de aceleração por GPU, recursos DRM/KMS ou simplesmente de um desktop interativo para administração.

Três abordagens práticas — escolha conforme a necessidade

• Plug HDMI dummy (hardware) — o mais simples para aceleração de GPU. Conecte um HDMI 'headless ghost' de $2 para simular um monitor; a GPU e o gerenciador de tela produzem uma sessão normal e resolução adequada.
• Virtual X / Xvfb ou driver dummy do Xorg + display manager — apenas software e amplamente compatível: cria uma sessão X11 completa que você pode expor via VNC (TigerVNC) ou compartilhar com x11vnc. Xvfb é o mais simples, mas não expõe KMS/ativação por GPU.
• RDP via xrdp (recomendado para muitos casos) — xrdp cria uma sessão X real (ou usa XorgXrdp) e fornece um endpoint RDP. Funciona bem em servidores headless porque não requer um display físico e é bem suportado por clientes Windows/macOS/Linux.

Opção A — Plug HDMI dummy (truque de hardware)

Se você precisa de aceleração por GPU (OpenGL, decodificação por hardware, saída de compositor Wayland) este é o truque mais rápido e confiável: compre um pequeno HDMI dummy (emulador EDID) que anuncia um monitor 1920×1080 ou 2560×1440. Conecte na saída HDMI da GPU, reinicie se necessário, e seu display manager (GDM, SDDM, LightDM) criará uma sessão normal. Sem gambiarras de software e sem framebuffers virtuais.

Prós: GPU real, sem alterações de configuração. Contras: acesso físico necessário; não é possível se o sistema não tiver conector de vídeo ou estiver em um rack lacrado.

Opção B — Sessão X virtual: Xvfb + desktop + TigerVNC (exemplo Ubuntu/Debian)

Use quando não for possível conectar um dummy ou quando a aceleração por GPU não for necessária. Isso produz uma sessão de desktop completa independente de monitor físico e funcionará em qualquer distro com X11.

sudo apt update
sudo apt install -y xvfb tigervnc-standalone-server xfce4 xfce4-goodies

# Create a dedicated VNC user (optional)
sudo adduser vncuser

# Example: start a persistent Xvfb display and XFCE
sudo -u vncuser Xvfb :99 -screen 0 1920x1080x24 &
export DISPLAY=:99
sudo -u vncuser startxfce4 &

# Start TigerVNC to expose :99 on TCP 5901
sudo -u vncuser x0vncserver -display :99 -passwordfile /home/vncuser/.vnc/passwd -forever -shared

# Or run tigervncserver directly if you want VNC-managed X sessions
sudo -u vncuser tigervncserver :1 -geometry 1920x1080 -depth 24

Unit systemd: faça o display persistir entre reinícios. Salve como /etc/systemd/system/xvfb-vnc.service (edite caminhos e usuário):

[Unit]
Description=Xvfb + desktop + VNC
After=network.target

[Service]
Type=simple
User=vncuser
Environment=DISPLAY=:99
ExecStart=/usr/bin/Xvfb :99 -screen 0 1920x1080x24
ExecStartPost=/usr/bin/sleep 1
ExecStartPost=/usr/bin/startxfce4
Restart=on-failure

[Install]
WantedBy=multi-user.target

Observações: Xvfb oferece apenas um framebuffer por software; aceleração por GPU não está disponível. Para muitas tarefas administrativas e aplicativos GUI isso é aceitável. Se você precisa de sessão com suporte a GPU, use o HDMI dummy ou o driver dummy do Xorg combinado com o driver da GPU (mais abaixo).

Opção C — Driver dummy do Xorg / servidor X headless (para sessões com display manager)

Em vez do Xvfb você pode configurar o Xorg para usar o driver de vídeo 'dummy', fazendo com que o display manager do sistema (GDM/LightDM) crie uma sessão de login normal na inicialização. Isso se aproxima mais de uma sessão com monitor real e às vezes oferece melhor compatibilidade que o Xvfb.

# Install Xorg dummy driver and a lightweight DE (Debian/Ubuntu)
sudo apt install -y xserver-xorg-video-dummy xfce4

# Example minimal /etc/X11/xorg.conf.d/10-dummy.conf
Section "Device"
  Identifier "DummyDevice"
  Driver "dummy"
EndSection

Section "Monitor"
  Identifier "DummyMonitor"
  HorizSync 28.0-80.0
  VertRefresh 48.0-75.0
EndSection

Section "Screen"
  Identifier "DummyScreen"
  Device "DummyDevice"
  Monitor "DummyMonitor"
  SubSection "Display"
    Depth 24
    Modes "1920x1080"
  EndSubSection
EndSection

Depois de criar essa configuração, habilite seu display manager e reinicie. O DM deve apresentar uma greeter normal e produzir sessões que você pode acessar com x11vnc (para compartilhar o desktop existente) ou via um servidor VNC conectado ao display X.

Opção D — xrdp: sessões RDP que funcionam bem em headless

xrdp é uma opção sólida porque cria uma sessão X sob demanda e fala RDP, protocolo amplamente suportado pelos clientes. Não depende de um monitor conectado e costuma ser a abordagem menos problemática para acesso GUI remoto em servidores.

sudo apt install -y xrdp xfce4 xfce4-terminal
# Configure XFCE for xrdp: create or edit /home/you/.xsession or /etc/xrdp/startwm.sh
echo "startxfce4" > /home/you/.xsession
sudo systemctl enable --now xrdp
# Open firewall for TCP/UDP 3389 only if you control the network; prefer an SSH tunnel or Tenvo relay

Em seguida, conecte-se com qualquer cliente RDP na porta 3389 ou via túnel SSH. xrdp pode usar XorgXrdp para melhor desempenho; verifique o empacotamento da sua distro para a versão compatível do xorgxrdp.

Wayland: limitações e opções

Compositores Wayland tratam saídas de forma diferente e historicamente têm suporte limitado ou inexistente para displays virtuais. GNOME no Wayland não aceitará um display Xvfb; ele espera uma saída DRM/KMS. Suas opções:

• Use um plug HDMI dummy para que o compositor pense que um monitor está presente.
• Execute uma sessão Xorg em vez disso (instale uma sessão X11 como XFCE ou GNOME on Xorg) e use Xvfb/xrdp/VNC.
• Para compositores baseados em wlroots, investigue wlr-rdp ou wayvnc (a maturidade dos projetos varia conforme o compositor).
• Para frotas grandes que exigem Wayland, considere usar uma GPU headless de hardware ou um driver headless empresarial — mas isso normalmente requer pacotes do fornecedor e hooks no kernel.

Se você depende de Wayland, leia nossa cobertura aprofundada em Desktop remoto Wayland: PipeWire, portals e lacunas antes de decidir por uma solução.

Conectividade de rede: relay da Tenvo e notas de segurança

Depois de ter uma sessão de desktop, você precisa de uma conexão confiável. Tenvo oferece clientes nativos para macOS/Windows/Linux, um cliente via navegador em beta público e um relay gerenciado multirregional, que é o padrão recomendado para a maioria dos usuários. Planos: Free $0, Lite $2.99/mo, Pro $7.99/mo. O relay gerenciado elimina a necessidade de regras de firewall, NAT traversal e manter uma frota TURN/STUN.

Seja explícito sobre criptografia: Tenvo usa TLS com certificados por dispositivo. Uma conexão peer-to-peer direta é end‑to‑end entre os dois dispositivos. Quando o tráfego recorre a um relay, o TLS termina no relay, o que significa que quem opera o relay pode acessar o tráfego da sessão. Se um requisito de conformidade proíbe infraestrutura de terceiros, self‑hosting é a opção certa — caso contrário, o custo operacional de self‑hosting (patching, custódia de chaves, failover) costuma ser maior que um relay gerenciado. Veja Remote Desktop Self-Hosted: por que, como e o que pode falhar para entender quando optar por self‑hosted.

Se você quer evitar encaminhamento de portas por completo, mas ainda assim usar seu próprio relay ou túnel, consulte Remote Desktop Without Port Forwarding Explained.

Lista de verificação de solução de problemas (telas pretas, resolução errada, problemas de teclado)

• Tela preta após o login: verifique os logs do display manager (journalctl -u gdm -b ou journalctl -u lightdm) e /var/log/Xorg.0.log em busca de erros.
• Framebuffer pequeno demais (ex.: 640×480): defina um modo customizado na sua configuração dummy do X ou use xrandr para adicionar um modo (funciona apenas se o X expor a saída).
• Mapeamento de teclado/mouse errado: verifique locale e configurações xkb, e confirme que o cliente VNC/RDP não está forçando um layout; teste com um console virtual local (chvt) se possível.
• Sem GPU/OpenGL: Xvfb não fornece aceleração por GPU. Use HDMI dummy ou um driver headless do fornecedor se precisar de aceleração por hardware.
• Greeter Wayland mas sem sessão: mude para uma sessão X ou conecte um dummy; verifique os logs do compositor (journalctl para gnome-shell ou o serviço do compositor).

Para correções comuns de tela preta veja nosso guia de solução de problemas: Fluxo de solução de tela preta em remote desktop. Também inspecione Xauthority, a propriedade de /tmp/.X11-unix e confirme que o usuário tem um shell válido e diretório home.

Quando self‑hostear vs usar o relay gerenciado da Tenvo

Opte por self‑hosting apenas se você tiver uma política escrita que proíba relays de terceiros (residência de dados, certos regimes de conformidade), ou se a máquina estiver em uma rede isolada. Caso contrário, o relay gerenciado da Tenvo é a escolha prática: reduz o trabalho de plantão, gerencia certificados TLS e oferece failover multirregional. Se planeja self‑hostear, leia as compensações em Remote Desktop Self-Hosted: por que, como e o que pode falhar e prepare-se para rodar um cluster de relays, cuidar da rotação de certificados, logging e monitoramento.

Referência rápida: comandos e verificações

# Check active display
echo "$DISPLAY"
# Test X connectivity
xdpyinfo -display :0 || xdpyinfo -display :99
# View DM logs
sudo journalctl -u gdm -b --no-pager
# Xorg log
sudo tail -n 200 /var/log/Xorg.0.log
# See screen/outputs
DISPLAY=:0 xrandr --listmonitors || DISPLAY=:99 xrandr --listmonitors
# Enable xrdp
sudo systemctl enable --now xrdp

Se você está migrando de uma ferramenta de desktop remoto que sempre 'simplesmente funcionava' com um monitor conectado, lembre-se: máquinas headless mudam as suposições que o SO e os drivers fazem sobre displays. Comece pela correção mais simples (HDMI dummy) e passe para soluções por software se o acesso físico não for possível.

Pronto para testar? Baixe o Tenvo, teste uma conexão unattended pelo relay gerenciado e escolha a abordagem de desktop acima que corresponda à sua GPU e requisitos de conformidade: Baixar Tenvo.