Cómo instalar GeyserMC y Floodgate para jugar Minecraft Java y Bedrock juntos

Respuesta directa: para aceptar jugadores de Minecraft Bedrock en un servidor Java Paper o Purpur, descarga Geyser-Spigot y Floodgate-Spigot desde la fuente oficial, coloca ambos JAR en plugins, inicia una vez para generar sus archivos, detén por completo el servidor, configura el puerto Bedrock en UDP y cambia auth-type a floodgate. Si el backend Java es anterior a 26.2, también necesita ViaVersion. La instalación no está terminada hasta probar el puerto desde otra red y confirmar que Java sigue entrando.

Esta guía desarrolla ese proceso para Paper/Purpur y explica qué cambia en Fabric, NeoForge, Velocity, BungeeCord y Geyser Standalone. Los pasos son instrucciones reproducibles; no implican que Teramont haya ejecutado comandos en tu servidor.

Qué hacen GeyserMC y Floodgate, y qué no hacen

Geyser recibe tráfico Bedrock, normalmente por UDP 19132, traduce sus paquetes al protocolo Java y entrega la sesión al servidor Java. Es una pasarela de protocolo: no convierte el mundo, no crea una copia Bedrock del mapa y no ejecuta dos servidores. Los jugadores de ambas ediciones comparten el mismo backend, mundo y lógica del servidor.

Floodgate resuelve otra capa. Autentica identidades Bedrock y permite que esos jugadores entren sin comprar Java Edition. No sustituye a Geyser y tampoco significa dejar el servidor sin autenticación. En una instalación Paper sencilla, Geyser traduce y Floodgate aporta la identidad Bedrock; el servidor Java puede conservar su configuración normal de autenticación para jugadores Java.

• Entrada Bedrock: dirección pública o dominio A, más el puerto UDP asignado.
• Traducción: Geyser presenta al backend una sesión compatible con Java.
• Identidad: Floodgate distingue y autentica al jugador Bedrock.
• Backend: Paper, Purpur u otra plataforma compatible mantiene el mundo. Geyser no toca el formato del mundo.

Compatibilidad al 30 de julio de 2026

Comprueba la tabla oficial de versiones compatibles antes de revisar firewall o DNS: un puerto perfecto no corrige una combinación de protocolos que todavía no está soportada.

Matriz de compatibilidad en la fecha de corte:

Mojang registró Bedrock 26.34 el 23 de julio en el changelog oficial del hotfix; consulta también qué corrige Bedrock 26.34. Al corte del 30 de julio, la tabla oficial de Geyser todavía termina en 26.33. Eso significa compatibilidad no confirmada, no una declaración de incompatibilidad. Actualiza Geyser desde su sitio oficial y vuelve a comprobar la tabla antes de diagnosticar la red. No bajes de versión con clientes o descargas no oficiales.

Elige la topología antes de copiar JAR

La variante correcta depende del lugar donde termina la conexión pública. Instalar Geyser en todos los nodos de una red proxy crea puertos duplicados y hace más difícil saber qué proceso recibió el paquete.

Tabla de decisión por plataforma:

En Velocity o BungeeCord, todos los destinos deben aceptar el cliente Java 26.2 que emula Geyser. Instala Geyser únicamente en el proxy. Según la topología oficial de Floodgate, solo añade Floodgate a un backend si necesitas su API o el soporte de skins allí; en ese caso activa el envío de datos, usa el reenvío seguro del proxy y distribuye la misma key.pem mediante un canal privado.

Standalone no es un plugin. Corre junto al servidor y necesita su propia supervisión. Para usar Floodgate con Standalone, Floodgate debe estar instalado en el servidor Java de destino y la clave se copia al directorio de Geyser Standalone porque esa topología sí lo requiere.

Prerrequisitos y plan de cambio

• Copia recuperable: crea un snapshot o backup completo y conserva por separado plugins, config y la configuración del firewall. Comprueba que puedes identificar el backup correcto.
• Versión conocida: anota la versión de Paper/Purpur, el protocolo del backend y las versiones de Geyser, Floodgate y ViaVersion si ya existen.
• Java correcto: Geyser requiere Java 21 o posterior. El servidor también debe soportar ese runtime.
• Acceso de operación: necesitas detener e iniciar por completo, leer el log desde el arranque, subir archivos y editar YAML. Un comando /reload no sustituye el reinicio.
• UDP asignado: reserva 19132/UDP u otro puerto permitido. Voice Chat, Query u otro servicio UDP no puede escuchar en el mismo puerto.
• Ruta pública completa: en VPS considera firewall del sistema, firewall del proveedor, NAT y DNS; en Pterodactyl, la allocation; en Docker, el mapeo UDP.
• Capacidad observable: no existe una cifra universal de RAM o CPU para Geyser. Deja margen, registra una línea base y mide bajo la carga real de tu servidor.

Haz el backup con el servidor detenido

Detén el servidor desde systemd o el panel y adapta las rutas. El ejemplo de systemd verifica que la unidad ya está detenida, crea un backup privado de las áreas modificadas y conserva el estado previo de UFW; en Pterodactyl, confirma el estado detenido desde el panel antes de copiar. El snapshot completo del proveedor sigue siendo la protección preferida para el mundo.

Guarda además los JAR anteriores si esto es una actualización. El rollback depende de restaurar el binario y la configuración como pareja; mezclar un JAR antiguo con un config.yml recién migrado puede añadir un segundo problema.

Cómo instalar GeyserMC y Floodgate en Paper o Purpur

1. Confirma runtime y backend

Con el servidor detenido, comprueba el Java que usa realmente el servicio. Si el panel permite seleccionar runtime, valida también el valor de su startup, no solo el Java de tu sesión SSH.

Debe ser Java 21 o posterior. Comprueba que Paper/Purpur se basa en una versión compatible con Geyser-Spigot y determina si el backend acepta Java 26.2. Si es anterior, planifica ViaVersion antes de abrir el acceso público.

2. Descarga solo los artefactos oficiales

Desde la página oficial de descargas, elige Geyser para Spigot y Floodgate para Spigot. No uses repositorios de reempaquetado ni una URL de compilación copiada de una guía antigua. Sube Geyser-Spigot.jar y Floodgate-Spigot.jar a la carpeta plugins.

3. Genera la configuración y vuelve a detener

Inicia el servidor una vez. Revisa el log desde la primera línea: ambos plugins deben habilitarse sin errores de clase, Java o dependencia. Cuando existan plugins/Geyser-Spigot/config.yml y la carpeta de Floodgate, detén por completo. No reemplaces JAR en caliente.

4. Edita solo las claves necesarias

Conserva el archivo generado por tu versión y modifica sus valores existentes. El fragmento esencial es:

• bedrock.address: 0.0.0.0 hace que Geyser escuche en todas las interfaces IPv4 del contenedor o host. No es la dirección que escribe un jugador.
• bedrock.port: 19132 es el puerto UDP de entrada. Si tu panel asignó otro, usa ese mismo número en Geyser, firewall, mapping y cliente.
• clone-remote-port: false conserva el puerto Bedrock explícito. Solo actívalo si el proveedor exige clonar el puerto Java; al activarlo, el valor de port puede ser reemplazado en cada arranque.
• java.auth-type: floodgate indica que la identidad Bedrock la gestiona Floodgate. Sin Floodgate, no selecciones este modo.

En Paper/Purpur con Geyser y Floodgate en el mismo servidor, no copies manualmente key.pem a la carpeta de Geyser: la integración local la encuentra. Una copia sobrante puede provocar una desalineación futura.

5. Arranca y conserva el log completo

Inicia de nuevo, sin /reload. Debes ver Geyser y Floodgate habilitados y un listener Bedrock sin errores de bind. Si el arranque falla, detente aquí; abrir más reglas de red no arreglará un plugin que no cargó.

Abre UDP 19132 sin abrir de más

Java suele escuchar en TCP 25565; Bedrock usa UDP. Una regla TCP para 19132 no permite el tráfico de Geyser. En un VPS Ubuntu con UFW, revisa primero el estado y añade únicamente UDP al puerto elegido:

ss debe mostrar un proceso Java escuchando en UDP. Si no aparece, vuelve al log y a config.yml. UFW es solo una capa: replica la autorización UDP en el firewall de nube o regla de seguridad del proveedor y configura NAT/port forwarding si el host no tiene la IPv4 pública directamente.

Pterodactyl y Docker

Pterodactyl

En Pterodactyl, un administrador del nodo debe crear y asignar la allocation al servidor. El puerto de esa allocation debe coincidir con bedrock.port, y el host debe permitirlo por UDP. Cambiar únicamente YAML dentro del contenedor no reserva un puerto del nodo.

Docker y Compose

En Docker o Compose, publica explícitamente UDP. Esta sección mínima ilustra la diferencia de protocolos:

Recrea el contenedor mediante tu procedimiento de despliegue y confirma el mapping efectivo. El mapping no reemplaza el firewall del host o de la nube; tampoco conviene asumir que UFW filtra de la misma forma todo el tráfico publicado por Docker.

Dirección y DNS para jugadores Bedrock

Entrega una IPv4 pública o un nombre con registro A y el puerto Bedrock explícito. Bedrock no resuelve el registro SRV de Minecraft Java, así que un dominio que funciona sin puerto en Java puede fallar en Bedrock. No indiques 0.0.0.0, 127.0.0.1 ni la IP privada del contenedor a jugadores externos.

Cuándo instalar ViaVersion

Geyser emula un cliente Java 26.2. Si Paper/Purpur, el proxy o cualquiera de los backends rechaza esa versión porque ejecuta una versión anterior, instala una versión actual y compatible de ViaVersion en el punto que procesa el protocolo. En una red proxy, la guía oficial de Geyser indica que, si los backends no ejecutan 26.2, ViaVersion debe estar instalado en esos backends; después prueba el lobby y cada cambio de servidor.

ViaVersion no traduce Bedrock y no sustituye Geyser. Solo hace que el servidor Java acepte el protocolo Java que Geyser presenta. Revisa también las dependencias y compatibilidad de tus otros plugins; la guía de plugins para servidores Minecraft ayuda a ordenar esa revisión, pero la matriz oficial de cada proyecto manda.

Verificación de extremo a extremo

1. Arranque: lee el log completo y confirma que no hay errores de Java 21, clases, YAML, bind o autenticación.
2. Plugins: ejecuta plugins en la consola de Paper/Purpur. Geyser y Floodgate deben aparecer habilitados. En un proxy, usa el comando equivalente de esa plataforma.
3. Listener: ejecuta sudo ss -lunp 'sport = :19132' en el host. Dentro de un contenedor, revisa además el listener interno y el mapping del host.
4. Autodiagnóstico: ejecuta geyser connectiontest <ip-publica> <puerto> en la consola del servidor o proxy. Es un comando de Geyser, no de Bash ni SSH.
5. Prueba externa Bedrock: desde datos móviles u otra red, añade la IPv4/dominio A y el puerto. Una prueba desde la misma LAN puede ocultar un problema de NAT.
6. Regresión Java: entra por el endpoint Java habitual y recorre al menos lobby, autenticación y cambio de backend si existe proxy.
7. Observación: compara un intento Bedrock con el log. Si no aparece ninguna línea, lo más probable es que el intento no alcanzara el listener o no quedara registrado; confirma listener, nivel de log y ruta UDP. Si aparece y luego desconecta, investiga versión, auth, proxy, plugin o anticheat.

Registra las versiones, el puerto, la hora y el resultado. Esa evidencia reduce el diagnóstico de “GeyserMC no funciona” a una capa concreta.

GeyserMC no funciona: diagnóstico por síntoma

La guía oficial de Unable to Connect to World y la lista de problemas comunes son la referencia de actualización. Usa esta tabla para elegir el primer control, no para aplicar todos los cambios a la vez.

Síntoma, capa probable y siguiente prueba:

Seguridad de Floodgate y del puerto Bedrock

• Protege key.pem: no la publiques en tickets, repositorios, copias compartidas ni capturas. Permite que identidades Floodgate crucen la autenticación Java.
• No copies la clave sin necesidad: en el mismo servidor Paper no hace falta. En proxy con Floodgate de backend o en Standalone, copia solo según la topología oficial y usa un canal seguro.
• No desactives online-mode para “arreglar” Floodgate: una instalación Paper directa puede mantener la autenticación Java normal. Los backends detrás de proxy requieren aislamiento y forwarding seguro según Velocity/Bungee, no exposición pública.
• Abre solo el juego: autoriza el UDP elegido; no abras panel, SSH, RCON, base de datos ni puertos administrativos a todos los orígenes.
• No apagues el firewall como solución permanente: si una desactivación temporal y controlada demuestra la causa, vuelve a activarlo y crea la regla mínima.
• Revisa plugins de identidad: permisos, chat, sanciones y bases de datos deben manejar correctamente UUID y nombres Floodgate.

En un VPS, ajusta propietario y permisos de la clave al usuario real del servicio. Este ejemplo no debe ejecutarse con una ruta o usuario sin verificar:

Limitaciones reales con mods, plugins e interfaces

Geyser solo puede trabajar con mods server-side cuando un cliente vanilla puede entrar. No descarga, emula ni traduce un mod que requiere instalación en el cliente. Por eso un modpack Java con bloques, pantallas o paquetes propios del cliente no se vuelve compatible con Bedrock al añadir Geyser.

También existen diferencias que afectan diseños de plugins. La lista oficial de limitaciones actuales incluye la imposibilidad de distinguir clic izquierdo y derecho en ciertos inventarios, argumentos de comandos que no usan Brigadier, algunos encantamientos o recetas personalizadas y estados visuales que Bedrock representa de otra forma. Antes de abrir el servidor, prueba:

• menús de tiendas, subastas, claims y selección de kits;
• comandos esenciales y sus argumentos desde la interfaz Bedrock;
• anticheat, parkour, vehículos y mecánicas sensibles al movimiento;
• resource packs y contenido personalizado;
• permisos, sanciones, chat y teletransporte con una identidad Floodgate nueva.

Una diferencia visual no siempre significa pérdida de estado en el servidor, pero una interacción crítica que depende de un clic imposible sí requiere rediseño o una alternativa compatible.

Mantenimiento y criterio para futuras actualizaciones

1. Antes de una actualización automática de Bedrock, revisa la tabla de versiones de Geyser y su descarga oficial.
2. Haz copia de JAR, configuración y key.pem; registra la versión funcional.
3. Detén por completo, reemplaza el JAR y arranca. Evita hot reload.
4. Revisa si el archivo generado añadió o cambió claves. No pegues una configuración antigua sobre una nueva sin comparar.
5. Actualiza ViaVersion cuando cambie el protocolo Java emulado y verifica todos los backends.
6. Repite conexión Bedrock externa y regresión Java. En redes proxy, prueba cambio de servidor.
7. Revisa limitaciones y anticheat cuando una actualización cambie inventarios, movimiento o contenido personalizado.

El criterio es sencillo: si la tabla oficial aún no enumera una versión recién publicada, trátala como no confirmada, mantén la observación y espera una versión oficial. No conviertas un cambio de protocolo en una búsqueda de “clientes antiguos” de procedencia dudosa.

Rollback: retirar Geyser sin tocar el mundo

Si Java funcionaba antes y el cambio no supera las pruebas, revierte los artefactos y sus configuraciones. Este ejemplo supone una unidad systemd llamada minecraft.service; en Pterodactyl usa Stop/Start del panel. Sustituye BACKUP_DIR por la ruta real creada antes del cambio. Ejecuta este flujo solo durante una ventana sin cambios concurrentes en plugins: reemplaza íntegramente el árbol plugins por el restore point y devuelve ViaVersion a su estado anterior. Si hubo otros cambios desde el backup, no lo ejecutes; restaura mediante un manifiesto explícito de cada artefacto y su estado previo.

Comprueba el log y entra por Java. Si UDP se abrió solo para Geyser, compara ufw-before.txt con el estado actual y elimina únicamente la regla numerada que no existía antes. Si había una regla equivalente en el estado previo, consérvala. Revisa de nuevo la numeración después de cada borrado, incluida cualquier entrada IPv6.

En Docker elimina el mapping UDP en el siguiente despliegue; en Pterodactyl libera la allocation si ya no se necesita; en la nube retira la regla equivalente. No borres ni conviertas mundos: Geyser no requería modificar sus archivos. Conserva la cuarentena hasta confirmar que Java permanece estable.

Preguntas frecuentes

¿Un jugador Bedrock necesita comprar Java Edition?

No cuando Floodgate está instalado y configurado correctamente. Floodgate autentica su identidad Bedrock para entrar al servidor Java a través de Geyser.

¿Java y Bedrock pueden usar el mismo número de puerto?

TCP y UDP son protocolos distintos, por lo que técnicamente pueden compartir un número si el proveedor asigna ambos y no existe otro listener UDP. Mantener Java TCP 25565 y Bedrock UDP 19132 suele ser más claro. Nunca compartas el UDP de Geyser con Voice Chat, Query u otro servicio UDP.

¿Puedo usar el registro SRV de mi servidor Java?

No como ruta general para Bedrock. Usa un registro A/IPv4 y especifica el puerto Bedrock. Un SRV que hace transparente el puerto Java puede producir Invalid IP address o dirigir al destino equivocado.

¿Geyser sirve para Fabric o NeoForge?

Sí, con sus variantes específicas, pero al 30 de julio de 2026 solo corren sobre un servidor 26.2; Fabric requiere Fabric API. Solo los mods server-side compatibles con clientes vanilla son candidatos.

¿Por qué geyser connectiontest no funciona en SSH?

Porque es un comando del plugin o proxy. Ejecútalo en la consola de Minecraft donde Geyser está cargado, con la IP pública y el puerto Bedrock.

¿Puedo conectar desde Xbox, PlayStation o Switch directamente?

No hay una promesa universal. La capacidad de agregar servidores cambia por plataforma; pueden hacer falta BedrockConnect o un proxy LAN. Si móvil o Windows conecta y una consola no, revisa primero el método específico de esa consola.

¿Instalar Geyser cambia o duplica mi mundo?

No. Traduce protocolos hacia el mismo backend Java. El rollback retira plugins, configuración y red; no necesita tocar el mundo.

Conclusión

Un crossplay Java–Bedrock estable depende de alinear cinco capas: versión compatible, variante correcta, autenticación Floodgate, listener UDP y publicación real del puerto. Instala desde la fuente oficial, prueba desde fuera de la red y conserva un rollback que deje Java intacto. Si no queda registro de un intento, empieza por el listener, el log y la ruta UDP; si aparece y falla, investiga versión, autenticación o compatibilidad. Esa separación ahorra más tiempo que cambiar opciones al azar.