A propriedade max-players em server.properties define o limite configurado de jogadores simultâneos. Ela é um teto administrativo, não uma medição de quantas pessoas sua CPU, memória, rede e plugins conseguem atender com boa experiência. Um servidor pode aceitar o valor configurado e ainda apresentar TPS baixo, filas ou timeouts muito antes de alcançá-lo.

Use o limite junto de teste de carga controlado, observação em horário de pico e política de fila. Em rede Velocity, verifique ainda o que o proxy publica e como vagas são distribuídas entre backends. Aumentar um número sem capacidade não cria recursos.

Defina capacidade pelo comportamento real

Registre MSPT, TPS, heap, GC, CPU, disco, tráfego e erros de conexão com população em diferentes níveis. O custo muda conforme a atividade: vinte jogadores no lobby não equivalem a vinte pessoas explorando chunks novos, construindo fazendas ou participando de minigame com plugins pesados.

Identifique o perfil do seu modo. Survival pode carregar mundos e entidades; minigame concentra eventos, scoreboards e teleporte; lobby pode ter NPCs, partículas e mapas. Teste cenários representativos, não apenas conexões ociosas. Perfil spark enquanto a carga ocorre e use os resultados para localizar o trabalho dominante.

Estabeleça uma meta de qualidade: MSPT aceitável, tempo de login, latência, disponibilidade de disco e taxa de erro. O limite deve ficar dentro dessa capacidade observada, com margem para picos, atualizações e tarefas de manutenção.

Planeje crescimento e picos

Uma campanha, evento ou anúncio pode levar a uma onda de conexões. Monitore quantidade de tentativas, joins concluídos, tempo de entrada e integrações de login. A opção max-joins-per-tick pode adiar joins excedentes por tick, mas não aumenta o número total de jogadores que o host suporta. Planejamento de pico envolve também proxy, autenticação, banco e equipe.

Se o servidor atinge o limite com frequência, confira se jogadores ociosos ocupam vagas, se timeout atende a política e se existe fila clara. Não expulse usuários automaticamente sem avisar. Uma fila com informação de posição e regras transparentes costuma ser melhor que conexão falhando sem explicação.

Quando dois backends fazem parte da mesma rede, decida se max-players se aplica por modo, por servidor ou à rede inteira. A soma dos limites não corresponde necessariamente à capacidade de um único banco ou proxy compartilhado.

Use ferramentas de teste com responsabilidade

Faça teste de carga somente em instância controlada, com contas autorizadas e sem atingir serviços de terceiros. Copie plugins e configuração relevantes, mas isole integrações de produção como loja, Discord, pagamentos e bancos. Um teste que dispara ações reais pode afetar jogadores e gerar dados duplicados.

Aumente conexões em etapas, monitore recursos e interrompa ao chegar aos critérios de segurança definidos. Observe login, mudança de mundo, combate, inventário e saída. Uma ferramenta que abre sockets sem completar o protocolo não representa jogadores reais, e um bot que automatiza gameplay precisa respeitar termos do serviço e limites do host.

Repita em horário equivalente e guarde ambiente, versões, número de clientes e ações. Use a margem entre limite testado e limite configurado para cobrir variação, não uma promessa fixa de jogador por GB de RAM.

Configure também proxy e status

Se usa Velocity, confirme que o proxy e os backends mostram o estado esperado. O MOTD e status podem ser servidos pelo proxy, enquanto o backend tem seu próprio limite. Teste login pela rota pública e confira como o usuário recebe mensagem de lotação.

Não exponha backend para permitir testes externos. Use firewall, rede privada e forwarding conforme documentação oficial. O limite de jogadores não é controle de acesso e não protege um servidor offline-mode aberto contra conexão direta.

Integrações de lista e monitoramento podem ler max-players e contagem para status público. Se esconder a população, confirme os efeitos no monitor. Teste a informação que um jogador externo recebe sem privilégios administrativos.

Faça alteração com rollback

Antes de subir o teto, copie server.properties e defina janela de observação. Altere apenas max-players, reinicie ou aplique pelo mecanismo documentado e acompanhe. Se a experiência piorar, restaure valor anterior ou ative fila temporária com comunicação.

Se baixar o limite abaixo da quantidade online, observe como a versão e o proxy tratam conexões existentes. Não assuma que jogadores serão expulsos imediatamente ou preservados sem efeito; teste antes. Planeje alteração com aviso.

Documente limite, capacidade medida, modo, data e condição para reavaliar. Refaça teste quando hardware, Paper, Java, plugin principal ou topologia mudarem. Uma medição antiga deixa de representar o servidor após atualização relevante.

Proteja qualidade e saúde da comunidade

Capacidade também é percepção. Jogadores podem tolerar espera se recebem informação clara, mas não lag imprevisível que perde progresso. Explique horários de pico, eventos e limites sem inflar números em diretórios. Prefira uma rede saudável com limite realista a aceitar qualquer conexão e operar degradado.

Revise logs de suporte e feedback junto às métricas. Uma população menor pode reportar problemas porque o modo é complexo; número de usuários não identifica sozinho o gargalo. Use perfil e reprodução para priorizar mudanças.

Quando a capacidade cresce, planeje recursos, operação e proteção. Mais slots aumentam tráfego, custo de banco e carga de equipe. Defina alertas e uma pessoa responsável antes de publicar novo limite para a comunidade.

Faça orçamento por camadas

Liste componentes compartilhados: proxy, autenticação, banco, armazenamento, web map, Discord e APIs. Um backend pode estar folgado enquanto banco ou proxy se torna o gargalo. Calcule capacidade considerando o caminho inteiro do login e da troca entre servidores, não apenas RAM alocada ao Paper.

Revise custo e operação de suporte. Um limite mais alto pode aumentar tickets, moderação, espaço de backup e resposta a incidentes. Garanta que há responsáveis para incidentes em horários de pico e que o painel não permite reinícios concorrentes.

Use testes graduais para identificar o ponto em que a qualidade cai e mantenha margem abaixo dele. O teste não deve buscar travar o host; pare com sinal de saturação e guarde logs. Um benchmark destrutivo que corrompe mundo ou derruba nó não é um bom plano de capacidade.

Trate número de slots como promessa pública

Listagens e anúncios podem mostrar a capacidade configurada. Publique um número que a rede realmente consegue atender e atualize quando arquitetura muda. Se a população ultrapassa vagas, informe fila e horários; não infle o limite para parecer maior.

Se usa múltiplos modos, defina limites por modo e uma regra de prioridade transparente. Compartilhar o mesmo proxy pode criar competição por CPU mesmo quando cada backend está abaixo do próprio limite.

Registre sinais que disparam expansão: p95 de MSPT, erros de login, latência, ocupação de CPU e disponibilidade. Reavalie em cada temporada em vez de esperar reclamações repetidas.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.