O IP Forwarding do BungeeCord garante que um backend receba o IP real do jogador, a UUID online e as informações de perfil, mesmo que a ligação TCP venha do proxy. Para isso, quatro valores precisam estar alinhados, e a porta do backend deve estar protegida contra ligações diretas.
ip_forward: truenão é uma firewall. O formato clássico do BungeeCord não tem nenhum segredo de assinatura específico do proxy. Quem alcançar um backend em Offline-Mode desprotegido pode falsificar dados de forwarding e fazer-se passar por outro jogador.
Os quatro valores
| Local | Ficheiro/campo | Valor normal |
|---|---|---|
| BungeeCord | config.yml → online_mode |
true |
| BungeeCord | config.yml → ip_forward |
true |
| Backend | server.properties → online-mode |
false |
| Backend | spigot.yml → settings.bungeecord |
true |
No Paper atual, junta-se ainda:
# config/paper-global.yml
proxies:
bungee-cord:
online-mode: true
Este valor do Paper corresponde ao Online-Mode do proxy. Ele permanece true, embora server.properties no backend use online-mode=false.
Porque precisas de um backup antes da alteração
Sem forwarding, o backend em Offline-Mode gera uma UUID a partir do nome do jogador. Com forwarding correto, ele recebe a UUID vinda da autenticação online. Estes valores não são idênticos. Inventário, Enderchest, cargos ou dados de economia podem depois parecer desaparecidos, embora estejam guardados sob a UUID antiga.
Antes da alteração:
- faz backup dos mundos,
playerdata, permissões e bases de dados de plugins; - testa um restauro;
- documenta a UUID antiga e a esperada para um jogador de teste;
- verifica ferramentas de migração específicas dos plugins;
- nunca alteres nomes de ficheiros às cegas sem conhecer as referências e o formato dos dados.
O guia existente sobre troca de versão descreve um caminho adequado para backup, cópia e rollback.
Passo 1: Configurar o proxy
Para o BungeeCord corretamente e edita a config.yml atual:
online_mode: true
ip_forward: true
Mantém a autenticação pública ativa no proxy. Verifica em paralelo os listeners, servers e priorities com a referência dos campos de config.yml.
Passo 2: Configurar o backend
Para completamente cada backend e altera:
# server.properties
online-mode=false
# spigot.yml
settings:
bungeecord: true
No Paper, define adicionalmente o valor proxies.bungee-cord.online-mode mostrado acima. Inicia primeiro os backends e depois reinicia o BungeeCord. Um reload parcial não chega para esta alteração de identidade.
Passo 3: Fechar o caminho para o backend
Permite a porta TCP do backend apenas a partir do caminho de proxy verificado. Dependendo da tua infraestrutura, isso pode ser loopback, uma rede privada/VPN real ou uma regra de firewall restrita. Em ambientes com containers, uma IP interna por si só não chega: uma instância estranha na mesma bridge não deve poder passar por proxy.
Na game-serverhosting, o Guard ativo associa backends BungeeCord suportados à instância concreta do proxy e resolve novamente a origem atual do respetivo container. Stop, origem ausente ou ambígua continuam em modo drop-only. Caminhos Same-Node, Cross-Node e External-Backend foram testados com join real via proxy; acesso direto independente permaneceu bloqueado. Isto é uma afirmação sobre estes caminhos comprovados, não uma garantia para redes externas arbitrárias de outros providers.
O guia completo de setup organiza estas variantes de rede.
Como enquadrar corretamente o BungeeGuard
O BungeeGuard acrescenta um token partilhado ao formato legacy. Usa pelo menos a versão 1.4.0. A página de segurança do projeto documenta uma exposição de token em setups BungeeCord antigos; depois do upgrade, um token possivelmente afetado deve ser rodado no proxy e nos backends.
- gera o token localmente com entropia suficiente;
- nunca o copies para tickets, logs, screenshots ou Git;
- atualiza o proxy e todos os backends de forma coordenada;
- remove o token antigo só depois de um teste bem-sucedido;
- se a versão for desconhecida/antiga, trata o estado como unverified.
O BungeeGuard é especialmente útil em Shared Hosting, mas não substitui uma solução disponível de firewall/rede privada como primeira camada de proteção.
Verificação: quatro sinais separados
- Processo: proxy e backend estão completamente iniciados.
- TCP: o proxy alcança o listener do backend.
- Join na lobby: um jogador real autenticado entra no backend através do proxy.
- Identidade: o backend vê a UUID online e a IP do cliente esperadas, não uma UUID offline nem apenas a IP do proxy.
Depois vem o teste negativo: uma origem independente não deve conseguir alcançar a porta do backend. Um listener aberto ou um ping bem-sucedido por si só não prova um join.
Erros típicos
| Sintoma | Causa | Próximo passo |
|---|---|---|
| todos os jogadores têm a IP do proxy | ip_forward ou bungeecord desligado |
verificar os dois lados e reiniciar completamente |
| jogador tem inventário novo | o modo de UUID mudou | manter o backup, comparar UUIDs, migrar conforme o plugin |
If you wish to use IP forwarding... |
backend espera forwarding, mas o proxy não o envia | verificar o valor do proxy e a config exata iniciada |
| join direto possível com nome alheio | backend acessível publicamente | corrigir firewall/rede privada imediatamente |
| proxy também não alcança o backend | liberação tem origem errada/obsoleta | reavaliar a associação concreta do proxy, sem abrir demais |
| sem join depois do update do BungeeGuard | token inconsistente | verificar versões redigidas e rodar de forma coordenada |
Se faltar um destino de arranque, o guia de erros de fallback ajuda. Os domínios continuam a apontar para o proxy; para isso, usa o guia de domínio/SRV.
Plugins e crossplay
Plugins de permissões, bans e economia são especialmente sensíveis a UUID. Faz backup dos dados deles e verifica se é necessário um componente no proxy e outro no backend. O guia de plugins explica a separação de plataformas.
O Geyser, numa rede com proxy, é instalado apenas no proxy. Bedrock-UDP e Java-TCP continuam a ser caminhos separados; key.pem é secreto. Configura Geyser/Floodgate só quando o forwarding Java e o caminho negativo estiverem verdes.
FAQ
ip_forward: true é uma proteção?
Não. Ele apenas garante que IP, UUID e perfil sejam encaminhados para o backend. O formato clássico não tem nenhum segredo de assinatura específico do proxy: quem alcança diretamente um backend em Offline-Mode desprotegido pode falsificar estes dados. A proteção é a fronteira de rede, não a configuração.
Porque é que no backend está online-mode=false?
Porque a autenticação contra a Mojang já acontece no proxy — caso contrário, o backend iria pedi-la uma segunda vez e rejeitaria todos os jogadores. No Paper, proxies.bungee-cord.online-mode continua mesmo assim true: este valor reflete o Online-Mode do proxy, não o do backend.
Porque é que os jogadores têm um inventário vazio depois da mudança?
Porque a UUID mudou. Sem forwarding, um backend em Offline-Mode gera a UUID a partir do nome do jogador; com forwarding, chega a UUID online real. Os dados antigos não se perderam, estão sob a UUID antiga — por isso é preciso um backup testado antes da alteração.
Preciso do BungeeGuard?
Ele acrescenta um token partilhado ao formato legacy e é sobretudo útil em Shared Hosting, onde não podes criar a tua própria regra de firewall. Usa pelo menos a versão 1.4.0 e roda o token depois de um upgrade. Ele não substitui uma solução disponível de firewall ou rede privada.
Onde fica o Geyser numa rede com proxy?
Exclusivamente no proxy, não também nos backends. Bedrock corre por UDP, Java por TCP — ambos os caminhos são verificados separadamente, e key.pem é secreto. Configura o crossplay só quando o forwarding e o teste negativo no lado Java estiverem verdes.