Iniciar sesión Añade tu servidor

GuíaPara propietarios de servidores

Cómo configurar Geyser y Floodgate para jugadores de Bedrock

Configura Geyser y Floodgate en Paper o Velocity, activa NetherNet antes de Bedrock 26.60, abre el 19132 por TCP y UDP y pruébalo desde fuera de tu red.

Equipo editorial de ServerList Publicado el 16 min de lectura
Geyser + FloodgateTCP 25565UDP 19132Los nombres de Bedrock llevan prefijo

Geyser permite que los jugadores de Bedrock en móviles, tablets, consolas y Windows entren a tu servidor Java traduciendo entre las dos ediciones, y Floodgate los deja entrar sin una cuenta de Java. Instala los dos en tu servidor Paper o en tu proxy Velocity, pon el transport de Geyser en both, abre el puerto de Bedrock para TCP y UDP y comprueba después, desde fuera de tu red, que un jugador de Bedrock puede entrar de verdad.

Ese último paso es el que casi todos los dueños se saltan. Nuestro pinger envía cada minuto un ping de Bedrock a todas las fichas crossplay que publican una dirección de Bedrock, y en los últimos 30 días 21 de las 93 fichas que eran jugables en Java no respondieron ni a uno, mientras que solo 52 respondieron al menos el 90 % de las veces. Cuando escribimos esto, el 18 de octubre de 2026, eran 94 fichas, de las cuales 20 nunca respondían en Bedrock y 53 respondían con fiabilidad. El dueño de un crossplay roto casi nunca lo sabe, porque nadie en Java lo nota.

Hay una fecha que importa ahora mismo. Bedrock 26.60 está prevista para el 27 de octubre de 2026, y desde esa versión los clientes de Bedrock dejan de conectarse por RakNet, el transporte que Geyser sigue usando por defecto. El aviso sobre NetherNet de GeyserMC es tajante: pasada esa fecha, los jugadores de Bedrock no podrán entrar en los servidores que no hayan hecho el cambio. Todos los pasos de abajo ya incluyen el cambio.

Cómo funcionan Geyser y Floodgate

Geyser se coloca entre el cliente de Bedrock y tu servidor Java. Acepta la conexión de Bedrock, abre una conexión de Java en nombre del jugador y traduce todo lo que pasa entre las dos: chunks, entidades, inventarios, chat, sonidos. Tu servidor ve un cliente de Java más. Como Geyser imita al cliente de Java actual, tu servidor tiene que aceptar esa versión, que a día de hoy es Java 26.3. Un servidor más antiguo necesita ViaVersion para aceptar el cliente nuevo.

Floodgate resuelve el problema de las cuentas. Un jugador de Bedrock tiene una cuenta Microsoft y un gamertag de Xbox, no un perfil de Java, así que un servidor normal en modo online lo rechazaría. Con Floodgate, Geyser avala al jugador con un archivo de clave compartido llamado key.pem, y Floodgate lo admite con una identidad de Java generada: el gamertag con un prefijo (un punto por defecto, así que .Steve) y un UUID construido a partir de su ID de usuario de Xbox, con el formato 00000000-0000-0000-xxxx-xxxxxxxxxxxx.

Un apunte: como ese UUID sale del ID de usuario de Xbox, un jugador de Bedrock que cambia de gamertag conserva su inventario y sus permisos. Los plugins que guardan a los jugadores por nombre no serán tan indulgentes.

Qué cambia con NetherNet

NetherNet es el nuevo transporte de Bedrock, construido sobre WebRTC. Primero, el cliente envía por TCP una pequeña petición web para preguntar cómo conectarse, un paso llamado señalización (signaling), y solo después juega por UDP. La señalización también lleva el MOTD y el número de jugadores que muestra la lista de servidores de Bedrock. Por eso un puerto de Bedrock que antes solo necesitaba UDP ahora necesita también TCP, y por eso tu servidor puede desaparecer de la lista de servidores de Bedrock de los jugadores aunque el puerto de juego esté abierto de par en par. Los clientes desde la 26.40 pueden usar NetherNet, del todo desde la 26.50, y desde la 26.60 están obligados a usarlo. Geyser lo admite desde la build 1237, pero RakNet sigue siendo su valor por defecto.

Plugin, proxy o Standalone: qué instalación elegir

Tu configuraciónInstala Geyser enInstala Floodgate en
Un servidor Paper o PurpurEse servidor (Geyser-Spigot)El mismo servidor (Floodgate-Spigot)
Una network con VelocitySolo en el proxy (Geyser-Velocity)En el proxy, y además en cada backend si los plugins de allí necesitan Floodgate
Una network con BungeeCordSolo en el proxy (Geyser-BungeeCord)Igual que en Velocity
Un servidor Fabric o NeoForge que solo usa mods del lado del servidorEn el servidor (Geyser-Fabric o Geyser-NeoForge)En el servidor (el mod de Floodgate, y Fabric necesita además Fabric API)
Un servidor en el que no puedes añadir pluginsGeyser Standalone en otra máquina, con Java 21 o superiorEn el servidor Java si puedes, y si no, los jugadores necesitan cuentas de Java

En una network, Geyser va en el proxy y en ningún otro sitio. Los jugadores de Bedrock se conectan al proxy como todos los demás, y el proxy los mueve entre backends.

Instalar en Paper

Comprobado con la documentación de GeyserMC para un servidor Paper 26.3. Purpur y otros forks de Paper siguen los mismos pasos.

  1. Comprueba que el servidor acepta clientes de Java 26.3. Si usa una versión más antigua, instala antes ViaVersion.

  2. Descarga Geyser-Spigot y Floodgate-Spigot desde geysermc.org/download, pon los dos jars en plugins, arranca el servidor una vez para que creen sus carpetas y después páralo.

  3. Abre plugins/Geyser-Spigot/config.yml y configura la sección de Bedrock:

    bedrock:
      address: 0.0.0.0
      port: 19132
      transport: both
      webrtc-port: 19134
  4. En el mismo archivo, pon auth-type: floodgate. Está en la sección del servidor Java, que las builds actuales llaman java: y las antiguas remote:.

  5. Abre los puertos como se explica más abajo, arranca el servidor y lee la consola. Geyser imprime los puertos que ha abierto y explica con claridad la mayoría de los problemas de NetherNet.

¿Por qué both y no nethernet? Con NetherNet a secas ya basta para los clientes actuales. both además deja entrar a los jugadores que siguen entre la 26.30 y la 26.34, que solo hablan RakNet, atiende a los clientes 26.40 que todavía leen el MOTD por RakNet y mantiene en marcha el listener RakNet de Geyser, con el que habla nuestra comprobación de Bedrock (más sobre esto en la sección para comprobarlo desde fuera). El coste es un puerto UDP más: webrtc-port tiene que estar libre y ser distinto de port, y 19134 es solo un ejemplo. El consejo del propio GeyserMC es pasar a nethernet y cerrar el puerto de RakNet cuando salga la 26.60 y tus jugadores ya se hayan actualizado.

Instalar en Velocity

  1. Asegúrate de que Velocity y todos los backends aceptan clientes de Java 26.3. Geyser entra al proxy como un cliente de Java de esa versión, y Velocity transmite esa versión a los backends, así que un backend desactualizado y sin ViaVersion es un backend al que los jugadores de Bedrock no pueden llegar.
  2. Pon Geyser-Velocity y Floodgate-Velocity en la carpeta plugins del proxy, arranca Velocity una vez y páralo.
  3. Configura plugins/Geyser-Velocity/config.yml exactamente como en el ejemplo de Paper, incluido auth-type: floodgate.
  4. Abre los puertos de Bedrock en la máquina del proxy, no en los backends.
  5. Mantén el modern forwarding tal como ya lo tienes: player-info-forwarding-mode = "modern" en velocity.toml y, en cada backend, proxies.velocity.enabled: true en config/paper-global.yml con el secreto del archivo forwarding.secret de Velocity.

Los comandos propios de Geyser, como /geyser version y /geyser dump, se ejecutan en el proxy, así que concede sus permisos allí, por ejemplo con LuckPerms para Velocity.

Floodgate en los backends

Floodgate solo tiene que estar en el proxy. Añádelo a los backends cuando un plugin de un backend necesite la API de Floodgate, por ejemplo para abrir formularios nativos de Bedrock o para comprobar si un jugador está en Bedrock.

  1. Instala Floodgate-Spigot en cada backend.
  2. En la configuración de Floodgate del proxy, pon send-floodgate-data: true.
  3. Copia key.pem de la carpeta de Floodgate del proxy a la carpeta de Floodgate de cada backend.
  4. Reinicia los backends y después el proxy.

Trata key.pem como una contraseña. Quien lo tenga puede saltarse la autenticación de Java para cualquier cuenta de Bedrock en tu servidor, así que nunca debe acabar en un repositorio público, en una captura de pantalla para soporte ni en un pack de plugins compartido.

Puertos: el 19132 por TCP y UDP, y tu hosting

El puerto por defecto de Bedrock es el 19132. Con NetherNet y la señalización integrada de Geyser, el puerto de Geyser tiene que estar abierto para TCP y UDP a la vez, así que ya no puede compartir número con tu puerto de Java, que ya usa TCP. Con transport: both, el webrtc-port también necesita UDP.

  • Router doméstico o VPS. Redirige el puerto de Geyser como TCP y UDP (muchos routers lo llaman "Ambos") y el webrtc-port como UDP. Después abre los mismos puertos en el cortafuegos del sistema operativo. Con ufw es sudo ufw allow 19132 (los dos protocolos) y sudo ufw allow 19134/udp.
  • Docker. Publica cada protocolo de forma explícita: 19132:19132/tcp, 19132:19132/udp y 19134:19134/udp. Un simple 19132:19132 publica solo TCP.
  • Oracle Cloud. Abre los puertos en la security list de la nube y en el cortafuegos de la propia instancia. Con uno solo no basta.
  • OVH y SoYouStart. La página de redirección de puertos de GeyserMC avisa de que las reglas de Bedrock del cortafuegos GAME todavía no gestionan NetherNet. Usa la regla Other para los puertos de Geyser.
  • Hostings de juegos con un solo puerto. El truco de siempre, clone-remote-port, reutilizaba el número de tu puerto de Java para Bedrock por UDP. No funciona con la señalización integrada, porque la señalización necesita TCP en ese puerto y tu servidor Java ya lo ocupa. Entonces Geyser recurre por su cuenta a Warden, un servicio de señalización externo y gratuito de Ziax, la empresa detrás de CubeCraft. Con Warden solo necesitas UDP por tu parte, pero los jugadores entran con la dirección y el puerto que Geyser imprime en la consola, salvo que registres un dominio propio en Warden. Pide a tu hosting un segundo puerto o comprueba si ya configura Geyser mediante flags de arranque.
  • Túneles. ngrok solo tuneliza TCP, así que no puede llevar el juego de Bedrock. La guía de playit.gg de GeyserMC se escribió para RakNet y remite a la página de estado de NetherNet del propio playit, así que míralo antes de fiarte de un túnel.

Los puertos personalizados fallan más a menudo en nuestros datos. En los últimos 30 días, las fichas con un puerto de Bedrock distinto del 19132 que nunca respondieron a un ping de Bedrock fueron 6 de 18, frente a 15 de 75 en el 19132 (el 18 de octubre de 2026: 6 de 18, frente a 14 de 76). La muestra es pequeña, pero un puerto personalizado es un número más que acertar en dos sitios.

La señalización integrada de Geyser usa HTTP sin cifrar por defecto, así que en la primera entrada Bedrock pregunta a cada jugador si confía en el servidor. Si apuntas el ajuste certificate de la parte HTTPS de la configuración de señalización de Geyser a un certificado TLS, la pregunta desaparece, y Warden se encarga del HTTPS por ti.

Nombres de Floodgate y tus plugins

Un jugador de Bedrock llamado Steve llega como .Steve, y ese punto llega a todos los plugins que ejecutas.

  • El prefijo. Es el ajuste username-prefix de la configuración de Floodgate, "." por defecto. Floodgate recomienda un prefijo sin letras ni números, para que ningún nombre de Bedrock pueda chocar con uno de Java. Evita *: entonces puede que los comandos pidan el nombre entre comillas.
  • Espacios. Los gamertags pueden llevar espacios y los nombres de Java no. Con replace-spaces: true (el valor por defecto), Cool Steve pasa a ser .Cool_Steve.
  • LuckPerms. Pon allow-invalid-usernames: true en la configuración de LuckPerms para que se acepten los nombres con punto, o apunta a los jugadores por UUID.
  • Whitelist. /whitelist add pide a Mojang un perfil de Java y falla con los jugadores de Bedrock. Usa en su lugar /fwhitelist add Steve (el prefijo es opcional) o el UUID de Floodgate del jugador. El permiso es floodgate.command.fwhitelist.
  • "Failed to verify username" en Paper. Paper rechaza los nombres que considera inválidos. Instalar Floodgate en el backend lo mitiga, y la página de problemas conocidos de Floodgate da la solución completa: pon perform-username-validation en false dentro de unsupported-settings en config/paper-global.yml.
  • Jugadores con las dos ediciones. La vinculación global, activada por defecto, permite que un jugador vincule una sola vez sus cuentas de Java y Bedrock y llegue con su identidad de Java a todos los servidores que la tengan activada.
  • Votos. Votifier entrega un nombre de usuario, y los plugins de recompensas pagan al jugador, conectado o no, cuyo nombre coincide. Un jugador de Bedrock tiene que votar como .Steve, no como Steve, o la recompensa no llega a ninguna parte. Nuestro formulario de voto reconoce los prefijos habituales de Floodgate, comprueba el nombre con cuentas de Bedrock y lo entrega tal como se escribió. En los últimos 30 días, el 6 % de todos los votos de serverlist.net fueron para nombres de Bedrock, y el 97 % de ellos llevaba el punto por defecto (6 % y 97 % el 18 de octubre de 2026). Si cambiaste el prefijo, dilo en tu mensaje de /vote. La guía de NuVotifier cubre el resto del recorrido del voto.

Los jugadores de Bedrock no pueden hacer clic en los enlaces del chat, un límite que Geyser no puede arreglar. Un mensaje de voto que solo diga "haz clic aquí" no les sirve de nada. Escribe la dirección de voto como texto normal, lo bastante corta para teclearla en un móvil.

Compruébalo desde fuera

Entrar desde tu propio móvil con tu propia Wi-Fi demuestra muy poco, porque el móvil puede llegar al servidor por tu red local sin tocar nunca las reglas del router que acabas de escribir. Comprueba como lo haría un desconocido.

  1. Apaga la Wi-Fi de un móvil, añade el servidor en Bedrock con la dirección y el puerto públicos y entra con datos móviles. La guía para entrar desde Bedrock muestra el lado del jugador.

  2. Pasa la dirección y el puerto de Bedrock por la herramienta de estado del servidor, que lo comprueba una vez desde nuestro lado:

    Comprueba un servidor ahora

    La dirección que los jugadores ponen en Multijugador. Quitamos etiquetas como IP: y los espacios.

    La respuesta aparece aquí como la fila que verías en Multijugador, con jugadores, versión y ping.

  3. Añade tu servidor o edita tu ficha, activa "Los jugadores de Bedrock también pueden entrar" y escribe la dirección y el puerto de Bedrock. Desde ese momento nuestro pinger comprueba el puerto de Bedrock cada minuto, y la marca de Bedrock de tu ficha y tu puesto en la lista de servidores Bedrock salen de esas respuestas, no del interruptor.

  4. Repite la comprobación después de cada actualización de Geyser y de cada versión de Bedrock. Una build de Geyser demasiado antigua para una versión nueva de Bedrock es una causa habitual de que los jugadores de Bedrock se queden fuera de golpe el día de una actualización.

Una nota sobre cómo comprobamos, porque afecta a lo que ves. Nuestro ping de Bedrock es el ping de RakNet que usaban los clientes de Bedrock antes de NetherNet. Geyser en modo both lo responde, Geyser en modo nethernet no. Mientras nuestra comprobación no hable también NetherNet, un servidor solo en nethernet aparece aquí como que no responde en Bedrock aunque los jugadores de Bedrock puedan entrar, así que both es, por ahora, el ajuste que mantiene exacta la marca de Bedrock de tu ficha. Cómo medimos está en la página de metodología.

Así se reparten ahora las fichas por plataforma:

Java, Bedrock o ambosÚltimos 30 días
  • Solo JavaLa ficha no tiene dirección de Bedrock367 % de los jugadores
  • Bedrock respondePublica una dirección de Bedrock que respondió a nuestro ping de Bedrock7290 % de los jugadores
  • Bedrock no respondePublica una dirección de Bedrock que nunca respondió213 % de los jugadores

De 129 servidores que fueron jugables, 72 también respondieron en Bedrock y 21 publican una dirección de Bedrock que nunca respondió.

Medido el 19 oct 2026, 23:05 UTCCómo medimos

Lo que echarán en falta los jugadores de Bedrock

Geyser no puede cambiar el cliente de Bedrock. GeyserMC mantiene una página de limitaciones actuales, y estos son los puntos de esa lista que con más frecuencia importan en un servidor típico:

  • Enlaces clicables en el chat. No funcionan en Bedrock, y eso afecta a los enlaces de voto, a los de la tienda y a las invitaciones de Discord.
  • Clic izquierdo y clic derecho en los menús de inventario. Bedrock no los distingue, así que los menús de cofre que hacen cosas distintas con cada clic se rompen. Los formularios de Floodgate son la alternativa nativa de Bedrock.
  • Los encantamientos personalizados no se muestran, y los niveles que no existen en vanilla, como "Toque de seda 2", no se pueden mostrar.
  • Los argumentos de los comandos y el autocompletado con Tab solo funcionan con comandos registrados a la manera moderna (Brigadier).
  • El efecto Luminiscencia y los estandartes con más de seis capas.

Dos límites relacionados no aparecen en esa página. Los paquetes de recursos de Java no se cargan en Bedrock, así que Geyser tiene que enviar un paquete de Bedrock, y los objetos personalizados necesitan un mapping de Geyser para que los jugadores de Bedrock los vean bien. El GeyserIntegratedPack que incluye Geyser corrige algunas carencias por su cuenta, como las animaciones de la mano secundaria y las poses de los soportes para armadura.

El combate también es distinto. Bedrock no tiene un cooldown de ataque propio, así que Geyser dibuja un indicador sustituto, por defecto en la mira (la opción cooldown-type de la sección gameplay, llamada show-cooldown en las configuraciones antiguas), y quienes juegan con pantalla táctil apuntan de forma distinta a quienes usan ratón. Si tu servidor está construido en torno al timing del PvP de Java, dilo en tu ficha.

Muéstralo bien en tu ficha

Una configuración de Bedrock que funciona se desperdicia si los jugadores no pueden verla ni escribirla.

  • Dirección y puerto en sus propios campos. Bedrock no lee registros SRV, así que los jugadores escriben el puerto a mano. Pon el puerto en el campo del puerto, no detrás de dos puntos en la dirección. Si Geyser recurrió a Warden, usa la dirección que Geyser imprime. Si Geyser compartía antes tu puerto de Java, tu puerto de Bedrock ha cambiado: actualiza la ficha y dile a los jugadores que editen su servidor guardado.
  • Cuenta qué obtienen los jugadores de Bedrock. Una o dos líneas en tu descripción: el prefijo que verán, qué menús o minijuegos no funcionan en Bedrock y cómo votar con su nombre. La guía para escribir la descripción de un servidor muestra dónde encaja.
  • Indica qué versiones de Bedrock admites. "Bedrock 26.50 y posteriores" dice más a un jugador que "crossplay".
  • Los jugadores de consola necesitan más ayuda. Los móviles y Windows pueden añadir cualquier servidor, pero los jugadores de Xbox, PlayStation y Switch necesitan soluciones de terceros, así que una dirección de Bedrock por sí sola no llega hasta ellos.

El punto de vista del jugador sobre todo esto está en si pueden jugar juntos los jugadores de Java y de Bedrock.

Tabla de problemas

Lo que vesCausa probableSolución
Los jugadores de Bedrock no pueden entrar después de Bedrock 26.60, los de Java síGeyser sigue solo en RakNet, o es una build anterior a la 1237Actualiza Geyser, pon transport: both (o nethernet) y abre TCP en el puerto de Geyser
El servidor no aparece en la lista de Bedrock, o no tiene MOTD, pero el puerto está "abierto"No se ha redirigido TCP y la señalización no puede llegar hasta tiRedirige el puerto de Geyser como TCP y UDP
Consola: "Built-in signaling cannot use port ... because the Java server already uses it"clone-remote-port o el puerto de Java reutilizadoConsigue un puerto aparte, o quédate con la señalización externa (Geyser cambia a ella por su cuenta)
Consola: "RakNet and NetherNet each need their own UDP port"webrtc-port es igual que portElige otro puerto UDP libre para webrtc-port
Consola: "... is a loopback address"address está en 127.0.0.1Pon address: 0.0.0.0
A los jugadores de Bedrock se les pide iniciar sesión con una cuenta de Javaauth-type no es floodgate, o falta Floodgate en el servidor al que se conecta GeyserPon auth-type: floodgate e instala Floodgate
"Please connect through the official Geyser"key.pem distinto entre instalaciones, o Geyser y Floodgate desactualizadosCopia el key.pem del proxy a cada backend y actualiza los dos
"Failed to verify username" en un backend PaperLa validación de nombres de Paper rechaza el puntoInstala Floodgate en el backend, o sigue la solución de la página de problemas conocidos de Floodgate
Un jugador de Bedrock en la whitelist sigue siendo expulsadoSe añadió con /whitelistUsa /fwhitelist add con el gamertag o el UUID
Llegan votos de Bedrock pero no hay recompensasEl jugador votó sin el prefijoDi a los jugadores de Bedrock que voten como .Name
Todos los de Bedrock se quedan fuera después de una actualización de BedrockBuild de Geyser demasiado antiguaActualiza Geyser y reinicia
Pregunta de confianza en la primera entradaSeñalización por HTTP sin cifrarAñade un certificado para la señalización, o usa Warden
Funciona en casa y falla para todos los demásEl router o el cortafuegos de la nube están abiertos solo a mediasRevisa los dos cortafuegos y los dos protocolos, y prueba con datos móviles

Cuando la tabla no basta, /geyser dump genera un informe de depuración, que es lo que pide el soporte de GeyserMC. Cuando Bedrock ya funcione, el siguiente trabajo es asegurarte de que llegan los votos de las dos ediciones, algo que explica paso a paso la guía de instalación de NuVotifier.