Servidor de jogos na Starlink com uma VPS grátis de retransmissão

Como os jogadores chegam a um servidor em casa sem port forwarding

Se o seu roteador não tem um endereço IPv4 público, as conexões dos jogadores vindas da internet chegam primeiro ao NAT do seu provedor, e um port forwarding (redirecionamento de portas) no seu próprio roteador só as recebe se esse NAT também redirecionar a porta. O guia sobre hospedar um servidor sem um endereço IPv4 público mostra como isso aparece numa conexão Starlink de casa.

A página de ajuda da Starlink What IP address does Starlink provide? diz que a configuração IPv4 padrão dela usa NAT de nível de operadora (CGNAT), e que essa política “default” (padrão) “does not allow inbound traffic” (não permite tráfego de entrada; verificada em outubro de 2026). Um endereço IPv4 público na própria conexão é uma opção dos planos Priority (Prioritário, no texto em português da Starlink), diz a página de ajuda da Starlink sobre definir um IP público.

Uma retransmissão inverte a conexão. O caminho tem quatro passos:

1. O jogo de um jogador se conecta ao endereço IPv4 público de uma VM na nuvem, a VM de retransmissão, na porta do jogo.
2. Um programa de retransmissão na VM aceita a conexão e abre a sua própria conexão com o endereço do servidor de jogos numa tailnet, a rede privada em que as suas máquinas entram com o cliente do Tailscale.
3. A tailnet leva essa conexão até a sua casa, direto entre as duas máquinas ou por um servidor de retransmissão DERP. A página do Tailscale sobre tipos de conexão diz que toda conexão começa retransmitida pelo DERP e passa a ser direta onde puder, e que algumas redes, que ela chama de hard NAT, impedem o caminho direto (verificada em outubro de 2026).
4. O servidor de jogos responde pelo mesmo caminho de volta.

Os jogadores se conectam só ao endereço público da VM de retransmissão, e a retransmissão, não o jogador, abre a conexão até a sua casa.

O Minecraft Java respondeu a 30 de 30 pings da lista de servidores pela retransmissão

Eu hospedo um servidor de Minecraft Java Edition assim, em Docker, em casa, numa conexão Starlink. Os jogadores se conectam a uma VM na nuvem do nível gratuito, com um endereço IPv4 público, onde o socat retransmite cada conexão TCP na porta 25565 pela minha tailnet do Headscale, que roda sobre WireGuard, até o servidor de jogos. Configurei a política da tailnet para que a VM de retransmissão alcance essa única porta em casa e mais nada.

Uma leitura no servidor de jogos em outubro de 2026 encontrou a imagem itzg/minecraft-server com o online-mode, a whitelist e o enforce-whitelist ligados. O Docker publica a TCP 25565 para ele, não a UDP.

O teste rodou em outubro de 2026 a partir de um computador ligado por cabo na rede de casa, em três sessões de 10 rodadas cada, todas num mesmo dia, cada sondagem pelo menos 2 s depois da anterior. Cada rodada fez uma conexão TCP simples com o endereço público da VM de retransmissão na porta 25565, depois um ping da lista de servidores pela retransmissão: o pedido de status que um cliente de Minecraft envia para mostrar um servidor na lista, seguido de um ping e um pong na mesma conexão. Esse ping nunca faz login. Antes de cada sessão, a rota até o endereço da VM foi verificada: ela saía pela rota padrão da conexão de casa, não pela tailnet. Em todas as sessões, a resposta de status pela retransmissão foi igual à lida direto no servidor de jogos pela tailnet, então a retransmissão levava a este servidor.

O único ping direto que falhou, e dois que só conectaram depois que o primeiro pacote foi reenviado, estavam no caminho direto da tailnet dentro da rede de casa. A retransmissão respondeu normalmente nas mesmas rodadas. Não se examinou por que o caminho direto travou, já que era só um controle.

Os pings do teste não deixaram linha no log do servidor de jogos. As linhas de jogadores que já estavam no log, de logins anteriores, trazem todas um mesmo endereço privado da rede que o Docker montou nessa máquina: nunca o endereço da VM de retransmissão na tailnet e nunca o próprio endereço de um jogador. O log não mostra por que caminho esses jogadores entraram.

O trecho da retransmissão, da VM ao servidor de jogos e de volta, ficou em cerca de 20 ms (uma estimativa)

Uma ida e volta pela retransmissão cobre o trecho do jogador até a VM de retransmissão e o trecho da retransmissão: da VM pela tailnet até o servidor de jogos e de volta, com o encaminhamento da própria retransmissão. O trecho da retransmissão ficou em cerca de 20 ms, como estimativa. Essa é a mediana de 27 rodadas, e as medianas das três sessões foram de 17,9 a 23,6 ms. A comparação de internet via satélite põe essa estimativa ao lado do tempo mínimo de ida e volta por um satélite geoestacionário.

Para cada rodada, a estimativa pega o tempo do ping ao pong pela retransmissão, menos o tempo de ida e volta dessa mesma conexão até a VM, medido um instante antes, e menos o próprio tempo de resposta do servidor de jogos, medido direto pela tailnet. As partes não foram medidas no mesmo instante, e o tempo de ida e volta da conexão de casa muda de um segundo para o outro, como mostra o guia de latência. Três rodadas ficaram de fora porque a conexão direta delas, da qual a estimativa depende, falhou ou precisou que um pacote fosse reenviado.

O computador de teste e o servidor de jogos dividem a conexão de casa, então cada sondagem pela retransmissão saiu de casa pela Starlink até a VM e voltou pela Starlink dentro da tailnet. Para um jogador em outro lugar, o trecho dele até a VM substitui o do computador de teste, e o trecho da retransmissão continua.

Uma retransmissão TCP leva jogos TCP; jogos UDP precisam de uma retransmissão UDP

Uma retransmissão TCP transporta só TCP. A documentação ou a wiki de cada jogo diz que protocolo o servidor dele usa (verificadas em outubro de 2026):

As linhas vêm das páginas da Minecraft Wiki sobre o server.properties e o Bedrock Dedicated Server, uma wiki da comunidade; da página Server da Official Terraria Wiki; da página Multiplayer da Factorio Wiki, que diz “Factorio uses UDP only” (o Factorio usa só UDP); da página Requirements do Palworld Server Guide da Pocketpair; da Dedicated server setup da ARK Official Community Wiki; e da página Dedicated servers da Official Satisfactory Wiki. Todas deixam você mudar a porta padrão. A página do Terraria diz que o servidor dele “runs on TCP port 7777 by default” (roda por padrão na porta TCP 7777), e a nota dela para provedores de nuvem manda abrir a 7777 em TCP e UDP. A do Satisfactory diz “Port redirection is not supported at the moment for the standard port” (o redirecionamento de porta não tem suporte, por enquanto, para a porta padrão), então uma retransmissão ali mantém o número dessa porta, 7777 por padrão, igual dos dois lados. A porta de mensagens confiáveis dele, TCP 8888 por padrão, “can be remapped” (pode ser remapeada) com o parâmetro de linha de comando -ExternalReliablePort=, diz a mesma página.

No endereço da retransmissão testada, um pacote UDP, o ping de descoberta que um cliente Bedrock envia para achar servidores, não teve resposta em 5 s na porta 25565. O mesmo pacote para a porta 25566, que nada serve, teve o mesmo silêncio, enquanto um ping da lista de servidores por TCP na 25565 respondeu no mesmo minuto. No servidor de jogos, o Docker publica a 25565 só para TCP.

VMs grátis na nuvem vêm com termos para conferir antes

A retransmissão precisa de uma VM com um endereço IPv4 público que fique no ar enquanto as pessoas jogam. Vários provedores de nuvem publicam ofertas grátis: o AWS Free Tier, os serviços gratuitos do Azure, os recursos gratuitos do Google Cloud e o Oracle Cloud Free Tier (páginas verificadas em outubro de 2026). As ofertas grátis mudam, então leia a página atual do provedor antes de montar algo em cima de uma. Veja:

• se a VM continua grátis sem data de término ou só por um período de teste;
• se a VM grátis inclui um endereço IPv4 público, e se esse endereço é cobrado à parte;
• quantos dados de saída são grátis por mês;
• se o provedor pode recuperar uma VM que considere ociosa;
• o que o cadastro exige, como um cartão de pagamento.

Uma retransmissão manda o tráfego de todos os jogadores pela VM, então os dados de saída dela crescem com o número de jogadores e o tempo de jogo.

Monte com uma porta aberta, uma regra na tailnet e o login do próprio jogo

Estes passos usam o Minecraft Java Edition. Para outro jogo TCP, use a porta dele da tabela acima.

1. Em casa, rode o servidor de jogos em Docker com as verificações de login do próprio jogo ligadas. A imagem itzg/minecraft-server recebe as configurações como variáveis de ambiente, segundo a documentação dela (verificada em outubro de 2026):

   docker run -d -it --name mc -p 25565:25565 \
     -e EULA=TRUE -e ONLINE_MODE=TRUE \
     -e WHITELIST=your-friend-1,your-friend-2 \
     -e ENFORCE_WHITELIST=true \
     -v "$PWD/data:/data" itzg/minecraft-server

   • -p 25565:25565 publica a porta para TCP. A página do Docker sobre publicação de portas mapeia uma porta para TCP, a não ser que ela termine em /udp (verificada em outubro de 2026).
   • EULA=TRUE aceita o contrato de licença de usuário final do Minecraft, que a documentação da imagem manda “always include” (incluir sempre).
   • ONLINE_MODE=TRUE mantém o online-mode ligado, que a Minecraft Wiki descreve como “Whether to only allow players verified with the Minecraft account database to join” (se só os jogadores verificados no banco de dados de contas do Minecraft podem entrar). Ele vem ligado por padrão.
   • WHITELIST liga a whitelist (a lista de permissões) e lista quem pode entrar. Ponha os nomes de perfil do Java Edition dos seus jogadores no lugar de your-friend-1,your-friend-2; a documentação da imagem manda usar esses, “not Xbox gamertags” (e não gamertags do Xbox).
   • ENFORCE_WHITELIST=true liga o enforce-whitelist. Com ele ligado, diz a Minecraft Wiki, “players not present on the whitelist get kicked from the server after the server reloads the whitelist file” (os jogadores que não estão na whitelist são expulsos do servidor depois que ele recarrega o arquivo da whitelist).
   • -v "$PWD/data:/data" guarda o mundo numa pasta data no lugar onde você roda o comando, já que a imagem guarda os dados do servidor no /data do contêiner.

   Outros jogos têm as próprias verificações de entrada, como a senha do servidor no comando de início do ARK, na mesma página da wiki que as portas dele.

2. Arranje uma VM na nuvem com um endereço IPv4 público (o que conferir numa oferta grátis). A retransmissão só precisa do cliente do Tailscale e do socat nela.

3. Ponha a máquina do servidor de jogos e a VM de retransmissão numa mesma tailnet. Com o Headscale, que esta página não configura, cada máquina roda tailscale up --login-server com o endereço do seu servidor Headscale, e você a aprova no servidor Headscale (os métodos de registro do Headscale, verificada em outubro de 2026). O guia sobre deixar a internet fixa trata do que uma tailnet alcança sozinha.

4. Deixe a VM de retransmissão alcançar a porta do jogo e mais nada. A página de política do Headscale diz que, por padrão, “no policy is loaded which means that Headscale allows all traffic between nodes” (nenhuma política é carregada, o que significa que o Headscale permite todo o tráfego entre os nós), que ele lê o arquivo indicado na configuração policy.path e que ele “needs to be reloaded to pick up changes” (precisa ser recarregado para pegar as mudanças; verificada em outubro de 2026). Este arquivo de política permite uma coisa só: a VM de retransmissão abrir conexões TCP com a porta 25565 do servidor de jogos. No Headscale 0.29.7, em outubro de 2026, esta política carregou, o headscale nodes tag aplicou as duas tags e recusou uma tag que a política não define, e as regras que o Headscale montou a partir dela permitiam só TCP para a porta 25565 do servidor de jogos, a partir da retransmissão; nenhum cliente estava conectado nessa verificação.

   {
     "tagOwners": {
       "tag:game-relay": [],
       "tag:game-server": []
     },
     "acls": [
       {
         "action": "accept",
         "src": ["tag:game-relay"],
         "proto": "tcp",
         "dst": ["tag:game-server:25565"]
       }
     ]
   }

   A referência de sintaxe de política do Tailscale, cujo formato de arquivo o Headscale usa, diz que as regras de acesso “deny access by default” (negam o acesso por padrão). Então, depois que esta política carrega, tudo o que ela não permite fica bloqueado: se outros dispositivos da sua tailnet precisam alcançar uns aos outros, acrescente regras para eles. Sem "proto": "tcp", diz a mesma referência, uma regra “applies to all TCP and UDP traffic” (vale para todo o tráfego TCP e UDP). Na sintaxe do Tailscale, uma lista vazia em tagOwners é um atalho para os administradores da tailnet; no Headscale, o administrador define as tags com o comando headscale nodes tag do próximo passo. A página de política do Headscale recomenda grants, a sintaxe de regras mais nova do Tailscale, e também aceita regras como esta.

5. Marque as duas máquinas com as tags no servidor Headscale, com os IDs que o headscale nodes list mostra para elas no lugar de 1 e 2, como descreve a página do Headscale sobre tags (verificada em outubro de 2026):

   headscale nodes list
   headscale nodes tag -i 1 -t tag:game-server
   headscale nodes tag -i 2 -t tag:game-relay

6. Na VM de retransmissão, inicie a retransmissão. game-server representa o nome ou o endereço do servidor de jogos na tailnet:

   socat TCP4-LISTEN:25565,fork,reuseaddr \
     TCP4:game-server:25565

   O manual do socat chama um endereço TCP4-LISTEN com um endereço TCP4 de “a simple TCP port forwarder” (um simples redirecionador de portas TCP). Com fork, o socat “handles its channel in a child process” (trata o canal num processo filho) para cada conexão, então vários jogadores podem se conectar ao mesmo tempo. reuseaddr “Allows other sockets to bind to an address even if parts of it (e.g. the local port) are already in use by socat” (permite que outros sockets se vinculem a um endereço mesmo que partes dele, por exemplo a porta local, já estejam em uso pelo socat; verificada em outubro de 2026). Rode o comando com o gerenciador de serviços da VM, para que ele volte depois de uma reinicialização.

7. Abra uma porta. No firewall do provedor para a VM, e no firewall da própria VM se ela rodar um, libere a TCP 25565 de qualquer origem. Mantenha todas as outras portas fechadas, fora a que você usa para entrar na VM, se você entra nela pela internet.

8. Dê aos jogadores o endereço IPv4 público da VM de retransmissão, como 203.0.113.10 nos exemplos desta página, ou um nome de DNS que você aponte para ele, como mc.example.com.

Três formas de retransmitir um jogo UDP, pela documentação delas

O UDP não tem uma conexão para a retransmissão aceitar. O manual do socat diz que, com UDP, “no real connection is established; data has to arrive from the peer first” (nenhuma conexão real é estabelecida; os dados precisam chegar primeiro do outro lado) e que “no end-of-file condition is specified in UDP” (o UDP não especifica nenhuma condição de fim de arquivo). Então uma retransmissão UDP acompanha cada jogador e precisa descartar esse jogador depois de um tempo sem dados.

Em cada método abaixo, o servidor de jogos publica a porta para UDP (-p 34197:34197/udp no Docker), e a regra da política leva "proto": "udp" e a porta do jogo. A porta do Factorio, 34197, é o exemplo.

socat em modo UDP

Na VM de retransmissão:

socat -T 60 UDP4-LISTEN:34197,fork,reuseaddr \
  UDP4:game-server:34197

-T é o “Total inactivity timeout” (tempo limite de inatividade total) do socat, que o manual chama de “Useful with protocols like UDP that cannot transfer EOF” (útil com protocolos como o UDP, que não conseguem transferir EOF). Aqui, ele encerra o processo filho de um jogador depois de 60 segundos sem dados. Até o socat 1.8.0.0, -T 0 significava nenhum tempo limite; desde o 1.8.0.1, significa 0, diz o manual, então dê a ele um número.

NAT de destino no kernel da VM

A página de NAT da wiki do nftables mostra as duas regras que isso exige: uma regra dnat to numa chain de prerouting do tipo nat, que manda os pacotes da porta do jogo para o endereço do servidor de jogos na tailnet, e masquerade numa chain de postrouting, em que “the source address is automagically set to the address of the output interface” (o endereço de origem é definido automagicamente como o endereço da interface de saída), aqui o endereço da VM na tailnet, para que o servidor de jogos responda à VM. O kernel também precisa encaminhar pacotes entre as interfaces dele, que é a configuração net.ipv4.ip_forward: “Forward Packets between interfaces” (encaminhar pacotes entre interfaces), na documentação do kernel.

O módulo stream do nginx

No módulo stream core do nginx, listen 34197 udp reuseport; num bloco server abre um socket “for working with datagrams” (para trabalhar com datagramas); a página diz que o reuseport “should also be specified” (também deve ser especificado) para que os pacotes de um mesmo endereço e porta fiquem numa mesma sessão. O módulo stream proxy os repassa com proxy_pass para o servidor de jogos, e o proxy_timeout, de 10 minutos por padrão, fecha uma sessão quando “no data is transmitted within this time” (nenhum dado é transmitido nesse tempo). A página do módulo core diz que ele “is not built by default” (não é compilado por padrão) e precisa da opção de build --with-stream, então confira se o seu nginx o tem.

O Bedrock Edition pode precisar de mais de uma porta. A cópia, na Minecraft Wiki, do arquivo server.properties que vem com o Bedrock Dedicated Server 1.26.60.6 define transport=nethernet e server-udp-ports=19132, uma configuração que “Configures UDP client transport ports” (configura as portas de transporte UDP dos clientes): é uma “Single UDP port shared by all clients” (porta UDP única compartilhada por todos os clientes). Se ela não estiver definida, diz o arquivo, “UDP ports are allocated from the operating system's ephemeral port range” (as portas UDP são alocadas da faixa de portas efêmeras do sistema operacional), e uma retransmissão teria que transportar essas portas também. Com esse transporte, a configuração de porta IPv6 do arquivo é ignorada, e o IPv6 também usa a 19132. Esta página não testou o Bedrock por uma retransmissão.

Túneis gerenciados dispensam a VM, pelas páginas deles

Nenhum destes foi testado aqui. Cada um roda a ponta pública para você, então não há VM para configurar nem atualizar; em troca, a rede deles transporta o tráfego dos seus jogadores. Todas as páginas foram verificadas em outubro de 2026.

O playit.gg se descreve como “a global proxy that lets you host a server without port forwarding” (um proxy global que permite hospedar um servidor sem port forwarding), com um agente na sua máquina: “Only you run the agent, your players just connect.” (Só você roda o agente; os seus jogadores apenas se conectam.) A página inicial dele cita um nível gratuito e um plano Premium pago; a lista de jogos dele põe Minecraft Java e Bedrock, Palworld, Terraria, Factorio e uma entrada “UDP” simples em “Free” (grátis), e entradas “TCP” e “TCP+UDP” simples, com alguns outros jogos, em “Requires Playit Premium” (exige o Playit Premium).

A página de preços do ngrok diz que, no plano Free dele, “TCP endpoints also need a verified credit card, and ngrok doesn't charge it” (os endpoints TCP também precisam de um cartão de crédito verificado, e o ngrok não faz cobrança nele).

O Tailscale Funnel “can only listen on ports 443, 8443, and 10000” (só pode escutar nas portas 443, 8443 e 10000) e “only works over TLS-encrypted connections” (só funciona em conexões criptografadas com TLS). A porta padrão do Minecraft Java Edition, TCP 25565, não é nenhuma dessas portas. Na página de recursos do Headscale, o Funnel é um dos itens sem marcação.

O Cloudflare Tunnel precisa do cliente da Cloudflare na máquina de cada jogador para qualquer coisa que não seja um serviço web, como cita o guia sobre deixar a internet fixa. A página do Cloudflare Spectrum diz “Custom TCP/UDP applications require an Enterprise plan with Spectrum as a paid add-on” (aplicações TCP/UDP personalizadas exigem um plano Enterprise com o Spectrum como complemento pago; atualizada pela última vez em abril de 2026). A tabela de protocolos por plano dele (atualizada pela última vez em agosto de 2026) lista o Minecraft, um aplicativo, também nos planos Pro e Business, em que o Spectrum é um complemento pago.

Uma VPN mesh em que todos os jogadores entram dispensa a retransmissão, mas cada jogador instala o cliente e entra na sua tailnet (o que uma VPN mesh alcança).

Ainda não testado aqui

• Um jogador em outra rede. Todas as sondagens rodaram a partir da mesma conexão de casa que o servidor de jogos usa.
• O jogo de verdade. Nenhuma sondagem fez login ou jogou, então o tempo de ida e volta que o jogo mostra, vários jogadores ao mesmo tempo e uma sessão inteira não foram testados.
• UDP por qualquer retransmissão, o Bedrock Edition e todos os jogos menos o Minecraft Java Edition.
• O lado da VM de retransmissão. Se o caminho dela até em casa foi direto ou por um servidor de retransmissão DERP, a carga dela, as configurações de firewall dela e se a política da tailnet a impede de alcançar qualquer outra coisa em casa não foram verificados a partir da VM.
• O que o servidor de jogos registra no log para um jogador que chegou pela retransmissão. As linhas de jogadores do log vieram de logins anteriores cujo caminho não se conhece.
• Uma VM em outra região, outros dias e horários, os túneis gerenciados e rodar o jogo na própria VM.

Veja como os testes em casa se encaixam para um homelab.