Se o servidor anuncia um limite de jogadores diferente de max-players em server.properties, Paper pode estar recebendo um override como --max-players no startup. A referência de CLI informa que argumentos de linha de comando prevalecem sobre propriedades do arquivo. Em rede com Velocity, o status exibido ao público também pode vir do proxy, não do backend.

Para ajustar slots corretamente, descubra qual instância responde ao jogador, qual comando inicia cada processo e qual limite é mostrado na consulta de status.

Entenda as fontes do limite

max-players em server.properties configura quantidade máxima no servidor. CLI pode substituir via -s ou --max-players. Painel pode gerar argumento dinamicamente. Proxy pode exibir sua própria informação ou agregar estado. Um plugin de status também pode alterar apresentação.

Editar arquivo sem conferir estas fontes cria inconsistência: jogador vê 100 vagas, mas backend aceita 40; fila considera limite diferente; monitor alerta quando status muda. A configuração precisa ter fonte autoritativa clara.

Slot anunciado não é capacidade técnica. Um servidor pode aceitar menos que o valor mostrado por causa de plugin, proxy ou limite do host. Não aumente número público sem teste de CPU, TPS, banco, tráfego e login.

Inspecione comando e instância ativa

Leia saída de startup para caminho do JAR e argumentos, inclusive painel e container. Verifique se há --max-players após o JAR e se o comando usa `-c` para outro arquivo de propriedades. Compare diretório de trabalho e logs.

Em rede proxyada, conecte pela rota pública e, a partir de uma ferramenta autorizada, consulte cada backend. Não exponha backend diretamente para teste. Observe qual resposta o lobby e o proxy enviam aos clientes.

Confira se status plugin ou API de lista usa valor estático. Mudança correta no Paper pode não atualizar dashboard que mantém cache. Atualize a fonte e aguarde TTL definido.

Calcule capacidade e filas

Defina limite com base em teste representativo de jogadores e modos. Registre MSPT, latência, memória, CPU, rede e tempo de login. Teste eventos e exploração, não apenas players parados no lobby. Use margem de segurança em vez de extrapolar jogador por GB.

Se uma fila gerencia vagas, ela deve conhecer limite efetivo do backend, jogadores já conectados e capacidade da rede. Diferencie vaga do lobby e vaga total. Teste reconnect e troca de servidor para evitar mandar jogadores ao backend cheio.

Durante pico, acompanhe joins, erros, espera e carga. Limite CLI pode ser diferente em cada backend; documente distribuição por modo. Não prometa uma contagem agregada sem contabilizar conexões compartilhadas e slots reservados para staff.

Ajuste sem quebrar status

Escolha se painel ou `server.properties` será a fonte. Remova override duplicado ou atualize-o deliberadamente. Faça cópia do startup script e arquivo, altere em staging e reinicie. Confirme status externo, login até o limite e mensagem para jogador excedente.

Teste com um jogador autorizado e um não autorizado, modo privado e proxy. Não simule dezenas ou centenas de conexões em produção. Em staging, aumente gradualmente e pare ao atingir limites de segurança.

Se valor ainda não corresponde, procure plugin, caching, argumento oculto ou outra instância. Não altere várias fontes no mesmo momento. Capture status response e logs sanitizados.

Cuide de security e proxy

Não exponha backend para que ferramentas de status consigam consultá-lo. Configure firewall e forwarding seguro conforme docs de Velocity. Modern forwarding não substitui firewall e limite de slots não valida identidade de jogador.

O serviço de status público não deve retornar informação privilegiada. Se usa `hide-online-players` ou plugin de status, teste a lista sem OP. Não anuncie contagem falsa para parecer lotado ou vazio.

Restrinja comandos e gerenciamento do proxy; quem altera slots pode afetar disponibilidade. Mantenha log de mudanças e acesso individual de painel.

Documente o valor efetivo

Registre por servidor: arquivo usado, argumento CLI, limite efetivo, status publicado, proxy e responsável. Inclua última medição de capacidade e condição para revisão. Isso ajuda suporte a resolver divergência sem editar arquivo ao acaso.

Depois de atualizar Paper, painel ou Velocity, repita teste de status, fila, login e saturação. Argumentos e defaults podem mudar, e template pode restaurar valor antigo.

Uma configuração bem gerida alinha valor anunciado, vaga aceita e capacidade medida. O número no arquivo é apenas uma fonte possível dentro desse fluxo.

Revise ordem de entrada e fallback

Velocity pode tentar um servidor alternativo quando login falha ou jogador é expulso. Verifique lista try e limite de cada backend. Um servidor de fallback também pode estar cheio; teste a mensagem recebida e que a fila não envia pessoa num ciclo infinito.

Quando um backend fica offline, proxy pode mostrar capacidade parcial ou indisponível. Status público deve representar rede, mas monitoramento interno precisa identificar qual modo falhou. Separe indicador de uptime da contagem de slots para não gerar alerta enganoso.

Defina se slots temporários são reservados para atualização, staff ou evento. Remova reserva depois e registre quem pode alterá-la. Uma fila justa considera prioridade declarada, não uma diferença oculta entre número anunciado e aceito.

Faça simulação de lotação

Em staging, preencha slots com contas de teste, tente uma entrada adicional, reconecte alguém e troque de backend. Valide mensagem, fila, bypass permitido, status e log. Confirme que o servidor continua responsivo e não aceita mais do que a política.

Teste alteração de limite para baixo com jogadores online. Comportamento de sessões existentes pode variar entre Paper e proxy; não presuma expulsão ou preservação. Avise equipe e use janela controlada.

Se status não acompanha backend, investigue cache e plugin. Guarde resposta antes/depois e valor efetivo. Esse teste fecha o ciclo entre interface pública, configuração e capacidade real.

Teste vagas reservadas e exceções

Alguns grupos, como staff de emergência ou participantes de evento, podem ter vaga reservada. Documente como bypass funciona no proxy e no Paper. A propriedade e OP podem afetar capacidade de maneiras diferentes, então teste conta normal, staff e reconnect.

Evite reservar vagas sem transparência. Configure fila para mostrar quando espaço é reservado e quem pode usar. Faça teste com slot cheio, reconexão e jogador enviado de um backend para outro.

Se o proxy redireciona usuários para vários modos, verifique que a ocupação agregada não excede banco ou conexão compartilhada. Distribuição de slots é política da rede, não apenas parâmetro de cada Paper.

Investigue divergência por cache

Monitor externo pode armazenar status por intervalo. Aguarde TTL e force refresh pelo mecanismo autorizado antes de concluir que o valor não mudou. Compare resposta bruta de status e interface gráfica.

Se status do proxy mostra capacidade fixa, atualize configuração do proxy ou plugin responsável. Reinicie somente componente necessário e teste que os backends continuam seguros. Não exponha host interno para fazer status funcionar.

Guarde a resposta antes/depois e o caminho consultado. Isso acelera tickets com diretórios, bots ou ferramentas que apresentam valor diferente do Minecraft client.

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.