A opção rate-limit em server.properties define o máximo de pacotes que podem ser enviados antes de o jogador ser desconectado. A referência atual informa que definir zero desativa o limite. Isso pode ser parte da proteção contra tráfego abusivo, mas valores mal escolhidos podem interromper jogadores legítimos, mods ou plugins.

O parâmetro é descrito como limite de pacotes, não como controle de largura de banda em megabits por segundo. Não confunda com limitação de conexões, limiar de compressão, regras de firewall ou limites específicos do packet limiter da configuração global de Paper. Cada mecanismo observa ações e períodos diferentes.

O que observar antes de configurar

Comece com logs de kick, versão do servidor, proxy, plugins e mods. Pergunte se o problema ocorre para um cliente específico, durante uma ação específica ou quando a rede inteira recebe tráfego anormal. Reproduza com uma conta de teste; o número de pacotes de um cliente normal pode variar de acordo com atividade, protocolo e integrações.

Um valor baixo pode atingir conexões legítimas em sessões movimentadas ou clientes com comportamento diferente. Um valor alto pode não produzir o controle esperado contra abuso. Aplique o valor apenas depois de entender a taxa normal do seu servidor e o efeito da unidade conforme documentada na versão que usa.

Consulte as recomendações atuais do Paper e o contexto do tráfego. Não copie números de posts antigos ou de forks distintos, porque implementações e nomes de opções evoluem. A configuração de packet limiter em Paper oferece controles por pacote e ação que devem ser tratados separadamente de rate-limit.

Use defesa em camadas

Um limite no servidor não substitui firewall, proteção do provedor, proxy configurado e restrição de acesso aos backends. Em uma rede Velocity, mantenha os servidores backend alcançáveis apenas por caminhos autorizados. A documentação alerta que modern forwarding não substitui firewall; o segredo de forwarding precisa continuar privado.

Não reduza segurança de autenticação para contornar desconexões. Não compartilhe forwarding secrets, tokens, credenciais de painel ou IPs internos em logs públicos. Ao pedir suporte, remova informações que permitiriam a terceiros acessar serviços.

Se o servidor roda plugins que lidam com pacotes, como tradução de versões, cross-play ou anticheat, teste a compatibilidade antes de ativar uma política agressiva. A solução mais segura pode ser atualizar uma extensão, corrigir um loop de pacote ou ajustar proteção no proxy, em vez de desconectar toda a população acima de uma taxa arbitrária.

Faça medição e teste sem afetar a comunidade

Em staging, use a mesma versão de Paper e plugins, dados fictícios e endpoints de teste. Capture o comportamento normal em uma sessão ociosa, durante movimento, combate, inventário, troca de mundo e cross-play. Depois, reproduza somente o padrão que motivou a mudança.

Altere uma opção por vez e registre o que muda: desconexões, mensagens do log, carga, experiência de usuários e resultado de ataques simulados no seu ambiente autorizado. Não faça flood contra rede pública ou terceiros. Um limite de pacotes não deve ser validado por teste que possa derrubar infraestrutura compartilhada.

Peça a um grupo pequeno de jogadores confiáveis para tentar ações variadas durante manutenção. Use clientes e versões suportados. Se há kick em um usuário, capture o log e o cenário exato antes de aumentar ou reduzir outro valor.

Aplique alteração reversível

Faça cópia do server.properties, confira a instância correta e desligue normalmente antes de editar. Altere apenas rate-limit e reinicie. Leia o valor novamente após o boot e confirme que painel ou script não o reescreveu.

Monitore as primeiras horas e o próximo pico. Observe kicks, reportes, logins via proxy e métricas de rede. Prepare rollback para o valor anterior e mantenha uma pessoa responsável pela observação. Se a mudança causa falsos positivos, reverta antes de tentar combinar com novos filtros.

Registre versão, valor, motivo, teste e resultado. Revise após upgrade de servidor, proxy, plugins ou protocolo suportado. O histórico mostra se a decisão ainda tem motivo e ajuda a distinguir um incidente novo de uma configuração antiga.

Investigue o atacante ou causa real

Se há desconexões maliciosas ou flood, correlacione tentativas, IPs, portas, provedor e logs do proxy. Acione o suporte de rede quando necessário. Um limite de pacote no Paper vê somente o tráfego que chega à aplicação; saturação do link pode ocorrer antes que o servidor consiga agir.

Se usuários relatam kicks depois de atualização, compare a lista de plugins e proxies com a instalação anterior. Mude uma integração por vez em ambiente isolado e mantenha dados de jogador protegidos. Erro de versão de protocolo pode parecer limite de pacote, então capture primeiro a mensagem completa de conexão.

Defina a experiência esperada: versões aceitas, suporte Bedrock, mods permitidos e comportamentos de automação. Explique as regras à comunidade e disponibilize canal de reporte. Limites transparentes reduzem conflito com quem usa clientes legítimos.

Quando não mexer

Se não existe abuso ou erro reproduzível, mantenha o valor padrão documentado. O fato de existir um campo de configuração não significa que seu servidor precisa alterá-lo. Uma defesa eficaz combina observação, atualização, firewall, arquitetura segura e teste sem prejudicar jogadores.

Se um problema ocorre, corrija a causa na camada adequada e só use este limite quando tráfego legítimo e abusivo estiverem caracterizados. Segurança não é simplesmente tornar todos os valores menores: é bloquear o cenário indevido sem negar o serviço ao usuário esperado.

Diferencie o limite geral do packet limiter

A configuração global do Paper possui um packet limiter com intervalos, taxas máximas e ações, inclusive substituições por tipo de pacote. Esse mecanismo é separado de rate-limit em server.properties. Leia a documentação da sua versão e não suponha que números iguais representam a mesma janela, contagem ou ação.

Se o log aponta um tipo de pacote específico, descubra qual cliente ou plugin o produz e use a ferramenta de diagnóstico adequada. Um limite geral pode desconectar todos os usuários que ultrapassam o limiar, enquanto configuração direcionada pode oferecer outra ação, conforme esquema atual. Alterações direcionadas também podem quebrar ações legítimas, então teste cada pacote envolvido.

Evite definir duas proteções sem saber qual está respondendo. Isso dificulta correlacionar kicks e pode multiplicar falsos positivos. Registre nomes das opções, escopo, período de contagem e resposta configurada para manter o relatório claro.

Interprete evidências sem expor usuários

Guarde a mensagem de kick, horário, versão do cliente, servidor de origem e ações imediatamente anteriores. Remova IPs, UUIDs, tokens e nomes quando compartilhar com público ou autores não autorizados. Os logs internos podem conter dados pessoais; limite acesso à equipe e retenha só pelo tempo necessário.

Compare eventos de vários jogadores. Se só um cliente modificado é afetado, investigue essa instalação; se dezenas caem ao usar uma ação comum, o limite pode estar baixo ou um plugin está produzindo rajadas. Correlação não prova causa, mas orienta uma reprodução segura.

Use canais de suporte oficiais para reportar comportamentos reproduzíveis. Inclua configuração sanitizada e os passos mínimos. Nunca cole forwarding.secret, senha de RCON ou dados de autenticação, mesmo que a pessoa oferecendo ajuda pareça conhecida.

Recupere uma sessão interrompida

Após um kick, verifique se o jogador consegue reconectar e se inventário, localização e progresso persistiram. Se muitos usuários caíram durante uma atividade importante, pause-a e examine o estado antes de mandar reconectar em massa. Falhas simultâneas podem sobrecarregar ainda mais a fila de login.

Se a mudança foi recente, reverta ao valor anterior conhecido e observe. Mantenha logs da versão com problema para investigação. Não faça limpeza automática dos logs antes de confirmar que as evidências foram preservadas.

Escreva uma mensagem simples para a comunidade se o serviço foi afetado: o que ocorreu, qual grupo foi atingido, como voltar e quando haverá atualização. Evite afirmar que houve ataque até que a equipe tenha evidência. Comunicação precisa protege a confiança e evita rumores.

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.