Serve para estes casos:

• Você usa o RustDesk com frequência para acessar remotamente seus próprios computadores.
• Você não quer depender dos servidores públicos padrão.
• Você tem vários dispositivos que precisam de manutenção remota de longo prazo.
• Você quer o nó de relay mais próximo de você, por exemplo Hong Kong, Japão, Singapura ou a costa oeste dos EUA.
• Você aceita abrir algumas portas específicas do RustDesk.

Não serve para estes casos:

• Você só ajuda um amigo remotamente de vez em quando.
• Você não tem um VPS público e só quer rodar em um NAS doméstico.
• Você não pode abrir portas UDP.
• Você espera contas completas, permissões, auditoria e gestão de equipe como em um produto comercial de acesso remoto.

Se você só precisa de acesso remoto temporário, usar os servidores padrão do RustDesk é mais simples. O valor da auto-hospedagem está em: estabilidade, controle e latência mais previsível.

O ponto onde mais fácilmente se erra no RustDesk Server são as portas.

Segundo a documentação oficial, o serviço auto-hospedado OSS envolve principalmente estas portas:

Se você não usa o Web Client, as portas principais são:

TCP: 21115, 21116, 21117
UDP: 21116

21118 e 21119 não são portas obrigatórias para o cliente desktop; estão relacionadas principalmente ao Web Client. No início da investigação, você pode liberar o conjunto completo de portas e, depois que tudo funcionar, restringi-las conforme a necessidade real.

O RustDesk Server não consome muita CPU nem memória, mas consome qualidade de rede.

Configuração mínima:

O que realmente importa é:

• A latência do VPS até a sua localização.
• Se é estável no horário de pico da noite.
• Se a largura de banda de upload e download é suficiente.
• Se o UDP funciona corretamente.
• Se a cota de tráfego é suficiente.

Se você acessa remotamente um computador de casa principalmente a partir da China continental, Hong Kong, Japão, Singapura e a costa oeste dos EUA costumam ser mais adequados do que a Europa. VPSs europeus são muito baratos, mas quando a latência do acesso remoto fica alta, mover o mouse fica muito desconfortável.

Este artigo assume:

• Ubuntu 22.04 / 24.04 ou Debian 12.
• Docker e Docker Compose já instalados.
• Você tem um domínio acessível externamente, por exemplo rustdesk.example.com, ou pode usar diretamente o IP público do VPS.
• O firewall e o security group do provedor de nuvem são configuráveis.

Confirme o Docker:

docker version
docker compose version

Crie o diretório:

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

O diretório data é importante; nele ficam as chaves geradas pelo RustDesk Server. Se esse diretório for perdido, a Key configurada nos clientes deixa de corresponder e você terá que reconfigurar todos os dispositivos depois.

Crie docker-compose.yml:

nano docker-compose.yml

Escreva o conteúdo abaixo, substituindo rustdesk.example.com pelo seu domínio público ou pelo IP público do VPS. Não use nome de contêiner, hostname interno ou endereço que só resolve no próprio servidor; o cliente precisa conseguir acessá-lo pela rede 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

Aqui há alguns pontos importantes:

• hbbs -r rustdesk.example.com:21117 informa ao cliente o endereço do servidor de relay.
• ./data:/root é usado para persistir as chaves.
• 21116 precisa tanto de TCP quanto de UDP.
• hbbs e hbbr compartilham o mesmo diretório data.
• O exemplo fixa rustdesk/rustdesk-server:1.1.15; em atualizações futuras, você pode consultar primeiro o Docker Hub / GitHub Release e depois alterar manualmente o número da versão.

Se você usa um IP puro, também pode escrever:

command: hbbs -r 1.2.3.4:21117

A vantagem do domínio é que, se você trocar de VPS no futuro, basta alterar o DNS e não precisa preencher o IP em cada cliente.

Execute:

docker compose up -d

Verifique os contêineres:

docker compose ps

Veja os logs:

docker compose logs -f --tail=100

Normalmente, hbbs gera um conjunto de chaves. Você pode ler os arquivos diretamente:

ls -l data
cat data/id_ed25519.pub

Também pode encontrar a Key nos logs:

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

A Key que os clientes precisam preencher depois costuma ser o conteúdo de id_ed25519.pub.

Se o UFW estiver ativado no 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

Se você confirmar que não usa o Web Client, pode deixar 21118 e 21119 fechadas. Mas na fase de diagnóstico para iniciantes é mais simples liberar o conjunto completo de portas; restrinja depois de confirmar a conectividade.

Não esqueça o security group no painel do provedor de nuvem. Algumas pessoas configuram ufw allow corretamente dentro do VPS, mas o painel da nuvem continua bloqueando, e no fim nunca conseguem conectar.

Verifique as portas em escuta:

ss -lntup | grep 211

Você deve ver portas como 21115, 21116 e 21117.

Abra o cliente RustDesk:

Settings -> Network -> ID/Relay Server

Formas comuns de preencher:

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

Se você não tem domínio, preencha o IP público do VPS. Aqui é obrigatório informar um endereço público que o cliente consiga acessar; não preencha hbbs, localhost, 127.0.0.1 nem um endereço de rede interna do Docker.

Os dois dispositivos precisam ter o mesmo servidor e a mesma Key. Depois de preencher, reinicie o cliente RustDesk ou desconecte e conecte novamente.

Se a configuração der certo, o cliente normalmente mostra um status de conexão com o servidor normal na parte inferior. Em seguida, use um dispositivo para conectar ao outro e testar.

O RustDesk usa conexão direta quando possível e só passa pelo relay quando a conexão direta falha. O hbbs do servidor auto-hospedado coordena primeiro o hole punching e, se falhar, encaminha por meio do hbbr.

Você pode determinar isso de várias formas:

• Veja as informações de conexão do cliente.
• Verifique se os logs de hbbr têm registros de conexão.
• Observe se o tráfego do VPS aumenta claramente durante o acesso remoto.
• Use iftop ou nload para ver o tráfego na porta 21117.

Instale nload:

sudo apt update
sudo apt install -y nload
nload

Se o tráfego de saída do VPS aumentar claramente durante o acesso remoto, muito provavelmente está passando pelo relay.

Isso também lembra uma coisa: se você retransmitir com frequência transferências de arquivos grandes, o tráfego do VPS será consumido rapidamente. O desktop remoto em si não é problema; transferências de arquivos e telas em alta resolução são o que realmente consome tráfego.

As portas principais do RustDesk não são serviços HTTP comuns, então você não pode simplesmente fazer reverse_proxy 127.0.0.1:21117 nelas como em um site e pronto.

Se você está apenas implantando o OSS RustDesk Server, recomenda-se abrir diretamente as portas principais 21115-21117 e não forçar um proxy reverso HTTP comum sobre elas.

Os cenários opcionais 21118, 21119 e Web Client são onde entra o proxy WebSocket / HTTPS. A maioria dos usuários individuais não precisa mexer nisso no começo; fazer o cliente desktop funcionar é mais importante.

Se a sua rede só permite saída na 443, o RustDesk também tem uma solução 443 mais complexa, mas isso já não é uma implantação de nível iniciante. Este artigo aborda primeiro o método de portas padrão, que é o mais estável e fácil de diagnosticar.

Isso é muito importante.

Faça backup do diretório 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

A forma mais segura é fazer backup de todo o diretório data. No mínimo, preserve o arquivo de chave privada:

data/id_ed25519

data/id_ed25519.pub é a chave pública que os clientes preenchem, o que é importante, mas o que realmente determina a identidade do servidor é a chave privada id_ed25519. Se a chave privada for perdida, o servidor gera um novo conjunto de chaves, a Key que os clientes tinham configurado deixa de valer e você terá que reconfigurar cada dispositivo. Com poucos dispositivos tudo bem, mas com uma dúzia é bem chato.

Recomenda-se sincronizar o backup para um segundo local, como outro VPS, um NAS, armazenamento de objetos ou um disco na nuvem criptografado.

Faça backup antes de atualizar:

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

Depois verifique se há uma nova versão e altere a tag da imagem em docker-compose.yml, por exemplo de 1.1.15 para uma nova versão estável.

Baixe a nova imagem:

docker compose pull
docker compose up -d

Veja os logs:

docker compose logs -f --tail=100

Após atualizar, conecte de fato uma vez com dois dispositivos; não presuma que está tudo bem só porque o contêiner está Up.

Não recomendo usar latest por muito tempo em um tutorial. Para testes pessoais, vale pela praticidade, mas no uso real fixar uma versão é mais estável e também facilita reverter se algo der errado.

O RustDesk Server existe para que os clientes se encontrem; não é um sistema de backend tradicional, mas também não convém ignorar totalmente a segurança.

Recomendações:

• Não deixe exposto o login com senha root do VPS.
• Abra no firewall apenas as portas necessárias.
• Se não usar o Web Client, não abra 21118/21119.
• Atualize as imagens Docker e os patches do sistema em dia.
• Faça backup do diretório de chaves data, especialmente da chave privada id_ed25519.
• Não envie a chave privada do servidor para outras pessoas.
• Ative senhas fortes e confirmação de conexão nos clientes.
• Não conceda acesso não assistido de longo prazo a estranhos.

Se você usa com familiares ou uma equipe, é melhor combinar antes: quais dispositivos permitem acesso não assistido e quais dispositivos exigem confirmação manual. Ferramentas de desktop remoto são realmente práticas, mas conceder permissões erradas também é realmente perigoso.

Verifique uma vez antes do uso formal:

• Os contêineres hbbs e hbbr estão em execução.
• 21115/tcp, 21116/tcp, 21116/udp, 21117/tcp estão liberadas.
• Se usar o Web Client, 21118/tcp, 21119/tcp estão tratadas; se não usar, permanecem fechadas.
• hbbs -r contém um domínio público ou o IP público do VPS acessível pelos clientes.
• O ID Server, o Relay Server e a Key do cliente estão preenchidos.
• Todo o diretório data está com backup, especialmente a chave privada data/id_ed25519.
• Um teste de conexão real entre dois dispositivos foi aprovado.
• A transferência de arquivos e o acesso não assistido foram testados conforme necessário.
• O tráfego e a largura de banda do VPS são suficientes.

Se você só acessa remotamente de vez em quando, os servidores públicos padrão do RustDesk bastam.

Se você acessa com frequência remotamente seus próprios computadores, NAS ou computadores de familiares, ou não quer deixar a qualidade da conexão nas mãos dos servidores públicos, auto-hospedar o RustDesk Server vale muito a pena. Ele não exige muito do VPS; o que realmente importa é a rota de rede, a liberação das portas e o backup das chaves.

Meu conselho: primeiro coloque para rodar em um VPS barato mas com rota estável e teste por 3-5 dias. Se o acesso remoto ficar fluido mesmo no horário de pico da noite, então vá migrando aos poucos os dispositivos de casa e do escritório. Não altere todos os dispositivos de uma vez; valide primeiro e migre depois.