Como configurar o Geyser e o Floodgate para jogadores de Bedrock

O Geyser permite que jogadores do Bedrock em celulares, tablets, consoles e Windows entrem no seu servidor Java, traduzindo entre as duas edições, e o Floodgate deixa todos entrarem sem uma conta Java. Instale os dois no seu servidor Paper ou no seu proxy Velocity, coloque o transport do Geyser em both, abra a porta do Bedrock para TCP e UDP e depois confira, de fora da sua rede, se um jogador do Bedrock realmente consegue entrar.

Esse último passo é o que quase todo dono pula. O nosso pinger manda um ping Bedrock por minuto para todo servidor crossplay que publica um endereço Bedrock e, nos últimos 30 dias, 21 dos 93 servidores que estavam jogáveis no Java nunca responderam a um só, enquanto apenas 52 responderam em pelo menos 90% das vezes. Quando escrevemos isto, em 18 de outubro de 2026, eram 94 servidores, dos quais 20 nunca responderam no Bedrock e 53 responderam de forma confiável. O dono de um crossplay quebrado quase nunca sabe, porque ninguém no Java percebe.

Uma data importa agora. O Bedrock 26.60 está previsto para 27 de outubro de 2026 e, a partir dessa versão, os clientes Bedrock deixam de se conectar por RakNet, o transporte que o Geyser ainda usa por padrão. O aviso sobre o NetherNet da GeyserMC é direto: depois dessa data, jogadores do Bedrock não conseguem entrar em servidores que não fizeram a troca. Todos os passos abaixo já incluem a troca.

Como o Geyser e o Floodgate funcionam

O Geyser fica entre o cliente Bedrock e o seu servidor Java. Ele aceita a conexão do Bedrock, abre uma conexão Java em nome do jogador e traduz tudo o que passa entre as duas: chunks, entidades, inventários, chat, sons. O seu servidor enxerga só mais um cliente Java. Como o Geyser imita o cliente Java atual, o seu servidor precisa aceitar essa versão, que hoje é o Java 26.3. Um servidor mais antigo precisa do ViaVersion para aceitar o cliente mais novo.

O Floodgate resolve o problema das contas. Um jogador do Bedrock tem uma conta Microsoft e uma gamertag do Xbox, não um perfil Java, então um servidor normal em modo online o barraria. Com o Floodgate, o Geyser atesta o jogador usando um arquivo de chave compartilhado chamado key.pem, e o Floodgate o admite com uma identidade Java gerada: a gamertag com um prefixo (um ponto por padrão, então .Steve) e um UUID construído a partir do ID de usuário do Xbox, no formato 00000000-0000-0000-xxxx-xxxxxxxxxxxx.

Um detalhe à parte: como esse UUID vem do ID de usuário do Xbox, um jogador do Bedrock que troca de gamertag mantém o inventário e as permissões. Plugins que guardam jogadores pelo nome não serão tão generosos.

O que o NetherNet muda

O NetherNet é o novo transporte do Bedrock, construído sobre WebRTC. Primeiro, o cliente envia uma pequena requisição web por TCP perguntando como se conectar, uma etapa chamada sinalização (signaling), e só então joga por UDP. A sinalização também leva o MOTD e a contagem de jogadores que a lista de servidores do Bedrock mostra. É por isso que uma porta Bedrock que antes só precisava de UDP agora precisa de TCP também, e é por isso que o seu servidor pode sumir da lista de servidores do Bedrock dos jogadores mesmo com a porta do jogo totalmente aberta. Clientes a partir da 26.40 podem usar o NetherNet, plenamente a partir da 26.50, e a partir da 26.60 são obrigados a usar. O Geyser oferece suporte desde a build 1237, mas o RakNet ainda é o padrão dele.

Plugin, proxy ou Standalone: qual instalação

Numa rede, o Geyser vai no proxy e em nenhum outro lugar. Os jogadores do Bedrock se conectam ao proxy como todo mundo, e o proxy os move entre os backends.

Instalar no Paper

Conferido na documentação da GeyserMC para um servidor Paper 26.3. O Purpur e outros forks do Paper seguem os mesmos passos.

1. Confira se o servidor aceita clientes Java 26.3. Se ele roda uma versão mais antiga, instale antes o ViaVersion.

2. Baixe o Geyser-Spigot e o Floodgate-Spigot em geysermc.org/download, coloque os dois jars em plugins, inicie o servidor uma vez para que criem suas pastas e depois pare o servidor.

3. Abra plugins/Geyser-Spigot/config.yml e configure a seção do Bedrock:

   bedrock:
     address: 0.0.0.0
     port: 19132
     transport: both
     webrtc-port: 19134

4. No mesmo arquivo, coloque auth-type: floodgate. Ele fica na seção sobre o servidor Java, que as builds atuais chamam de java: e as antigas de remote:.

5. Abra as portas como descrito abaixo, inicie o servidor e leia o console. O Geyser imprime as portas que abriu e descreve em palavras claras a maioria dos problemas do NetherNet.

Por que both e não nethernet? Só o NetherNet já basta para os clientes atuais. O both também deixa entrar jogadores que ainda estão na 26.30 a 26.34, que só falam RakNet, atende clientes 26.40 que ainda leem o MOTD por RakNet e mantém ativo o listener RakNet do Geyser, que é com quem a nossa verificação do Bedrock conversa (mais sobre isso em conferir de fora). O custo é uma porta UDP a mais: a webrtc-port precisa estar livre e ser diferente da port, e 19134 é só um exemplo. O conselho da própria GeyserMC é passar para nethernet e fechar a porta do RakNet quando a 26.60 sair e os seus jogadores tiverem atualizado.

Instalar no Velocity

1. Garanta que o Velocity e todos os backends aceitam clientes Java 26.3. O Geyser entra no proxy como um cliente Java dessa versão, e o Velocity repassa a versão, então um backend desatualizado e sem ViaVersion é um backend que os jogadores do Bedrock não alcançam.
2. Coloque o Geyser-Velocity e o Floodgate-Velocity na pasta plugins do proxy, inicie o Velocity uma vez e pare.
3. Configure plugins/Geyser-Velocity/config.yml exatamente como no exemplo do Paper, incluindo auth-type: floodgate.
4. Abra as portas do Bedrock na máquina do proxy, não nos backends.
5. Mantenha o modern forwarding como você já usa: player-info-forwarding-mode = "modern" no velocity.toml e, em cada backend, proxies.velocity.enabled: true em config/paper-global.yml, com o segredo do arquivo forwarding.secret do Velocity.

Os comandos do próprio Geyser, como /geyser version e /geyser dump, rodam no proxy, então conceda as permissões deles lá, por exemplo com o LuckPerms para Velocity.

O Floodgate nos backends

O Floodgate só precisa estar no proxy. Adicione-o aos backends quando um plugin de backend precisar da API do Floodgate, por exemplo para abrir formulários nativos do Bedrock ou para saber se um jogador está no Bedrock.

1. Instale o Floodgate-Spigot em cada backend.
2. Na configuração do Floodgate do proxy, coloque send-floodgate-data: true.
3. Copie o key.pem da pasta do Floodgate do proxy para a pasta do Floodgate de cada backend.
4. Reinicie os backends e depois o proxy.

Trate o key.pem como uma senha. Quem tiver esse arquivo consegue passar pela autenticação Java com qualquer conta Bedrock no seu servidor, então ele nunca vai para um repositório público, para um print enviado ao suporte ou para um pacote de plugins compartilhado.

Portas: 19132 em TCP e UDP, e a sua hospedagem

A porta padrão do Bedrock é a 19132. Com o NetherNet e a sinalização embutida do Geyser, a porta do Geyser precisa estar aberta para TCP e UDP, então ela não pode mais ter o mesmo número da sua porta Java, que já usa TCP. Com transport: both, a webrtc-port também precisa de UDP.

• Roteador doméstico ou VPS. Redirecione a porta do Geyser como TCP e UDP (muitos roteadores chamam isso de "Ambos") e a webrtc-port como UDP. Depois abra as mesmas portas no firewall do sistema operacional. Com o ufw, isso é sudo ufw allow 19132 (os dois protocolos) e sudo ufw allow 19134/udp.
• Docker. Publique cada protocolo de forma explícita: 19132:19132/tcp, 19132:19132/udp e 19134:19134/udp. Um simples 19132:19132 publica só o TCP.
• Oracle Cloud. Abra as portas na security list da nuvem e no firewall da própria instância. Só um dos dois não basta.
• OVH e SoYouStart. A página de redirecionamento de portas da GeyserMC avisa que as regras de Bedrock do firewall GAME ainda não lidam com o NetherNet. Use a regra Other para as portas do Geyser.
• Hospedagens de jogos com uma porta só. O truque antigo, clone-remote-port, reaproveitava o número da sua porta Java para o Bedrock em UDP. Ele não funciona com a sinalização embutida, porque a sinalização precisa de TCP nessa porta e o seu servidor Java já a ocupa. Aí o Geyser recorre por conta própria ao Warden, um serviço externo e gratuito de sinalização mantido pela Ziax, a empresa por trás do CubeCraft. Com o Warden, do seu lado só é preciso UDP, mas os jogadores entram com o endereço e a porta que o Geyser imprime no console, a menos que você registre um domínio próprio no Warden. Peça uma segunda porta à sua hospedagem ou veja se ela já configura o Geyser por flags de inicialização.
• Túneis. O ngrok só faz túnel de TCP, então não consegue carregar o jogo do Bedrock. O guia do playit.gg da GeyserMC foi escrito para o RakNet e aponta para a página de status do NetherNet do próprio playit, então confira isso antes de confiar num túnel.

Portas personalizadas dão mais problema nos nossos dados. Nos últimos 30 dias, os servidores numa porta Bedrock diferente da 19132 que nunca responderam a um ping Bedrock foram 6 de 18, contra 15 de 75 na 19132 (em 18 de outubro de 2026: 6 de 18, contra 14 de 76). A amostra é pequena, mas uma porta personalizada é mais um número para acertar em dois lugares.

A sinalização embutida do Geyser usa HTTP simples por padrão, então, na primeira entrada, o Bedrock pergunta a cada jogador se ele confia no servidor. Apontar a configuração certificate, na parte HTTPS da configuração de sinalização do Geyser, para um certificado TLS faz a pergunta sumir, e o Warden cuida do HTTPS para você.

Nomes do Floodgate e os seus plugins

Um jogador do Bedrock chamado Steve chega como .Steve, e esse ponto chega a todos os plugins que você roda.

• O prefixo. É a configuração username-prefix do Floodgate, "." por padrão. O Floodgate recomenda um prefixo sem letras nem números, para que nenhum nome do Bedrock possa colidir com um nome Java. Evite *: os comandos podem passar a exigir o nome entre aspas.
• Espaços. Gamertags podem ter espaços, nomes Java não. Com replace-spaces: true (o padrão), Cool Steve vira .Cool_Steve.
• LuckPerms. Coloque allow-invalid-usernames: true na configuração do LuckPerms para que nomes com ponto sejam aceitos, ou mire nos jogadores pelo UUID.
• Whitelist. O /whitelist add pede um perfil Java à Mojang e falha com jogadores do Bedrock. Use /fwhitelist add Steve (o prefixo é opcional) ou o UUID do Floodgate do jogador. A permissão é floodgate.command.fwhitelist.
• "Failed to verify username" no Paper. O Paper recusa nomes que considera inválidos. Instalar o Floodgate no backend ameniza o problema, e a página de problemas conhecidos do Floodgate traz a correção completa: coloque perform-username-validation como false em unsupported-settings, em config/paper-global.yml.
• Jogadores com as duas edições. A vinculação global, ativada por padrão, permite que um jogador vincule uma vez as contas Java e Bedrock e chegue com a identidade Java em todo servidor que a tenha ativada.
• Votos. O Votifier entrega um nome de usuário, e os plugins de recompensa pagam ao jogador, online ou offline, cujo nome bate. Um jogador do Bedrock precisa votar como .Steve, não como Steve, ou a recompensa não vai para ninguém. O nosso formulário de voto reconhece os prefixos mais comuns do Floodgate, confere o nome em contas Bedrock e o entrega do jeito que foi digitado. Nos últimos 30 dias, 6% de todos os votos do serverlist.net foram para nomes Bedrock, e 97% deles vinham com o ponto padrão (6% e 97% em 18 de outubro de 2026). Se você mudou o prefixo, avise na sua mensagem do /vote. O guia do NuVotifier cobre o resto do caminho do voto.

Jogadores do Bedrock não conseguem clicar em links no chat, um limite que o Geyser não consegue corrigir. Uma mensagem de voto que só diz "clique aqui" não adianta nada para eles. Escreva o endereço de votação como texto simples, curto o bastante para digitar num celular.

Confira de fora

Entrar pelo seu próprio celular na sua própria rede Wi-Fi prova muito pouco, porque o celular pode chegar ao servidor pela rede local e nunca tocar nas regras do roteador que você acabou de escrever. Teste como um desconhecido testaria.

1. Desligue o Wi-Fi de um celular, adicione o servidor no Bedrock com o endereço e a porta públicos e entre pelos dados móveis. O guia para entrar pelo Bedrock mostra o lado do jogador.

2. Passe o endereço e a porta do Bedrock pela ferramenta de status do servidor, que confere uma vez do nosso lado:

   Verifique um servidor agora

   JavaBedrockJava e Bedrock

   Endereço do servidor

   O endereço que os jogadores digitam no Multijogador. Rótulos como IP: e espaços são removidos.

   Porta opcional

   Verificar agoraDando pingVerificadoNão verificado

   A resposta aparece aqui como a linha que você veria no Multijogador, com jogadores, versão e ping.

3. Adicione o seu servidor ou edite a página dele, ative "Jogadores Bedrock também podem entrar" e informe o endereço e a porta do Bedrock. A partir daí, o nosso pinger confere a porta do Bedrock a cada minuto, e o selo Bedrock do seu servidor e a sua posição na lista Bedrock vêm dessas respostas, não da chave que você ligou.

4. Repita depois de cada atualização do Geyser e de cada versão do Bedrock. Uma build do Geyser velha demais para uma versão nova do Bedrock é um motivo comum de jogadores do Bedrock ficarem de repente sem acesso no dia de uma atualização.

Uma observação sobre como conferimos, porque isso afeta o que você vê. O nosso ping Bedrock é o ping RakNet que os clientes Bedrock usavam antes do NetherNet. O Geyser em modo both responde a ele, o Geyser em modo nethernet não. Enquanto a nossa verificação não falar NetherNet também, um servidor só em nethernet aparece aqui como sem resposta no Bedrock, mesmo quando jogadores do Bedrock conseguem entrar, então both é, por enquanto, a configuração que mantém correto o selo Bedrock do seu servidor. Como medimos está na página de metodologia.

Veja como os servidores se dividem por plataforma agora:

• Só JavaNenhum endereço Bedrock na página367% dos jogadores
• Bedrock respondeInforma um endereço Bedrock que respondeu ao nosso ping Bedrock7290% dos jogadores
• Bedrock em silêncioInforma um endereço Bedrock que nunca respondeu213% dos jogadores

Dos 129 servidores que estavam jogáveis, 72 também responderam no Bedrock e 21 informam um endereço Bedrock que nunca respondeu.

Medido em 19 out. 2026, 22:55 UTCComo medimos

Do que os jogadores do Bedrock vão sentir falta

O Geyser não consegue mudar o cliente Bedrock. A GeyserMC mantém uma página de limitações atuais, e estes são os itens dela que mais costumam importar num servidor típico:

• Links clicáveis no chat. Não funcionam no Bedrock, o que atinge links de votação, links da loja e convites do Discord.
• Clique esquerdo e direito em menus de inventário. O Bedrock não distingue os dois, então menus de baú que fazem coisas diferentes em cada clique quebram. Os formulários do Floodgate são a alternativa nativa do Bedrock.
• Encantamentos personalizados não aparecem, e níveis fora do padrão do vanilla, como "Toque suave 2", não podem ser exibidos.
• Argumentos de comandos e preenchimento automático com Tab só funcionam em comandos registrados do jeito moderno (Brigadier).
• O efeito de brilho (glowing) e estandartes com mais de seis camadas.

Dois limites relacionados não estão nessa página. Os resource packs do Java não carregam no Bedrock, então o Geyser precisa enviar um pacote do Bedrock, e itens personalizados precisam de um mapeamento do Geyser para que os jogadores do Bedrock os vejam direito. O GeyserIntegratedPack que acompanha o Geyser corrige algumas lacunas por conta própria, como as animações da mão secundária e as poses de suporte de armadura.

O combate também parece diferente. O Bedrock não tem um tempo de recarga de ataque próprio, então o Geyser desenha um indicador substituto, por padrão na mira (a opção cooldown-type na seção gameplay, chamada show-cooldown nas configurações antigas), e jogadores de toque miram de um jeito diferente de quem usa mouse. Se o seu servidor é construído em torno do timing do PvP do Java, diga isso na página do servidor.

Divulgue isso direito na página do seu servidor

Uma configuração de Bedrock que funciona é desperdício se os jogadores não conseguem ver nem digitar.

• Endereço e porta em campos próprios. O Bedrock não lê registros SRV, então os jogadores digitam a porta à mão. Coloque a porta no campo da porta, não depois de dois-pontos no endereço. Se o Geyser recorreu ao Warden, use o endereço que o Geyser imprime. Se o Geyser antes dividia a sua porta Java, a sua porta Bedrock mudou, então atualize a página do servidor e diga aos jogadores para editarem o servidor salvo.
• Diga o que os jogadores do Bedrock recebem. Uma ou duas linhas na descrição: o prefixo que eles vão ver, quais menus ou minigames não funcionam no Bedrock e como votar com o nome deles. O guia de descrição do servidor mostra onde isso se encaixa.
• Informe a faixa de edições. "Bedrock 26.50 e mais novo" diz mais a um jogador do que "crossplay".
• Jogadores de console precisam de mais ajuda. Celulares e Windows podem adicionar qualquer servidor, mas jogadores de Xbox, PlayStation e Switch precisam de soluções de terceiros, então um endereço Bedrock sozinho não chega até eles.

A visão do jogador sobre tudo isso está em Java e Bedrock podem jogar juntos.

Tabela de problemas

Quando a tabela acabar, o /geyser dump gera um relatório de depuração, que é o que o suporte da GeyserMC pede. Depois que o Bedrock funcionar, o próximo trabalho é garantir que os votos das duas edições cheguem, o que o guia de configuração do NuVotifier mostra passo a passo.