Hospedagem Velocity para redes Minecraft

Um Paper bem ajustado aguenta bastante gente antes de um proxy fazer sentido. O que empurra o projeto para o Velocity é a quantidade de processos Java em paralelo, não a lotação.

A conta vira quando as instâncias deixam de ser compatíveis: versões diferentes, carregadores de mod diferentes, ciclos de reinício diferentes. Nada disso cabe em um servidor só, e é aí que o proxy se paga.

O contrário vale com a mesma força: o proxy é mais um serviço para monitorar e o ponto por onde todo mundo passa. Se você tem um servidor e quer só mais um mundo, um plugin de mundo múltiplo resolve melhor.

Quem autentica o jogador na Mojang é o proxy, então os backends rodam com online-mode desligado e acreditam no que ele conta sobre quem chegou. No forwarding legado essa informação viaja anexada ao handshake, sem assinatura.

O modern forwarding fecha a brecha com segredo compartilhado: o Velocity assina os dados do jogador com o conteúdo de forwarding.secret e o backend recusa a conexão se a assinatura não bater. No Paper, em paper-global.yml.

Dois detalhes derrubam mais gente que a teoria. O segredo precisa bater byte a byte, e uma quebra de linha no fim do arquivo já recusa todo mundo. E quem entra pelo proxy ganha UUID online: ligar forwarding num servidor antigo obriga a migrar inventário e permissão.

Um backend com online-mode desligado aceita qualquer nome. Se a porta dele responde na internet, alguém conecta por fora dizendo que é o dono e entra com todas as permissões. Não é falha do Velocity nem do BungeeCord: é o custo de delegar a autenticação e parar na metade.

A regra: só a porta do proxy fica pública, 25577 por padrão, e cada backend aceita conexão apenas do IP dele. Com UFW é uma regra por backend mais a negação padrão de entrada. Depois teste de outra rede: se a conexão direta completar, a network está aberta.

O Velocity não carrega chunk, não simula entidade e não guarda mundo. Ele lê pacote, decide o destino e escreve de novo, para cada jogador, nos dois sentidos. Aumentar o heap não muda quase nada: aperta primeiro a taxa de pacotes e o limite de conexões abertas.

Por isso uma VPS pequena sustenta o proxy enquanto os backends ficam nas máquinas com folga de CPU. O que não dá para economizar é distância: cada salto entre as pontas entra no ping, e com as duas em São Paulo essa camada some da conta.