BungeeCord conecta varios servidores de Minecraft Java bajo una dirección común. El proxy autentica al jugador y lo redirige al lobby, survival u otros backends. No hospeda ningún mundo por sí mismo. Una red mínima necesita, por tanto, al menos dos procesos o instancias de hosting separados: un proxy BungeeCord y un backend de Minecraft.

La regla de seguridad más importante: los backends funcionan detrás de BungeeCord en modo offline. Por eso nunca deben ser accesibles libremente desde internet. ip_forward: true transmite la identidad, pero no es un control de acceso. Cierra la protección de firewall/red privada antes de considerar la red como terminada.

Así se ve una red BungeeCord

Minecraft Java Client
        |
        | dirección pública del proxy
        v
 BungeeCord (online_mode=true, ip_forward=true)
        |
        | solo ruta de proxy autorizada
        +---------------------+
        v                     v
 Lobby / Paper          Survival / Paper
 online-mode=false      online-mode=false
 bungeecord=true        bungeecord=true

El proxy se encarga del login, la dirección pública, el enrutamiento y los comandos de proxy. Los backends almacenan mundos, inventarios y datos de plugins de Bukkit/Paper. BungeeCord no sincroniza estos datos automáticamente. Los rangos, baneos o inventarios a nivel de red necesitan para ello plugins adecuados y, por lo general, una base de datos compartida.

¿Qué topología encaja?

La configuración de BungeeCord se ve similar en todas las variantes, pero la ruta segura de red no. Decide la topología antes de introducir direcciones en config.yml.

Proxy y backend en el mismo nodo

Dos instancias de hosting en el mismo nodo siguen siendo contenedores separados. El proxy puede alcanzar el backend a través de la dirección interna prevista para ello; una instancia ajena en el mismo puente no debería poder hacerlo. Por eso, habilitar toda la subred de Docker sería demasiado amplio. La protección debe permanecer vinculada a la fuente concreta del proxy y volver a resolverse tras un reinicio del contenedor.

Proxy y backend en nodos distintos

Aquí la ruta pasa por la red del nodo. Permite en el backend exactamente el origen del proxy correspondiente y el puerto TCP concreto. No abras accidentalmente UDP, un rango de puertos o toda la IP del nodo para otras instancias de clientes. Comprueba la ruta positiva desde el proxy y la ruta negativa desde una fuente independiente en la misma ventana de tiempo.

Backend externo

Un backend fuera de la plataforma de hosting necesita una ruta que el proxy de BungeeCord pueda alcanzar. El operador del sistema externo es responsable de su propio firewall. Un túnel inverso o una VPN pueden establecer el transporte, pero solo es seguro si el backend permanece vinculado localmente y únicamente se permite pasar la ruta de proxy autorizada. Los textos de producto solo deben calificar esta variante como segura cuando se hayan comprobado la ruta positiva y la negativa para la configuración concreta.

Varios proxys

Varios proxys para alta disponibilidad son un diseño propio. Cada ruta de origen permitida, el almacenamiento compartido de plugins/datos y el manejo de sesiones deben planificarse explícitamente. No copies simplemente otra IP en una lista de permitidos amplia. Esta guía describe deliberadamente un proxy asignado por ruta de backend.

Requisitos previos y modelo de costes

Necesitas:

  • una instancia de BungeeCord;
  • al menos un servidor Paper/Spigot separado como backend;
  • un puerto TCP único por proceso;
  • una ruta accesible del proxy al backend;
  • un firewall, una red privada o un control de acceso comparable y verificado;
  • una copia de seguridad probada antes de modificar un servidor existente.

En game-serverhosting, BungeeCord es un software de servidor propio. Planifica el proxy y los backends como instancias separadas. Si aún no tienes instancias, empieza por el pedido de servidor de Minecraft. La base de código actual de BungeeCord compila contra Java 17; el Egg ofrecido funciona con Java 21. No confíes en viejas afirmaciones generales como «512 MB para 500 jugadores»: los plugins, la tasa de conexiones, la compresión y los ataques modifican notablemente los requisitos.

Paso 1: Anotar la arquitectura y los puertos

Da a cada instancia un nombre y un rol. Un ejemplo sencillo:

Rol ¿accesible públicamente? Puerto de ejemplo
Proxy BungeeCord sí 25565/TCP
Backend Lobby no puerto TCP propio
Backend Survival no puerto TCP propio
Geyser en el proxy opcional puerto UDP propio

127.0.0.1 solo funciona si el proxy y el backend comparten el mismo namespace de red. Dos contenedores de Pterodactyl en el mismo host no están conectados automáticamente por loopback. Usa exactamente la dirección de backend que tu proxy pueda alcanzar y, por eso, nunca abras preventivamente toda una subred de contenedores.

Paso 2: Asegurar los servidores existentes

Antes de cambiar el online mode o el forwarding, guarda una copia de seguridad de los mundos, playerdata, las bases de datos de plugins y los archivos de configuración. Realiza al menos una restauración de prueba. Al pasar de UUIDs offline a online, los jugadores pueden aparecer como cuentas nuevas aunque sus archivos antiguos sigan existiendo. La guía para un cambio de versión seguro explica la ruta de copia de seguridad, copia y rollback que también deberías usar para esta migración.

Paso 3: Iniciar el proxy y editar config.yml

Inicia BungeeCord una vez y luego detén el proxy correctamente. Así se genera un config.yml adaptado a la versión instalada. La referencia completa de campos la encontrarás en BungeeCord config.yml explicado.

Un modelo mínimo y abreviado se ve así:

online_mode: true
ip_forward: true
player_limit: -1

servers:
  lobby:
    address: <DIRECCIÓN-LOBBY>:<PUERTO-LOBBY>
    motd: '&aLobby'
    restricted: false
  survival:
    address: <DIRECCIÓN-SURVIVAL>:<PUERTO-SURVIVAL>
    motd: '&aSurvival'
    restricted: false

listeners:
  - host: 0.0.0.0:<PUERTO-PROXY>
    priorities:
      - lobby
      - survival
    force_default_server: true
    max_players: 100

max_players influye en el número de slots mostrado. El límite duro global es player_limit; valores de cero o menores significan ahí ilimitado. Los nombres de backend bajo priorities deben coincidir exactamente con las claves bajo servers.

Paso 4: Configurar los backends para el forwarding

En cada backend Paper/Spigot:

# server.properties
online-mode=false

# spigot.yml
settings:
  bungeecord: true

Con Paper actual, comprueba adicionalmente en config/paper-global.yml:

proxies:
  bungee-cord:
    online-mode: true

Este valor de Paper describe el online mode del proxy y debe coincidir con él. No contradice el online-mode=false de server.properties. Los cuatro valores y las consecuencias de UUID/backup se explican en detalle en Configurar de forma segura el IP Forwarding de BungeeCord.

Paso 5: Proteger el acceso al backend

Ahora llega el paso que falta en muchos tutoriales antiguos. Permite el puerto TCP del backend exclusivamente desde el proxy correspondiente, o vincúlalo a una red privada realmente compartida. Una simple IP interna, restricted: true o bungeecord: true no es una prueba de seguridad.

En game-serverhosting, la ruta de proxy permitida para las topologías BungeeCord soportadas se deriva de la instancia de proxy concreta mediante el guard de backend activo. Si la fuente falta o se detiene, la ruta permanece en solo-drop. Para un backend operado externamente, debes configurar tú mismo su firewall de modo que solo se permita la ruta de proxy verificada.

BungeeGuard puede ofrecer protección adicional mediante token en hosting compartido. Usa al menos la versión 1.4.0; las instalaciones afectadas más antiguas deben actualizarse y rotar el token. El token nunca debe aparecer en tickets, capturas de pantalla o registros. BungeeGuard complementa la protección de red y no hace automáticamente invisible una superficie de ataque accesible.

Paso 6: Orden de inicio y pruebas reales

Inicia primero los backends y después el proxy. Comprueba más de un puerto abierto:

  1. El proceso del proxy está en ejecución y escucha en la asignación indicada.
  2. El proxy alcanza la dirección del lobby por TCP.
  3. El ping de Minecraft a través de la dirección pública del proxy funciona.
  4. Una cuenta de prueba real llega al lobby y puede cambiar de servidor.
  5. La IP y el UUID online llegan correctamente al backend.
  6. Un acceso directo independiente al puerto del backend falla.

Solo el punto 6 convierte una ruta de forwarding funcional en un resultado protegido. Si el ingreso falla, sigue el árbol de diagnóstico para «Could not connect to a default or fallback server» sin abrir el firewall de forma general para ello.

Planificar enrutamiento, fallback y mantenimiento

priorities no es solo una lista para el primer join. También determina qué destinos prueba BungeeCord en orden cuando un servidor falla. Coloca en la primera posición un backend pequeño y fiablemente compatible. Un servidor survival con un modpack pesado rara vez es el mejor fallback técnico.

forced_hosts puede dirigir distintos dominios a distintos destinos de inicio. Ejemplo: creative.example.net inicia en creative, mientras que play.example.net empieza en el lobby. Ambos nombres DNS apuntan al mismo proxy. Prueba cada nombre de host por separado, porque un valor predeterminado funcional no dice nada sobre un error tipográfico en el mapeo de forced host.

restricted: true tiene sentido para servidores de mantenimiento o de equipo. El permiso correspondiente bungeecord.server.<name> debe evaluarse a nivel de proxy. Evita que un jugador normal cambie a través de BungeeCord, pero no protege contra un acceso TCP directo al backend.

Para el mantenimiento se recomienda este procedimiento:

  1. Sacar el servidor objetivo de la prioridad usada públicamente o bloquearlo mediante permiso.
  2. Mover de forma controlada a los jugadores conectados a un backend saludable.
  3. Asegurar y mantener el backend.
  4. Comprobar el TCP proxy-a-backend y un join de prueba real.
  5. Solo entonces volver a habilitar el enrutamiento.

Un reinicio del proxy desconecta a todos los jugadores conectados a través de él. Los mundos siguen funcionando en los backends, pero el reinicio sigue siendo una interrupción visible y debe programarse en una ventana de mantenimiento.

Revisión de seguridad antes de la puesta en marcha

Repasa este límite una vez desde la perspectiva de un atacante:

  • ¿Solo el proxy está documentado como dirección pública de Minecraft?
  • ¿Está bloqueado cada puerto de backend desde una estación de trabajo independiente?
  • ¿Puede otra instancia en el mismo nodo/puente compartido alcanzar el puerto?
  • ¿Se reevalúa la fuente actual del proxy tras un stop/start?
  • ¿Permanece en fail-closed un proxy detenido o no resoluble de forma unívoca?
  • ¿Se han eliminado tokens, IPs completas y key.pem de capturas de pantalla y registros de soporte?
  • ¿Solo un grupo reducido de personas tiene permisos como /ip, /send, /alert y /end?
  • ¿Son de confianza todos los backends registrados? Los backends pueden influir en el conjunto mediante Plugin Messaging.

Si no puedes responder a una pregunta con una prueba o una regla concreta, el estado es unverified, no «probablemente seguro». Esto es especialmente importante en hosting compartido: una dirección que parece interna todavía no garantiza la separación entre clientes.

Copias de seguridad, actualizaciones y monitorización

BungeeCord no tiene mundo propio, pero su estado sigue siendo relevante para la recuperación. Antes de actualizar, asegura:

  • config.yml y modules.yml;
  • plugins/ del proxy junto con sus configuraciones;
  • las bases de datos de plugins locales o externas de forma consistente;
  • la versión de build de BungeeCord y de Java utilizadas;
  • documentación redactada de nombres de backend, puertos y reglas de protección.

Los mundos, playerdata y los datos de plugins de Bukkit/Paper se aseguran por separado en los backends. Una copia de seguridad del proxy no sustituye a una copia de seguridad del mundo. Tras una restauración, comprueba no solo si los archivos existen, sino si el join al lobby, el UUID, los permisos y el cambio de servidor vuelven a ser correctos.

Para una actualización, detén el proxy correctamente, reemplaza solo el JAR o usa el instalador previsto, y revisa primero el log de inicio. Después siguen el ping de Minecraft, un join real, la identidad, el fallback y la ruta directa que debe seguir bloqueada. Ten preparado el último JAR funcional junto con la configuración correspondiente como rollback.

La monitorización separa como mínimo estas señales:

Señal Qué demuestra Qué no demuestra
El proceso está en ejecución Existe el proceso Java Que el listener o el join funcionen
Listener TCP abierto El puerto acepta conexiones Que el protocolo de Minecraft o el lobby estén sanos
Ping de Minecraft El proxy responde conforme al protocolo Que un jugador pueda entrar en un backend
Join sintético al lobby Funciona toda la ruta positiva Que el backend esté protegido contra acceso directo
Prueba negativa de backend Se bloquea una fuente independiente Que funcionen todas las fuentes de proxy permitidas

Observa además el heap/GC, los bloqueos del event loop, las excepciones de plugins, los timeouts del backend y tasas de conexión inusuales. Un indicador verde en el panel no debe reducir varios de estos estados a un simple «en línea».

Evitar errores habituales de configuración

  • Puerto de proxy y de backend intercambiados: los jugadores llegan directamente al backend en modo offline o BungeeCord se conecta a sí mismo.
  • Dominio público como dirección de backend: el proxy entra en un bucle de DNS/enrutamiento. Usa la dirección interna concreta de destino.
  • max_players interpretado como límite duro: la lista de servidores muestra el valor, mientras que player_limit puede seguir siendo ilimitado.
  • Solo se hizo una prueba TCP: el listener está abierto, pero el lobby, el forwarding o el protocolo fallan.
  • Firewall desactivado para depurar: el join positivo funciona mientras, al mismo tiempo, queda abierto un bypass de identidad.
  • Plugin de Bukkit instalado en el proxy: la plataforma o las dependencias no coinciden; lee el descriptor y la página del proyecto.
  • /greload tras cambios profundos: partes de la configuración o de los plugins quedan en el estado antiguo. Usa un reinicio completo.
  • Copia de seguridad sin prueba de restauración: solo en caso de fallo se ve que la base de datos, los mundos o el estado de los plugins no se guardaron de forma consistente.

Apuntar el dominio y el SRV al proxy

El DNS siempre apunta al proxy público. Con un puerto Java distinto, un registro SRV _minecraft._tcp puede mapear el puerto. El destino del SRV debe ser un nombre de host, no una IP. Los pasos exactos de A/CNAME/SRV están en la guía Conectar tu propio dominio con tu servidor de juego.

Los forced hosts no cambian esto: solo usan el nombre de host solicitado por el cliente como información de enrutamiento. También survival.example.net apunta primero al proxy; solo BungeeCord redirige internamente a survival.

Distribuir plugins y permisos correctamente

  • Los plugins de BungeeCord van en plugins/ del proxy.
  • Los plugins de Bukkit/Paper van en el backend correspondiente.
  • Algunos plugins de red necesitan componentes en ambos niveles.
  • Los permisos de proxy no están automáticamente disponibles en un plugin de permisos que solo funcione a nivel de backend.
  • Tras cambios de plugins, un reinicio completo y planificado es más fiable que /greload.

Usa solo plugins de fuentes de confianza y comprueba la plataforma, la versión, las dependencias y los avisos de seguridad. La guía de plugins muestra la ruta en el panel para plugins de Paper/Spigot; los plugins de proxy debes reconocerlos explícitamente como compatibles con BungeeCord.

Crossplay con Bedrock mediante Geyser

En una red BungeeCord instalas Geyser en el proxy, no en cada backend. Java usa TCP, el listener de Bedrock usa UDP. Floodgate basta en el proxy, siempre que los plugins del backend no necesiten su API ni el soporte adicional de skins. key.pem es un secreto de autenticación.

La comprobación de puertos y de join sigue siendo separada para TCP y UDP. Usa la guía de crossplay Geyser/Floodgate una vez que la ruta pura de Java funcione de forma segura.

¿BungeeCord o Velocity?

BungeeCord sigue desarrollándose activamente en 2026. Waterfall, el antiguo fork de PaperMC, en cambio, ha llegado a su fin de vida útil. PaperMC recomienda Velocity para redes nuevas y señala él mismo que su propia comparación puede estar sesgada a favor de su propio producto.

Para una red existente con plugins de BungeeCord importantes, BungeeCord puede ser la opción de menor riesgo. Para una red nueva sobre versiones actuales de Paper, Velocity ofrece Modern Forwarding con un formato secreto protegido por MAC. No decidas basándote en cifras generales de rendimiento, sino en versiones, API de plugins, forwarding y migración. El artículo BungeeCord vs Velocity 2026 contiene la matriz de decisión.

FAQ

¿Es BungeeCord un servidor de Minecraft?

No. BungeeCord es un proxy. Los mundos, chunks, mobs y modos de juego se ejecutan en backends separados.

¿Cuántos servidores necesito?

Al menos dos procesos o instancias: proxy y un backend. Para lobby más modo de juego, tres instancias son razonables.

¿Debe el proxy funcionar en online mode?

Para una red autenticada normal, sí: online_mode: true en el proxy. Los backends usan online-mode=false, porque el proxy ya ha autenticado.

¿Es seguro ip_forward?

Es necesario para IPs reales y UUIDs online, pero por sí solo no es seguro. El forwarding legacy no tiene un secreto de firma específico del proxy. El puerto del backend debe estar protegido frente a fuentes no confiables.

¿Un reinicio del proxy reinicia mis mundos?

No. Los backends siguen funcionando, pero los jugadores conectados a través del proxy son desconectados.

¿Necesito un lobby?

No obligatoriamente. Se necesita al menos un destino accesible en priorities; un lobby propio suele hacer más claro el fallback y el mantenimiento.

¿Qué puertos necesita BungeeCord?

El listener público de Java usa TCP. Cada backend necesita un puerto TCP propio, accesible solo para el proxy. Query y Geyser/Bedrock usan puertos UDP separados si se activan; no los abras si no se usa la función.

¿Puedo instalar plugins de Paper en BungeeCord?

No, no en general. Los plugins de Paper/Bukkit van en los backends. El proxy necesita plugins construidos explícitamente para BungeeCord. Los plugins de red pueden entregar dos componentes separados.

¿Por qué mi backend solo ve la IP del proxy?

Normalmente ip_forward en el proxy o settings.bungeecord en el backend está desactivado. Comprueba ambos lados y reinicia por completo. Cambia valores relevantes para el UUID solo después de una copia de seguridad.

¿Puedo usar varios dominios?

Sí. Todos los dominios apuntan al proxy. forced_hosts puede asignar después el nombre de host solicitado a un backend de inicio.

¿Funciona el crossplay automáticamente en cada backend?

Geyser traduce Bedrock en el proxy. Los backends deben aceptar la versión de protocolo Java emulada por Geyser; con diferencias de versión puede ser necesaria una configuración de ViaVersion cuidadosamente comprobada. La accesibilidad UDP se prueba por separado del TCP de Java.

Comprobación final

La red solo está terminada cuando el join real a través del proxy funciona y un join directo independiente al backend en modo offline está bloqueado. Documenta las direcciones y reglas de forma redactada, guarda por separado la configuración y los datos del mundo, y programa la siguiente revisión técnica antes de la fecha indicada si BungeeCord, Java, BungeeGuard, Paper, Velocity o Geyser publican una versión relevante.

Guarda además, para futuros casos de soporte, el momento y la zona horaria de la prueba, las versiones de proxy/backend y el primer mensaje de error concreto. Enmascara al hacerlo las direcciones IP de los jugadores y elimina por completo los secretos. Así puede reconstruirse más adelante una diferencia entre error de proceso, red, protocolo, identidad y plugin, sin incorporar datos sensibles de clientes a una base de conocimiento permanente.

Fuentes primarias