Alojamento BungeeCord e Waterfall para network já no ar

O BungeeCord sustentou a primeira geração de networks brasileiras, e o Waterfall apareceu como fork da PaperMC: mesma API, mesmos plugins, correções de protocolo. A PaperMC declarou o Waterfall descontinuado e recomendou o Velocity. Ele funciona, mas sem desenvolvimento ativo.

Para rede nova, o menor arrependimento é o Velocity, e esta página não vai fingir o contrário. Quase todo o BungeeCord no ar hoje é herança: jogador ativo, loja a funcionar e plugins escritos contra a API net.md_5.bungee.

O que deita abaixo uma network Bungee não é lag, é autenticação. Com o ip_forward ligado no config.yml, o proxy injeta o IP e o UUID reais no handshake. Para aceitar isso, o backend corre com o online-mode desligado e a flag de bungeecord ligada no spigot.yml.

Esse handshake não vem assinado: não há segredo partilhado entre proxy e backend. Quem alcançar a porta de um backend monta o mesmo pacote e entra com o UUID que quiser, incluindo o do dono.

As defesas andam juntas. Na rede, backends à escuta só em 127.0.0.1 ou firewall que aceite apenas o IP do proxy. Na aplicação, o BungeeGuard, que cobre o dia em que alguém errar uma regra.

Ficar justifica-se em três casos: plugin de proxy sem equivalente e sem código fonte; temporada aberta, porque trocar o ponto de entrada deita abaixo o acesso de todos se correr mal; e rede grande já estável.

Congelar a versão, documentar a configuração e adiar a migração é uma decisão legítima. O que não vale é descobrir que versão está a correr só no dia do incidente.

A parte cara é o plugin de proxy: a API do Velocity é outra e nada do Bungee corre lá sem porte. Divida a pasta plugins em três pilhas: tem versão Velocity, tem substituto, ou precisa de código novo. A terceira é o orçamento.

A parte barata é o backend, porque o Velocity mantém o canal legado de plugin messaging. Some permissões, MOTD, tab e integração com o Discord. Suba o proxy novo numa porta alternativa e mude o DNS por último.