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.
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ón | Instala Geyser en | Instala Floodgate en |
|---|---|---|
| Un servidor Paper o Purpur | Ese servidor (Geyser-Spigot) | El mismo servidor (Floodgate-Spigot) |
| Una network con Velocity | Solo en el proxy (Geyser-Velocity) | En el proxy, y además en cada backend si los plugins de allí necesitan Floodgate |
| Una network con BungeeCord | Solo en el proxy (Geyser-BungeeCord) | Igual que en Velocity |
| Un servidor Fabric o NeoForge que solo usa mods del lado del servidor | En 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 plugins | Geyser Standalone en otra máquina, con Java 21 o superior | En 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.
Comprueba que el servidor acepta clientes de Java 26.3. Si usa una versión más antigua, instala antes ViaVersion.
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.Abre
plugins/Geyser-Spigot/config.ymly configura la sección de Bedrock:bedrock: address: 0.0.0.0 port: 19132 transport: both webrtc-port: 19134En el mismo archivo, pon
auth-type: floodgate. Está en la sección del servidor Java, que las builds actuales llamanjava:y las antiguasremote:.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
- 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.
- Pon Geyser-Velocity y Floodgate-Velocity en la carpeta
pluginsdel proxy, arranca Velocity una vez y páralo. - Configura
plugins/Geyser-Velocity/config.ymlexactamente como en el ejemplo de Paper, incluidoauth-type: floodgate. - Abre los puertos de Bedrock en la máquina del proxy, no en los backends.
- Mantén el modern forwarding tal como ya lo tienes:
player-info-forwarding-mode = "modern"envelocity.tomly, en cada backend,proxies.velocity.enabled: trueenconfig/paper-global.ymlcon el secreto del archivoforwarding.secretde 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.
- Instala Floodgate-Spigot en cada backend.
- En la configuración de Floodgate del proxy, pon
send-floodgate-data: true. - Copia
key.pemde la carpeta de Floodgate del proxy a la carpeta de Floodgate de cada backend. - 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-portcomo UDP. Después abre los mismos puertos en el cortafuegos del sistema operativo. Con ufw essudo ufw allow 19132(los dos protocolos) ysudo ufw allow 19134/udp. - Docker. Publica cada protocolo de forma explícita:
19132:19132/tcp,19132:19132/udpy19134:19134/udp. Un simple19132:19132publica 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
Otherpara 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-prefixde 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 Stevepasa a ser.Cool_Steve. - LuckPerms. Pon
allow-invalid-usernames: trueen la configuración de LuckPerms para que se acepten los nombres con punto, o apunta a los jugadores por UUID. - Whitelist.
/whitelist addpide 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 esfloodgate.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-validationenfalsedentro deunsupported-settingsenconfig/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 comoSteve, 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.
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.
Pasa la dirección y el puerto de Bedrock por la herramienta de estado del servidor, que lo comprueba una vez desde nuestro lado:
La respuesta aparece aquí como la fila que verías en Multijugador, con jugadores, versión y ping.
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.
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:
- 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 ves | Causa probable | Solució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 1237 | Actualiza 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 ti | Redirige 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 reutilizado | Consigue 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 port | Elige otro puerto UDP libre para webrtc-port |
| Consola: "... is a loopback address" | address está en 127.0.0.1 | Pon address: 0.0.0.0 |
| A los jugadores de Bedrock se les pide iniciar sesión con una cuenta de Java | auth-type no es floodgate, o falta Floodgate en el servidor al que se conecta Geyser | Pon auth-type: floodgate e instala Floodgate |
| "Please connect through the official Geyser" | key.pem distinto entre instalaciones, o Geyser y Floodgate desactualizados | Copia el key.pem del proxy a cada backend y actualiza los dos |
| "Failed to verify username" en un backend Paper | La validación de nombres de Paper rechaza el punto | Instala 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 expulsado | Se añadió con /whitelist | Usa /fwhitelist add con el gamertag o el UUID |
| Llegan votos de Bedrock pero no hay recompensas | El jugador votó sin el prefijo | Di a los jugadores de Bedrock que voten como .Name |
| Todos los de Bedrock se quedan fuera después de una actualización de Bedrock | Build de Geyser demasiado antigua | Actualiza Geyser y reinicia |
| Pregunta de confianza en la primera entrada | Señalización por HTTP sin cifrar | Añade un certificado para la señalización, o usa Warden |
| Funciona en casa y falla para todos los demás | El router o el cortafuegos de la nube están abiertos solo a medias | Revisa 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.
Para seguir leyendo
Sigue leyendo.
¿Pueden jugar juntos Java y Bedrock en Minecraft?
Sí, en servidores Java con Geyser. Cómo funciona el crossplay, cómo reconocerlo en una lista, qué notan los jugadores de Bedrock y cuánto se usa, medido.
Cómo configurar NuVotifier en tu servidor de Minecraft y probarlo
Instala NuVotifier en Paper o en una network con Velocity, abre el puerto, pruébalo y entiende cada error que da. Probado en Paper 26.3 y Velocity 4.2.