SSD Nodes Learn 🎉 VPS desde $4.99/mês
Guias Matt ConnorPor Matt Connor

Como escolher uma VPS para servidor de jogos

Saiba o que um servidor de jogos realmente precisa: CPU single-core rápida, RAM suficiente, portas, reinício com systemd, backups e baixa latência pela localização.

Que tipo de VPS para jogos pretende?

Uma VPS para servidores de jogos é uma boa escolha para uma finalidade: executar um servidor dedicado ao qual você e os seus amigos se ligam a partir dos próprios computadores. É uma escolha inadequada para a outra finalidade a que muitas pessoas se referem com essa expressão: jogar na própria VPS através de um ambiente de trabalho remoto. Estas duas finalidades exigem hardware oposto. Um servidor dedicado precisa de um núcleo de CPU rápido e de RAM suficiente para manter o mundo do jogo. Jogar exige uma GPU (unidade de processamento gráfico), e um plano de VPS normal não inclui uma.

Tudo o que se segue diz respeito à primeira finalidade. A segunda merece dois minutos da sua atenção, porque muitas pessoas compram a máquina errada para isso.

Por que não pode jogar num VPS

Um VPS comum fornece núcleos virtuais de CPU e não tem placa gráfica. Nada é passado pelo host físico, por isso não existe um renderizador de hardware que o jogo possa utilizar. Pode ver o que recebeu efetivamente:

sudo apt install -y pciutils
lspci | grep -iE "vga|3d"

A resposta é um adaptador de ecrã virtual, semelhante a um dispositivo Cirrus Logic ou a uma GPU virtio. Ele existe para que o console web do fornecedor possa mostrar um ecrã e não tem aceleração 3D. Instale um ambiente de trabalho e um servidor VNC sobre esse adaptador, e o glxinfo -B apresenta o renderizador como llvmpipe, que é o renderizador de software da Mesa executado na CPU. Um jogo 3D moderno desenhado pela CPU funciona a alguns fotogramas por segundo, por isso fica impossível de jogar antes de qualquer dado sair do servidor. As instâncias Windows enfrentam o mesmo problema pelo lado oposto. Muitos títulos terminam no arranque e informam que não foi possível criar um dispositivo Direct3D, porque não existe um adaptador de ecrã onde o dispositivo possa ser criado.

O segundo problema é o percurso de regresso até si. Jogar num servidor remoto significa que cada fotograma é codificado em vídeo, enviado pela internet e descodificado no seu ecrã. Isso acrescenta o tempo de codificação e descodificação à latência de entrada do próprio jogo, e RDP e VNC foram concebidos para ambientes de trabalho, não para movimento a 60 fotogramas por segundo. Os serviços de jogos na nuvem resolvem este problema com hardware de GPU real e um protocolo de transmissão concebido para esse fim. Um VPS comum não tem nenhum dos dois. Se quiser jogar, alugue tempo de GPU. Se quiser alojar, continue a ler.

O que um servidor de jogos dedicado realmente precisa

Um servidor de jogos é um ciclo de simulação. Mantém o mundo em memória e avança um número fixo de vezes por segundo. Depois, envia a cada jogador ligado a parte do mundo que esse jogador consegue ver.

Esta estrutura determina o hardware. O ciclo usa principalmente uma thread, por isso a velocidade dos cores é mais importante do que o número de cores. O mundo reside na memória, por isso a RAM é normalmente o primeiro limite atingido. O disco fica praticamente inativo durante o jogo e é utilizado durante o carregamento e a gravação. O caminho de rede determina o ping, e nenhum plano altera esse caminho.

A velocidade de um único core é mais importante do que a quantidade de cores

A maioria dos servidores de jogos avança o estado do jogo numa thread principal. O ciclo de ticks do Minecraft e o frame do servidor do Source engine funcionam dessa forma. Esse tick tem um prazo. O Minecraft Java executa 20 ticks por segundo, o que dá a cada tick um orçamento de 50 milissegundos. Quando o trabalho não cabe nesse intervalo, o servidor apresenta exatamente isto:

[12:04:51] [Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2547ms or 50 ticks behind

Essa linha significa que uma thread ficou sem tempo. Adicionar cores não dá mais tempo a essa thread. Um plano com 2 vCPUs rápidas mantém uma taxa de ticks que um plano com 8 vCPUs lentas deixa cair, porque apenas uma dessas 8 executa o trabalho relevante.

Meça a velocidade de uma única thread antes de escolher um plano:

sudo apt install -y sysbench
sysbench cpu --cpu-max-prime=20000 --threads=1 run

Leia a linha events per second. O número não tem significado isoladamente; serve para comparação. Por isso, execute o teste em dois planos candidatos e coloque os resultados lado a lado. Uma execução completa do benchmark de VPS avalia o disco e a rede da mesma forma.

As cores adicionais continuam a ser úteis. Executam o segundo servidor de jogos, a base de dados, a cópia de segurança noturna e o pré-gerador de chunks sem retirar tempo à thread dos ticks. O software de servidores também passou a distribuir melhor o trabalho, e o Paper, um fork popular de servidor Minecraft, move parte do trabalho para fora da thread principal dos ticks. Por isso, escolha alguns cores rápidos, não muitos cores lentos.

Há um número que nunca aparece na página do plano e que determina se o core rápido pelo qual pagou é realmente seu:

vmstat 1 5

A coluna st indica a percentagem de tempo durante a qual a sua CPU virtual estava pronta para executar, mas o host físico entregou o core a outro utilizador. Um valor st estável acima de alguns por cento indica que o host está sobrelotado. Os jogadores sentem isso como soluços, enquanto top no seu servidor continua a mostrar CPU ociosa, porque esse tempo ocioso não está disponível para si.

Quanta RAM um servidor de jogos precisa?

ChartCommon starting RAM per game server (published guidance, not a measurement)
The data behind this chart
[
  {
    "label": "Minecraft Java, vanilla",
    "players": 10,
    "ram_gb": 2
  },
  {
    "label": "Minecraft Java, large modpack",
    "players": 10,
    "ram_gb": 8
  },
  {
    "label": "Valheim",
    "players": 10,
    "ram_gb": 4
  },
  {
    "label": "Palworld",
    "players": 32,
    "ram_gb": 16
  }
]

Estas são as alocações iniciais publicadas na documentação dos jogos e modpacks, em agosto de 2026. Servem como orientação, não como valores medidos num único servidor. O Minecraft Java vanilla funciona bem com 2 GB de heap para cerca de 10 jogadores. A mesma quantidade de jogadores num modpack grande requer 8 GB, porque os mods adicionam entidades e estruturas geradas que ficam todas nesse heap. O mínimo indicado pelo próprio Valheim é 2 GB, mas operadores com um mundo pequeno relatam que o processo estabiliza perto de 3 GB. Por isso, 4 GB é um ponto de partida adequado. O Palworld é a exceção, com 16 GB para o máximo de 32 jogadores, conforme recomendado pela Pocketpair.

A RAM não aumenta proporcionalmente ao número de ligações. Aumenta com o mundo carregado. Cada jogador mantém carregada a região à sua volta. Por isso, dois jogadores juntos consomem muito menos do que dois jogadores a explorar cantos opostos do mapa. É por isso que "RAM por jogador" é apenas uma orientação aproximada, enquanto "RAM por área ativa" é o fator determinante. Um grupo pequeno que gosta de explorar pode ultrapassar um plano dimensionado para o dobro de jogadores.

Os servidores Java exigem mais duas regras. Defina o heap mínimo e máximo com o mesmo valor para impedir que a JVM faça pausas para redimensioná-lo:

java -Xms4G -Xmx4G -jar server.jar nogui

Depois, deixe margem livre. A JVM usa memória fora do heap que definiu, para stacks de threads e buffers nativos. O kernel também precisa da cache de páginas para ler rapidamente os ficheiros do mundo. Num servidor com 6 GB, um heap de 4 GB é adequado. Um heap de 6 GB não é.

As duas falhas de memória são muito diferentes. Por isso, memorize ambas as mensagens. Um heap demasiado pequeno gera uma exceção dentro do Java, e o servidor normalmente continua a funcionar com desempenho degradado:

java.lang.OutOfMemoryError: Java heap space

Um heap maior do que a memória disponível faz com que o processo inteiro seja terminado externamente. A consola mostra apenas Killed, e as evidências estão no log do kernel:

sudo dmesg -T | grep -i "out of memory"

Adicionar swap impede o processo de ser terminado, mas não corrige o problema. Um ciclo de ticks que precisa de ler o mundo novamente a partir da swap falha todos os prazos. Assim, os jogadores obtêm um servidor bloqueado em vez de um servidor terminado.

Uma nota sobre versões, atualizada em agosto de 2026: o Minecraft Java 1.20.5 e versões posteriores exigem Java 21. Um runtime mais antigo inicia e depois falha com um erro de versão de ficheiro de classe não suportada. A mensagem parece saída de um compilador e confunde quase toda a gente na primeira vez que a encontra.

sudo apt install -y openjdk-21-jre-headless
java -version

A velocidade do disco importa para um servidor de jogos?

Importa menos do que muitas pessoas esperam durante o jogo, mas importa bastante em dois momentos específicos. O mundo é carregado para a memória durante o arranque e escrito novamente durante o autosave. Por isso, a velocidade do disco manifesta-se num arranque lento e numa pausa quando o save é executado. Entre esses momentos, a maioria das leituras é servida a partir da RAM.

Dois fatores fazem o disco importar mais do que esse resumo sugere. A exploração carrega novos chunks ou zonas a partir do disco enquanto os jogadores se deslocam, e essa leitura ocorre dentro do orçamento do tick. O autosave de um mundo grande escreve muitos dados de uma só vez. Num volume lento, a escrita bloqueia o loop durante tempo suficiente para apresentar o aviso "Can't keep up" acima. Ambos são problemas de latência, não de throughput. Por isso, a diferença entre NVMe e SATA SSD num VPS importa mais neste caso do que os megabytes por segundo anunciados sugerem. O que importa é o tempo necessário para concluir uma operação pequena.

Dimensione o volume para permitir o crescimento. Um mundo cresce sempre que alguém explora uma área nova, e os seus backups multiplicam o espaço ocupado. Execute du -sh world uma vez por semana durante um mês para conhecer a sua taxa real de crescimento.

Taxa de ticks, ping e a diferença entre ambos

A taxa de ticks indica quantas vezes por segundo o servidor recalcula o mundo. O Minecraft Java funciona a 20. Os servidores do Source engine funcionam normalmente a 64. No Minecraft, não é possível comprar uma taxa superior, porque esse valor faz parte do design do jogo. O objetivo é manter 20, não ultrapassá-lo.

O ping é o tempo de ida e volta entre um jogador e o servidor. Estes dois problemas geram queixas diferentes, por isso deve distingui-los antes de gastar dinheiro. Quando o servidor falha ticks, todos os jogadores sofrem rubber-banding ao mesmo tempo, e o log do servidor regista isso claramente. Quando um jogador tem um percurso de rede longo, apenas esse jogador sofre lag e o resto do grupo funciona normalmente. Um CPU mais potente nunca resolve o segundo caso.

Latência depende da localização, não do tipo de plano

A luz na fibra percorre cerca de 200 quilómetros por milissegundo. Uma ida e volta cobre a distância duas vezes, por isso o limite mínimo é aproximadamente 1 ms por cada 100 km entre o jogador e o servidor. Nenhum fornecedor consegue superar esse limite, e nenhum upgrade de plano o altera.

ChartRound trip floor by distance, fibre physics only
The data behind this chart
[
  {
    "label": "Toronto to New York",
    "distance_km": 550,
    "rtt_floor_ms": 5.5
  },
  {
    "label": "Dallas to Chicago",
    "distance_km": 1290,
    "rtt_floor_ms": 12.9
  },
  {
    "label": "Dallas to Los Angeles",
    "distance_km": 1990,
    "rtt_floor_ms": 19.9
  },
  {
    "label": "New York to London",
    "distance_km": 5570,
    "rtt_floor_ms": 55.7
  },
  {
    "label": "Los Angeles to Sydney",
    "distance_km": 12070,
    "rtt_floor_ms": 120.7
  }
]

Estes são limites mínimos calculados com base na distância em grande círculo. A fibra real não segue uma linha reta, e cada router no caminho acrescenta alguma latência. Por isso, um bom resultado real costuma ficar próximo do dobro do limite mínimo. Um jogador em Toronto que aceda a um servidor em Nova Iorque, a 550 km de distância, tem um limite mínimo de 5.5 ms e normalmente verá um valor na casa dos 10 ms. O percurso entre Los Angeles e Sydney tem um limite mínimo de 120.7 ms, e nenhum montante de dinheiro o reduz.

Por isso, coloque o servidor perto das pessoas que jogam nele. Se o seu grupo estiver dividido por um oceano, alguém terá um percurso longo. A opção mais justa costuma ser a região onde está a maioria dos jogadores.

Meça o percurso em vez de adivinhar:

sudo apt install -y mtr-tiny
mtr -rwzc 100 203.0.113.10

Leia primeiro a última linha. Essa linha corresponde ao servidor, e a perda de pacotes e a latência apresentadas nela são as únicas que determinam a experiência no jogo. Uma perda apresentada num salto intermédio, com o salto final limpo, quase sempre indica limitação da taxa de respostas ICMP nesse router. Os routers dão prioridade inferior às respostas a pacotes de teste enquanto encaminham normalmente o tráfego real. Peça a cada jogador para executar o teste até ao servidor, porque cada jogador segue um percurso diferente.

Como é calculado o limite mínimo da ida e volta

A luz no vidro desloca-se aproximadamente a dois terços da velocidade que tem no vácuo, o que corresponde a cerca de 200 km por milissegundo. Uma ida e volta cobre a distância duas vezes, por isso o limite mínimo em milissegundos é a distância de ida, em quilómetros, dividida por 100. Nova Iorque e Londres ficam a 5,570 km de distância, e 5570 dividido por 100 dá 55.7 ms. Todos os valores medidos são superiores a este, porque os cabos seguem as linhas costeiras e os routers precisam de tempo para processar os pacotes.

Abra apenas as portas de que o jogo precisa

Um servidor de jogos precisa de uma ou duas portas abertas, e de mais nenhuma. Os valores predefinidos mais comuns são:

  • Minecraft Java Edition: TCP 25565
  • Minecraft Bedrock Edition: UDP 19132
  • Valheim: UDP 2456 e UDP 2457
  • Palworld: UDP 8211
  • Jogos do motor Source, como Counter-Strike 2: UDP 27015

Consulte a documentação do próprio jogo, porque vários títulos usam uma porta de consulta adicional. Valheim é o exemplo mais claro: 2456 transporta o tráfego do jogo e 2457 responde à consulta do servidor Steam que faz o servidor aparecer na lista do navegador. Abrir esses números em TCP não produz qualquer efeito, porque Valheim usa apenas UDP.

Permita o acesso por SSH antes de ativar a firewall, caso contrário ficará sem acesso ao seu próprio servidor:

sudo ufw allow 22/tcp
sudo ufw allow 25565/tcp
sudo ufw enable
sudo ufw status verbose

Muitos fornecedores também executam uma firewall de rede no painel de controlo, separada da firewall do servidor. Uma porta aberta em ufw mas fechada nesse painel continua a recusar ligações. O sintoma é igual a partir do exterior. Por isso, verifique os dois locais antes de começar a editar ficheiros de configuração.

Verificar uma porta TCP a partir de outra máquina é simples:

sudo apt install -y netcat-openbsd
nc -vz 203.0.113.10 25565

O UDP não pode ser testado dessa forma. Uma porta UDP fechada normalmente não responde. Por isso, uma sondagem sem resposta não lhe permite concluir nada. Em vez disso, confirme a partir do próprio servidor e procure o processo do jogo associado à porta esperada:

sudo ss -lunp | grep 2456

Nunca exponha o RCON, o protocolo de consola remota, à internet. Trata-se de uma única palavra-passe enviada através de uma ligação sem encriptação, por defeito na porta 25575. Associe-o a 127.0.0.1 e aceda-lhe através de um túnel SSH. Execute também o servidor de jogos com o seu próprio utilizador sem privilégios, para que uma falha num mod não consiga alcançar o resto da máquina. Os primeiros dez minutos num VPS novo aborda a conta de utilizador e o reforço da segurança do SSH que esta secção pressupõe que já tenha feito.

Execute o servidor com systemd para que seja reiniciado

Um servidor iniciado manualmente numa sessão SSH termina quando a sessão é fechada e continua parado depois de um reboot. O systemd resolve ambos os problemas. Escreva /etc/systemd/system/minecraft.service:

[Unit]
Description=Minecraft Java server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=minecraft
WorkingDirectory=/opt/minecraft
ExecStart=/usr/bin/java -Xms4G -Xmx4G -jar server.jar nogui
Restart=on-failure
RestartSec=15
TimeoutStopSec=180

[Install]
WantedBy=multi-user.target

Restart=on-failure reinicia o servidor depois de uma falha e mantém-no parado depois de um encerramento normal, que é o comportamento pretendido. Restart=always interfere sempre que parar o servidor deliberadamente. TimeoutStopSec=180 é mais importante do que parece. systemctl stop envia SIGTERM; o servidor vanilla do Minecraft captura esse sinal e guarda o mundo antes de sair. Quando o tempo limite termina, o systemd envia SIGKILL. Um mundo grande pode demorar mais do que os 90 segundos predefinidos a ser gravado, e tudo o que ainda não tiver chegado ao disco quando SIGKILL for enviado perde-se.

sudo systemctl daemon-reload
sudo systemctl enable --now minecraft
sudo journalctl -u minecraft -f

Um arranque bem-sucedido termina com uma linha semelhante a Done (12.345s)! For help, type "help". Se a unidade alternar entre activating e failed, journalctl -u minecraft -n 50 contém o motivo. Normalmente, trata-se de um caminho incorreto em WorkingDirectory ou de um heap maior do que a memória disponível no servidor.

O systemd não fornece uma consola interativa, por isso planeie isso antecipadamente. Use RCON em localhost para executar comandos ou execute o servidor dentro de uma sessão tmux. Este é o mesmo procedimento que mantém uma sessão longa do Claude Code ativa num VPS entre logins.

Os servidores de jogos distribuídos através do Steam precisam do SteamCMD antes de qualquer uma destas etapas. O pacote do Ubuntu é um binário de 32 bits, por isso a linha da arquitetura está presente. Se ignorar essa linha, apt informa que não existe nenhum candidato de instalação:

sudo add-apt-repository multiverse
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd

Alguns servidores de jogos aumentam o consumo de memória quanto mais tempo permanecem em execução. Um reinício agendado para uma hora de menor utilização é a solução normalmente adotada, e não uma correção. Um temporizador do systemd que chama systemctl restart é mais fácil de verificar do que uma entrada do cron, porque systemctl list-timers mostra exatamente quando será executado da próxima vez.

Faça backup do mundo regularmente

Tudo num servidor de jogo pode ser substituído, exceto o diretório do mundo e os dados dos jogadores. Reinstalar o jogo demora minutos. Reconstruir o que o seu grupo construiu demora meses.

Um backup seguro é feito quando nada está a escrever. Parar o servidor durante um minuto é a forma mais simples de garantir isso:

sudo systemctl stop minecraft
sudo tar czf /var/backups/mc-$(date +%F).tgz -C /opt/minecraft world world_nether world_the_end
sudo systemctl start minecraft

Se uma pausa noturna for inaceitável, faça primeiro o flush do mundo. Na consola do Minecraft, save-off interrompe o autosave, save-all flush grava tudo o que ainda está pendente e save-on volta a ativar o autosave depois de a cópia terminar. Copiar um mundo enquanto o servidor está a escrever pode guardar um ficheiro de região apenas parcialmente escrito. Só descobrirá isso no dia em que precisar de fazer o restore.

Mantenha pelo menos uma cópia fora da máquina. Um backup no mesmo disco não sobrevive à falha do disco. Um snapshot do fornecedor é uma conveniência, não um backup, porque fica na mesma conta que poderá perder. Os backups agendados do restic para armazenamento externo tratam da retenção e da deduplicação. Assim, um mês de cópias noturnas do mundo não enche o seu volume.

Depois, faça um restore. Um backup que nunca foi restaurado é apenas uma suposição. Extraia o arquivo da noite anterior para um diretório separado, aponte um servidor de teste para esse diretório e confirme que o mundo é carregado e que os edifícios estão onde os deixou.

Confirme tudo antes de se comprometer

Compre um mês em vez de um ano e faça um teste com jogadores reais durante uma noite. Execute o teste de thread única sysbench e peça a todos os jogadores para executarem mtr em direção ao servidor. O procedimento completo de benchmark de VPS explica essas ferramentas passo a passo e mostra como é um resultado problemático. Quanto custa realmente um VPS por mês ajuda a confirmar se está a pagar pelo recurso que limita o servidor, e não pelo que aparece com o maior valor na página do plano.

Dois artigos continuam a partir deste ponto. Como criar um servidor Minecraft num VPS apresenta, passo a passo, tudo o que foi descrito acima, aplicado ao jogo com que a maioria das pessoas começa. A lista mais abrangente do que um VPS pode executar é útil se preferir que o servidor faça algo produtivo entre as noites de jogo.

FAQ

Posso jogar num VPS em vez de comprar um PC para jogos?

Não. Um VPS standard não tem GPU, apenas um adaptador de ecrã virtual para a consola do fornecedor. Depois de instalar um ambiente gráfico, glxinfo -B indica o renderizador por software llvmpipe, e um jogo 3D corre a poucos fotogramas por segundo. Mesmo com uma GPU associada, o jogo remoto acrescenta codificação e descodificação de vídeo à viagem de ida e volta de cada fotograma, e RDP e VNC nunca foram concebidos para isso. Um VPS serve para alojar o servidor dedicado ao qual o seu grupo se liga. Alugue tempo de GPU ou use um serviço de cloud gaming se pretende jogar.

De quantos núcleos de CPU precisa um servidor de jogos?

Dois núcleos rápidos são melhores do que oito lentos na maioria dos jogos, porque a simulação do mundo corre numa thread principal e os núcleos adicionais não conseguem ajudar essa thread a cumprir o prazo de 50 ms. Compare os planos candidatos com sysbench cpu --cpu-max-prime=20000 --threads=1 run e consulte o valor de eventos por segundo. Vale a pena pagar por núcleos adicionais quando também executa um segundo servidor ou uma base de dados na mesma máquina, porque essas cargas podem então ser executadas sem retirar tempo à thread dos ticks.

De quanta RAM precisa um servidor de Minecraft?

Cerca de 2 GB de heap para um mundo vanilla com aproximadamente 10 jogadores, e 8 GB para um modpack grande com o mesmo número de jogadores. Defina -Xms e -Xmx com o mesmo valor e deixe 1 GB a 2 GB da máquina livres para o sistema operativo, porque a JVM usa memória fora da heap e o kernel precisa de page cache. Uma heap maior do que a máquina faz com que o processo seja terminado pelo kernel. Isto aparece em dmesg como uma linha de falta de memória, e não como um erro de Java.

Porque ficam os meus jogadores com lag quando o servidor ainda tem CPU e RAM disponíveis?

Há duas causas compatíveis com essa descrição. Consulte o log do servidor à procura de Can't keep up! Is the server overloaded?. Isto significa que a thread principal única não cumpriu o orçamento de 50 ms por tick enquanto os outros núcleos permaneciam inativos. Se essa linha não aparecer, o problema está no percurso de rede. Nesse caso, peça a cada jogador para executar mtr -rwzc 100 203.0.113.10 contra o endereço do seu servidor e ler a última linha. Verifique também a coluna st em vmstat 1: um steal time acima de alguns por cento significa que o host está sobrelotado. A CPU inativa que vê não está realmente disponível para si.

Que portas preciso de abrir para um servidor de jogos?

Apenas a porta do próprio jogo e a porta do SSH. Minecraft Java usa TCP 25565, Minecraft Bedrock usa UDP 19132, Valheim usa UDP 2456 e 2457, e Palworld usa UDP 8211. Adicione a regra do SSH antes de executar ufw enable, ou perderá o acesso à máquina. Lembre-se de que muitos fornecedores executam uma segunda firewall no painel de controlo, e a porta tem de estar aberta em ambas. Nunca abra o RCON na porta 25575 para a Internet, porque utiliza uma única palavra-passe enviada em texto simples.