network-compression-threshold em server.properties define o tamanho a partir do qual pacotes de rede são comprimidos. A documentação atual do Paper informa um valor padrão de 256 bytes e que um número negativo desativa a compressão. O que parece um ajuste simples envolve duas coisas escassas: largura de banda e tempo de CPU.

Comprimir pacotes pode reduzir o volume enviado, mas consome processamento no servidor e nos clientes. Se a infraestrutura tem banda disponível e CPU limitada, comprimir mais pode piorar latência. Se a rede está limitada e há margem de CPU, uma política diferente pode ser útil. O resultado depende do tráfego real do servidor.

O que o limite representa

O valor é um limiar em bytes para pacotes que podem ser comprimidos. A semântica de fronteira e os detalhes do protocolo devem ser confirmados na versão de Minecraft usada. Em geral, baixar o limiar faz mais pacotes candidatos passarem pela compressão; aumentar tende a deixar pacotes menores sem comprimir. Um valor negativo desativa o mecanismo, conforme o campo descrito pelo Paper.

Pacotes pequenos podem ficar maiores depois do cabeçalho de compressão, então comprimi-los não significa sempre economizar. O servidor escolhe um limite justamente para equilibrar tamanho e custo. Não presuma que “threshold menor” sempre economiza banda ou que “compressão desligada” sempre melhora desempenho.

O limiar não altera view distance, simulação, criptografia, capacidade do link ou limites de firewall. Não confunda compactação de tráfego de rede com compressão de arquivo de região no disco. São caminhos diferentes e suas opções têm efeitos diferentes.

Descubra qual recurso está limitado

Registre CPU por núcleo, uso de rede, latência de jogadores, MSPT e quantidade de usuários. Teste a partir de regiões com atividade parecida. Se a conexão externa está saturada, comprimir pode ter valor; se o servidor tem CPU cheia por entidades ou plugins, aumentar trabalho de compressão pode prejudicar ticks.

Observe o perfil do tráfego durante movimentação, chat, inventário, geração de chunks e eventos. A quantidade de pacotes e o tamanho médio variam conforme atividade e plugins. Um teste parado no spawn não representa uma noite de exploração ou minigame com muitos efeitos.

Em uma rede Velocity, entenda quais conexões usam proxy e quais configurações se aplicam a cada trecho. Configure e teste proxy e backend conforme documentação. Evite assumir que a compressão do backend representa o tráfego cliente-proxy da mesma forma.

Meça o custo de CPU e banda

Faça benchmark em ambiente de staging com clientes de teste e uma carga controlada. Anote valor original e mude apenas o limiar. Compare bytes por segundo, CPU do thread de rede e do servidor, latência, MSPT, perda de pacotes e estabilidade percebida. Rode tempo suficiente para atravessar eventos variados e repita mais de uma vez.

Uma diminuição de tráfego que vem acompanhada de CPU maior pode não ser vantajosa. Da mesma forma, aumentar tráfego em link congestionado pode causar timeout e desconexão. Defina critérios antes do teste: quanto de banda está disponível, qual limite de CPU é aceitável e qual p95 de latência é necessário.

Não use resultados de hardware diferente sem ajuste. Processador, largura do link, sistema operacional, proxy e perfil de clientes influenciam o balanço. Se não consegue medir um ganho ou efeito, preserve o padrão documentado em vez de adotar um valor extremo por imitação.

Edite server.properties corretamente

Encontre o arquivo da instância que realmente está sendo executada e faça backup. Pare o servidor de maneira controlada antes de editar, evitando que o processo reescreva valores antigos. Altere uma linha, mantenha o formato numérico válido e reinicie segundo a necessidade da versão.

Confira a configuração após o boot. Painéis podem manter múltiplos arquivos de template ou recriar propriedades. Verifique startup logs, caminho de trabalho e a versão ativa. Documente valor anterior, atual, motivo e resultado do teste.

Se houver impacto negativo, restaure imediatamente o valor anterior. Não misture a mudança de compressão com upgrade de proxy, plugin, distância de chunks ou versão de Minecraft. Isolar alterações simplifica diagnóstico e rollback.

Segurança e compatibilidade importam

Pacotes comprimidos continuam sujeitos à criptografia e demais proteções do protocolo conforme configuração do servidor; compressão não substitui autenticação ou defesa contra abuso. Mantenha Paper e Velocity atualizados, use forwarding seguro e firewall nos backends conforme a arquitetura.

Clientes, versões de protocolo e plugins que manipulam pacotes podem influenciar o comportamento. Teste cliente Java e Bedrock se a rede usa Geyser, além de versões compatíveis que o proxy aceita. Verifique que handshake, resource pack, troca de servidor e conexões após o login continuam funcionando.

Não publique uma alteração como solução universal. Registre evidências do seu ambiente e os trade-offs. Se uma atualização do servidor alterar implementação, repita os testes e consulte as referências oficiais da nova versão.

Quando deixar o padrão

Se rede e CPU estão dentro de capacidade, a latência é boa e não há reclamações reproduzíveis, não existe obrigação de ajustar esse valor. Mudar parâmetros estáveis sem benefício medido cria uma variável extra para futuras falhas.

Se o gargalo está em banda, procure primeiro jogadores usando redes ruins, geração excessiva, plugin enviando atualizações redundantes ou proxy mal dimensionado. Se o problema é CPU, capture perfil e resolva o método caro. Otimizar o threshold pode ser experimento secundário e bem medido, nunca substituto para identificar o trabalho dominante.

Guarde o resultado com métricas e reteste após qualquer troca de datacenter, processador, versão ou topologia. Assim, a política de compressão permanece alinhada aos recursos reais e à experiência que a comunidade precisa.

Investigue as camadas da rota de rede

Desenhe a rota entre jogador, proxy e backend. Identifique onde termina TLS ou criptografia do protocolo, quais conexões cruzam internet e quais passam por rede privada, e que processo consome CPU. Um valor aplicado no backend pode não ter a mesma relevância para o trecho público servido por Velocity. Consulte os documentos dos componentes e registre a topologia.

Compare também a rede do host e a do jogador. Perda de pacotes, rota congestionada, Wi-Fi instável e saturação do datacenter podem parecer lentidão de jogo. Antes de ajustar compressão, use ferramentas de diagnóstico de rede, horários e regiões afetadas, sem expor endereços de jogadores publicamente.

Se uma versão específica do cliente apresenta o problema, compare com outra versão oficialmente suportada e verifique plugins de protocolo. Não force jogadores a desativar recursos de segurança nem instale clientes modificados sem validar origem. A compatibilidade precisa ser reproduzida com informação concreta.

Considere tráfego adicional de recursos e plugins

Resource packs, mapas web, proxies de voz e APIs costumam usar caminhos e protocolos diferentes da compressão de pacotes Minecraft. O limiar de rede do servidor não reduzirá automaticamente o tamanho de arquivos servidos por um CDN ou hospedagem externa. Meça cada canal separadamente para encontrar o maior consumidor de banda.

Plugins podem enviar atualizações frequentes de scoreboard, partículas, hologramas ou inventários. Uma compressão mais agressiva pode esconder parcialmente o volume, mas manter a lógica que gera pacotes desnecessários. Perfil o plugin, reduza atualizações redundantes e compare com o protocolo em uma cópia antes de alterar globalmente.

Durante um evento, uma explosão de mensagens ou entidades pode mudar o perfil de tráfego. Teste cenários representativos com a mesma composição de jogadores e plugins. O objetivo é limitar custo total mantendo latência aceitável, não apenas reduzir a métrica de bytes transferidos.

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.