A opção use-native-transport em server.properties ativa transporte nativo de rede quando disponível. A referência do Paper descreve ganho de desempenho em Linux. O efeito depende de sistema operacional, bibliotecas nativas, kernel, virtualização e rota de tráfego; por isso, não assuma que a mesma opção ajuda em Windows ou em qualquer hospedagem.

Paper e Velocity usam Netty para conexões. O transporte nativo pode usar mecanismos específicos do sistema e requer ambiente compatível. A documentação de Velocity discute transportes nativos para a própria aplicação; uma configuração do Paper não altera automaticamente o proxy.

O que muda no caminho de rede

O processo recebe e envia dados por canais de rede. O transporte nativo pode aproveitar APIs do sistema operacional em vez do caminho padrão, potencialmente reduzindo overhead em alguns workloads. Não muda protocolo Minecraft, firewall, criptografia ou endereço de bind.

Se o servidor está limitado por geração de chunks, entidades ou plugin, trocar transporte não resolve o gargalo. A melhora pode ser invisível quando o tráfego é pequeno. Se o host usa CPU limitada ou latência de rede externa, medir o componente correto é essencial.

Bibliotecas nativas precisam ser carregadas corretamente. Container mínimo, arquitetura diferente ou dependência ausente podem alterar comportamento. Leia o log de startup e observe warnings relacionados a transporte.

Verifique compatibilidade do sistema

Confirme sistema operacional e arquitetura. A documentação menciona Linux para o benefício descrito. Em container, cheque imagem, runtime, acesso às bibliotecas nativas e política do provedor. Não use flags de kernel ou permissões privilegiadas copiadas de guias sem entender a implicação.

Em Windows ou ambientes compartilhados, mantenha padrão suportado salvo orientação oficial específica. Se houve erro de rede após ativar, teste rollback imediato antes de alterar firewall ou porta. Um warning sobre fallback pode significar que transporte nativo não está em uso.

Também confira proxy, cliente, plugin de protocolo e backend. Uma rede completa tem vários pontos de transporte; teste caminho público e ligações internas separadamente.

Meça um caso real

Registre CPU, pacotes por segundo, banda, latência, MSPT e desconexões durante uma sessão representativa. Use perfis e métricas no momento de pico. Uma comparação válida mantém número de jogadores, modo, região, versões e atividade semelhantes.

Faça staging com a mesma imagem e host sempre que possível. Compare opção ativa e inativa em várias execuções. Observe login, chat, movimento, troca de backend e encerramento. Se resultado técnico melhora, confirme que p95 de latência e estabilidade também melhoram.

Não faça stress test contra internet pública ou serviços de terceiros. Use clientes autorizados e pare ao saturar limites do provedor. A meta é comparar servidor próprio, não medir capacidade de uma rede alheia.

Ative e valide reversivelmente

Faça backup de server.properties, altere somente use-native-transport e reinicie de forma controlada. Confira startup log e conexão de teste. Se server.properties é regenerado por painel, verifique a configuração ativa depois do boot.

Monitore operações em horário de pico: login, teleporte, cross-play, resource packs e troca entre modos. Um sucesso ao entrar não prova que sessões longas ou reconexões estejam estáveis. Mantenha arquivo anterior e restaure caso haja timeout ou erro.

Documente resultado, host, kernel ou imagem, versão Java e Paper. Isso torna a decisão repetível quando a instância muda de nodo.

Segurança e rede continuam separadas

Transporte nativo não é proteção anti-DDoS nem firewall. Mantenha proxy e backend seguros, portas mínimas, forwarding compatível e ACLs. Não publique portas de gestão para testar desempenho.

Se usa Velocity, teste proxy e backend como processos separados. Um backend pode estar no mesmo host ou em outro nó. Configure cada serviço conforme a documentação de seu próprio produto, sem supor que o ajuste de Paper atinge o proxy.

Preserve credenciais e segredos em qualquer dump de ambiente. Coleta de profiling ou logs deve ser sanitizada antes de compartilhar.

Saiba quando manter o padrão

Sem gargalo de rede no perfil e sem comparação controlada, mantenha valor documentado. Otimização especulativa aumenta variáveis e não melhora jogadores. Se a rede está congestionada, investigue uplink, proxy, tráfego de plugin e distribuição geográfica.

Reavalie quando trocar sistema operacional, arquitetura, imagem ou provedor. O que funciona em Linux bare metal pode não trazer ganho em container compartilhado. Registre uma reversão simples e repita benchmark antes de fixar a escolha.

Use-native-transport pode ser útil no ambiente adequado, mas seu benefício é uma hipótese até ser medido na topologia real do servidor.

Confira kernel, permissões e container

Em Linux, a disponibilidade do mecanismo nativo depende de plataforma e bibliotecas que o processo consegue carregar. Container pode compartilhar kernel do host mas restringir syscall, acesso a arquivos ou bibliotecas. Leia erros no log; não conceda modo privilegiado ao container sem necessidade.

Atualização de kernel pode exigir restart do host para que processo use versão nova. Confirme manutenção com provedor. Se serviço opera em nó gerenciado, suporte do host deve validar requisito em vez de pedir ao cliente alteração de segurança global.

Compare ambiente de staging com produção. Imagem de desenvolvimento com bibliotecas extras pode esconder falha que acontece numa imagem enxuta.

Inclua teste de retomada

Teste não só login inicial, mas também perda curta de conexão, reconnect, troca de backend, restart gracioso e shutdown. Verifique se erros de canal, keepalive ou timeout aparecem sob tráfego normal.

Rode teste durante alguns ciclos de pico com número autorizado de usuários. Se conexões ficam estáveis e não há ganho mensurável, o padrão é opção defensável. Se há ganho, documente magnitude e condição para revisar.

Faça rollback imediatamente a qualquer mudança em desconexões ou crash. Preserve o relatório e evite alterar firewall, compression ou proxy ao mesmo tempo.

Diagnostique fallback e warnings

Se startup informa que bibliotecas nativas não podem ser carregadas, verifique log completo, arquitetura da imagem e dependências disponíveis. Não baixe bibliotecas aleatórias de sites externos para silenciar warning. Atualize imagem ou consulte o provedor sobre suporte oficial.

Compare conectividade com opção ativa e desativada. Faça ping de status, login, chat e tráfego prolongado. Um canal que abre não demonstra ausência de desconexões sob carga. Preserve capturas de perfil e hora para correlacionar erros.

Se fallback automático ocorre e serviço funciona, a propriedade pode não estar trazendo benefício porque o caminho nativo não inicializou. Documente isso para evitar acreditar que tuning está ativo quando não está.

Inclua observabilidade da camada de rede

Meça latência cliente-proxy e proxy-backend separadamente. Use conexão de monitoramento autorizada e combine com estatísticas do host. Uma média boa pode ocultar picos em horário de congestionamento; acompanhe percentis e desconexões.

Se clientes Bedrock entram por Geyser, teste também o fluxo UDP de entrada no proxy e a comunicação subsequente. O transporte nativo do Paper não substitui configuração correta de Geyser nem abertura das portas exigidas.

Depois de atualizar o kernel ou migrar container, repita o teste. O caminho nativo depende do ambiente e pode variar com recursos liberados pelo host.

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.