BungeeCord IP Forwarding se encarga de que un backend reciba la IP real del jugador, el UUID online y la información de perfil, aunque la conexión TCP provenga del proxy. Para ello deben coincidir cuatro valores, y el puerto del backend debe estar protegido contra conexiones directas.

ip_forward: true no es un firewall. El formato clásico de BungeeCord no tiene un secreto de firma específico del proxy. Quien alcance un backend en Offline-Mode sin protección puede falsificar los datos de forwarding y hacerse pasar por otro jugador.

Los cuatro valores

Ubicación Archivo/Campo Valor normal
BungeeCord config.yml → online_mode true
BungeeCord config.yml → ip_forward true
Backend server.properties → online-mode false
Backend spigot.yml → settings.bungeecord true

Para Paper actual se añade:

# config/paper-global.yml
proxies:
  bungee-cord:
    online-mode: true

Este valor de Paper corresponde al Online-Mode del proxy. Permanece en true, aunque server.properties en el backend usa online-mode=false.

Por qué necesitas una copia de seguridad antes del cambio

Sin forwarding, el backend en Offline-Mode genera un UUID a partir del nombre del jugador. Con el forwarding correcto, recibe el UUID procedente de la autenticación online. Estos valores no son idénticos. El inventario, el Enderchest, los rangos o los datos de economía pueden parecer desaparecidos después del cambio, aunque siguen guardados bajo el UUID antiguo.

Antes del cambio:

  1. haz una copia de seguridad de los mundos, playerdata y las bases de datos de permisos y plugins;
  2. prueba una restauración;
  3. documenta el UUID antiguo y el esperado para un jugador de prueba;
  4. revisa las herramientas de migración específicas de cada plugin;
  5. nunca cambies nombres de archivo a ciegas sin conocer las referencias y el formato de datos.

La guía existente sobre el cambio de versión describe una ruta adecuada de copia de seguridad, copia y rollback.

Paso 1: configurar el proxy

Detén BungeeCord de forma limpia y edita el config.yml actual:

online_mode: true
ip_forward: true

Deja activa la autenticación pública en el proxy. Revisa en paralelo los listeners, servers y priorities con la referencia de campos de config.yml.

Paso 2: configurar el backend

Detén completamente cada backend y cambia:

# server.properties
online-mode=false

# spigot.yml
settings:
  bungeecord: true

En Paper también debes establecer el valor proxies.bungee-cord.online-mode mostrado. Reinicia primero los backends y después BungeeCord. Una recarga parcial no es suficiente para este cambio de identidad.

Paso 3: cerrar la ruta del backend

Permite el puerto TCP del backend exclusivamente desde la ruta de proxy verificada. Según tu propia infraestructura, esto puede ser loopback, una red privada/VPN real o una regla de firewall estricta. En entornos con contenedores, una IP interna por sí sola no es suficiente: una instancia ajena en la misma bridge no debe poder pasar por el proxy.

En game-serverhosting, el guard activo vincula los backends de BungeeCord compatibles a la instancia de proxy concreta y resuelve de nuevo su origen actual del contenedor. Un origen detenido, ausente o ambiguo se queda en drop-only. Las rutas same-node, cross-node y de backend externo se probaron con un join real a través del proxy; el acceso directo independiente permaneció bloqueado. Esto es una afirmación sobre estas rutas comprobadas, no una garantía para redes de proveedores externos arbitrarias.

La guía completa de configuración clasifica estas variantes de red.

Cómo entender correctamente BungeeGuard

BungeeGuard complementa el formato legacy con un token compartido. Usa al menos la versión 1.4.0. La página de seguridad del proyecto documenta una filtración de token para configuraciones antiguas de BungeeCord; tras la actualización, un token posiblemente afectado debe rotarse en el proxy y en los backends.

  • genera el token localmente con suficiente entropía;
  • nunca lo copies en tickets, logs, capturas de pantalla o Git;
  • actualiza el proxy y todos los backends de forma coordinada;
  • elimina el token antiguo solo tras una prueba exitosa;
  • ante una versión desconocida o antigua, trata el estado como no verificado.

BungeeGuard es especialmente útil en hosting compartido, pero no sustituye a una solución de firewall/red privada disponible como primera capa de protección.

Verificación: cuatro señales independientes

  1. Proceso: el proxy y el backend están completamente iniciados.
  2. TCP: el proxy alcanza el listener del backend.
  3. Lobby-Join: un jugador real autenticado llega al backend a través del proxy.
  4. Identidad: el backend ve el UUID online esperado y la IP del cliente, no el UUID offline ni solo la IP del proxy.

A continuación llega la prueba negativa: una fuente independiente no debe poder alcanzar el puerto del backend. Un listener abierto o un ping exitoso por sí solos no son prueba de join.

Errores típicos

Síntoma Causa Siguiente paso
todos los jugadores tienen la IP del proxy ip_forward o bungeecord desactivado revisa ambos lados, reinicia por completo
el jugador tiene un inventario nuevo cambió el modo de UUID conserva la copia de seguridad, compara los UUID, migra según cada plugin
If you wish to use IP forwarding... el backend espera forwarding, el proxy no lo envía revisa el valor del proxy y la config exacta iniciada
es posible un join directo con un nombre ajeno el backend es accesible públicamente corrige de inmediato el firewall/red privada
el proxy tampoco alcanza el backend la regla de acceso tiene un origen incorrecto o desactualizado vuelve a evaluar la asignación concreta del proxy, no abras de forma amplia
no hay join tras la actualización de BungeeGuard el token es inconsistente revisa las versiones desplegadas, rota de forma coordinada

Si falta el destino de inicio, te ayuda la guía de errores de fallback. Los dominios siguen apuntando al proxy; usa para ello la guía de dominio/SRV.

Plugins y crossplay

Los plugins de permisos, bans y economía son especialmente sensibles al UUID. Haz una copia de seguridad de sus datos y comprueba si se necesita un componente tanto en el proxy como en el backend. La guía de plugins explica la separación de plataformas.

En una red con proxy, Geyser se instala únicamente en el proxy. Bedrock-UDP y Java-TCP siguen siendo rutas separadas; key.pem es secreto. Configura Geyser/Floodgate solo cuando el forwarding y la prueba negativa del lado Java estén en verde.

FAQ

¿Es ip_forward: true una protección?

No. Solo se encarga de que la IP, el UUID y el perfil se reenvíen al backend. El formato clásico no tiene un secreto de firma específico del proxy: quien alcance directamente un backend en Offline-Mode sin protección puede falsificar estos datos. La protección es el límite de red, no la configuración.

¿Por qué en el backend figura online-mode=false?

Porque la autenticación contra Mojang ya se realiza en el proxy; de lo contrario, el backend la exigiría por segunda vez y rechazaría a cada jugador. En Paper, proxies.bungee-cord.online-mode sigue siendo true: este valor refleja el Online-Mode del proxy, no el del backend.

¿Por qué los jugadores tienen el inventario vacío tras el cambio?

Porque el UUID ha cambiado. Sin forwarding, un backend en Offline-Mode genera el UUID a partir del nombre del jugador; con forwarding llega el UUID online real. Los datos antiguos no se han perdido, están guardados bajo el UUID anterior — por eso una copia de seguridad probada debe preceder al cambio.

¿Necesito BungeeGuard?

Complementa el formato legacy con un token compartido y resulta especialmente útil en hosting compartido, donde no puedes establecer tu propia regla de firewall. Usa al menos la versión 1.4.0 y rota el token tras una actualización. No sustituye a una solución de firewall o red privada disponible.

¿Dónde va Geyser en una red con proxy?

Únicamente en el proxy, no también en los backends. Bedrock funciona por UDP, Java por TCP — ambas rutas se comprueban por separado, y key.pem es secreto. Configura el crossplay solo cuando el forwarding y la prueba negativa del lado Java estén en verde.

Fuentes primarias