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:
| Capa | Estado confirmado | Implicación |
|---|---|---|
| Clientes Bedrock | 26.0 a 26.33 | Actualiza Geyser y valida la tabla si el cliente está fuera de ese intervalo. |
| Cliente Java que Geyser emula | 26.2 | El punto de entrada y todos los backends deben aceptar Java 26.2. |
| Backend Java anterior a 26.2 | Requiere ViaVersion | ViaVersion cubre la diferencia de protocolo; no cambia el mundo. |
| Geyser-Spigot | Paper/Spigot 1.20.5 o posterior; Java 21 o posterior | Comprueba tanto la versión del servidor como el runtime antes de instalar. |
| Geyser-Fabric y Geyser-NeoForge | Actualmente solo en servidor 26.2 | Fabric también necesita Fabric API; los mods que exigen cliente no se traducen. |
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:
| Plataforma | Dónde instalar | Cuándo elegirla | Punto crítico |
|---|---|---|---|
| Paper/Purpur | Geyser-Spigot y Floodgate-Spigot en plugins | Un servidor único o una instalación sin proxy | Paper/Spigot 1.20.5+, Java 21+ y un puerto UDP asignado. |
| Fabric/NeoForge | Variantes mod en mods | Servidor modded cuyo cliente vanilla puede entrar | Solo servidor 26.2 en la fecha de corte; Fabric requiere Fabric API. |
| Velocity/BungeeCord | Geyser y Floodgate en el proxy | Red con lobby y varios backends | Geyser solo en el proxy. Floodgate en backends es opcional para API o skins y exige la misma clave protegida. |
| Standalone | Proceso Java separado que apunta al backend | No hay acceso a plugins/mods en el punto de entrada o se desea separar la pasarela | Java 21+, servicio propio, puerto UDP y dirección/puerto Java remotos correctos. |
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,configy 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
/reloadno 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.
#!/usr/bin/env bash
set -Eeuo pipefail
SERVER_DIR=/srv/minecraft
BACKUP_DIR=$HOME/minecraft-backups/geyser-$(date +%Y%m%d-%H%M%S)
UNIT=minecraft.service
umask 077
SERVICE_STATE=$(sudo systemctl show "$UNIT" --property=ActiveState --value)
[[ "$SERVICE_STATE" == inactive || "$SERVICE_STATE" == failed ]] || {
printf '%s\n' "El servicio $UNIT no está detenido; backup cancelado." >&2
exit 70
}
[[ -d "$SERVER_DIR/plugins" ]] || {
printf '%s\n' "No existe $SERVER_DIR/plugins." >&2
exit 66
}
install -d -m 700 "$BACKUP_DIR"
sudo cp -a -- "$SERVER_DIR/plugins" "$BACKUP_DIR/plugins"
if [[ -d "$SERVER_DIR/config" ]]; then
sudo cp -a -- "$SERVER_DIR/config" "$BACKUP_DIR/config"
fi
sudo find "$BACKUP_DIR/plugins" -type f -name key.pem -exec chmod 600 {} +
sudo ufw status numbered | tee "$BACKUP_DIR/ufw-before.txt" >/dev/null
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.
java -version
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
port: 19132
clone-remote-port: false
java:
auth-type: floodgate
bedrock.address: 0.0.0.0hace que Geyser escuche en todas las interfaces IPv4 del contenedor o host. No es la dirección que escribe un jugador.bedrock.port: 19132es el puerto UDP de entrada. Si tu panel asignó otro, usa ese mismo número en Geyser, firewall, mapping y cliente.clone-remote-port: falseconserva el puerto Bedrock explícito. Solo actívalo si el proveedor exige clonar el puerto Java; al activarlo, el valor deportpuede ser reemplazado en cada arranque.java.auth-type: floodgateindica 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:
sudo ufw status verbose
sudo ufw allow 19132/udp comment 'Geyser Bedrock'
sudo ufw status numbered
sudo ss -lunp 'sport = :19132'
Abre tu servidor a jugadores Java y Bedrock
Elige un entorno de hosting Minecraft para desplegar Geyser y administrar versiones, plugins y acceso de red desde una misma infraestructura.
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:
services:
minecraft:
ports:
- '25565:25565/tcp'
- '19132:19132/udp'
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
- Arranque: lee el log completo y confirma que no hay errores de Java 21, clases, YAML, bind o autenticación.
- Plugins: ejecuta
pluginsen la consola de Paper/Purpur. Geyser y Floodgate deben aparecer habilitados. En un proxy, usa el comando equivalente de esa plataforma. - 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. - 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. - 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.
- Regresión Java: entra por el endpoint Java habitual y recorre al menos lobby, autenticación y cambio de backend si existe proxy.
- 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:
| Síntoma | Capa probable | Qué comprobar |
|---|---|---|
| Unable to connect to world y no hay línea nueva en consola | Red antes de Geyser | IP y puerto Bedrock, UDP en UFW/nube/NAT, allocation de Pterodactyl, mapping Docker y connectiontest. No cambies auth todavía. |
Geyser no aparece en plugins | Carga del plugin | JAR para Spigot en plugins, Paper/Spigot 1.20.5+, Java 21+ y la primera excepción del log. No mires solo la última línea. |
| Outdated client o Outdated server | Protocolo | Actualiza Geyser oficialmente, revisa la tabla soportada e instala ViaVersion si el backend es anterior a 26.2. Para Bedrock 26.34, recuerda que al corte aún no estaba confirmado; no asumas que el firewall es culpable. |
| Address already in use o BindException | Puerto local ocupado | Identifica el listener con sudo ss -lunp 'sport = :19132'. Detén la instancia duplicada o asigna otro UDP; no mates procesos a ciegas. Voice Chat y Query no pueden compartirlo. |
| Java entra, Bedrock no | Ruta UDP o DNS Bedrock | Verifica que no abriste solo TCP, que el cliente usa el puerto Bedrock y que el dominio tiene A/IPv4. Bedrock no usa el SRV de Java. |
| El intento aparece, pero falla el login | Auth/Floodgate | Confirma que Floodgate cargó y auth-type es floodgate. En el mismo Paper elimina copias manuales obsoletas de la clave; en proxy/Standalone comprueba que la clave requerida coincide y está protegida. |
| Funciona en host, falla en Pterodactyl o Docker | Aislamiento del contenedor | Alinea cuatro valores: listener interno, allocation o mapping UDP, firewall del host y puerto público. Abrir UFW por sí solo no publica un puerto del contenedor. |
| Móviles/PC entran, consola no | Método de conexión de consola | Las consolas restringen servidores personalizados según plataforma. BedrockConnect o un proxy LAN pueden ser necesarios; prueba primero con un cliente móvil/Windows como control y no prometas conexión directa universal. |
| Entra y luego el anticheat expulsa al jugador | Compatibilidad de movimientos/paquetes | Consulta la matriz oficial de anticheat, actualiza y aplica solo los ajustes documentados para Bedrock/Floodgate. |
| La conexión funciona, pero hay lag | Rendimiento | Separa traducción de ticks, red y plugins. Perfila durante un caso reproducible; la guía de diagnóstico con spark evita atribuir todo a Geyser sin datos. |
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-modepara “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:
KEY_FILE=/srv/minecraft/plugins/floodgate/key.pem
sudo chown minecraft:minecraft "$KEY_FILE"
sudo chmod 600 "$KEY_FILE"
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
- Antes de una actualización automática de Bedrock, revisa la tabla de versiones de Geyser y su descarga oficial.
- Haz copia de JAR, configuración y
key.pem; registra la versión funcional. - Detén por completo, reemplaza el JAR y arranca. Evita hot reload.
- Revisa si el archivo generado añadió o cambió claves. No pegues una configuración antigua sobre una nueva sin comparar.
- Actualiza ViaVersion cuando cambie el protocolo Java emulado y verifica todos los backends.
- Repite conexión Bedrock externa y regresión Java. En redes proxy, prueba cambio de servidor.
- 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.
#!/usr/bin/env bash
set -Eeuo pipefail
SERVER_DIR=/srv/minecraft
BACKUP_DIR=/home/minecraft/minecraft-backups/geyser-20260730-120000
UNIT=minecraft.service
QUARANTINE_DIR="$SERVER_DIR/rollback-geyser-$(date +%Y%m%d-%H%M%S)"
[[ -d "$SERVER_DIR/plugins" ]] || {
printf '%s\n' "No existe $SERVER_DIR/plugins." >&2
exit 66
}
[[ -d "$BACKUP_DIR/plugins" ]] || {
printf '%s\n' "El restore point no contiene plugins: $BACKUP_DIR." >&2
exit 66
}
sudo systemctl stop "$UNIT"
if sudo systemctl is-active --quiet "$UNIT"; then
printf '%s\n' "El servicio sigue activo; rollback cancelado." >&2
exit 70
fi
sudo install -d -m 700 "$QUARANTINE_DIR"
sudo mv -- "$SERVER_DIR/plugins" "$QUARANTINE_DIR/plugins-after-change"
sudo cp -a -- "$BACKUP_DIR/plugins" "$SERVER_DIR/plugins"
sudo systemctl start "$UNIT"
sudo systemctl is-active --quiet "$UNIT"
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.
#!/usr/bin/env bash
set -Eeuo pipefail
BACKUP_DIR=/home/minecraft/minecraft-backups/geyser-20260730-120000
[[ -f "$BACKUP_DIR/ufw-before.txt" ]] || {
printf '%s\n' "Falta el estado previo de UFW; no se eliminará ninguna regla." >&2
exit 66
}
sudo ufw status numbered
diff -u "$BACKUP_DIR/ufw-before.txt" <(sudo ufw status numbered) || true
read -r -p 'Número exacto de la regla nueva de Geyser (vacío para cancelar): ' RULE_NUMBER
[[ "$RULE_NUMBER" =~ ^[0-9]+$ ]] || {
printf '%s\n' 'No se seleccionó una regla exacta; UFW queda sin cambios.' >&2
exit 64
}
sudo ufw delete "$RULE_NUMBER"
sudo ufw status numbered
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.
