El config.yml define dónde escucha BungeeCord, qué backends conoce y hacia dónde se dirige a los jugadores nuevos. Genera siempre el archivo con tu versión instalada. Los ejemplos antiguos de blogs pueden contener campos o valores predeterminados que ya no encajan con el build actual.

Una configuración sintácticamente válida no es todavía una red segura. En cuanto los backends usen online-mode=false, su puerto TCP debe estar protegido frente a conexiones directas. El proceso completo está en el pilar de configuración de BungeeCord.

Estructura base segura

online_mode: true
ip_forward: true
player_limit: -1
server_connect_timeout: 5000
remote_ping_timeout: 5000

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

listeners:
  - host: 0.0.0.0:<PUERTO-PROXY>
    motd: '&aMi Red'
    priorities:
      - lobby
      - survival
    force_default_server: true
    forced_hosts:
      survival.example.net: survival
    max_players: 100
    tab_list: GLOBAL_PING
    query_enabled: false
    proxy_protocol: false

Los marcadores de posición deben sustituirse por las direcciones de tu panel. Que en el ejemplo aparezca una dirección de backend pública no significa que esté permitido dejar el puerto abierto públicamente.

Campos globales

Campo Significado Clasificación segura
online_mode autenticación en el proxy true para redes premium normales
ip_forward IP, UUID y perfil hacia el backend necesario, pero no es un control de acceso
player_limit límite global estricto de jugadores 0 o menos significa ilimitado
server_connect_timeout tiempo para la conexión al backend demasiado bajo genera falsas alarmas, demasiado alto provoca esperas largas
remote_ping_timeout tiempo límite para los pings al backend un ping no es lo mismo que una conexión real
remote_ping_cache caché del estado del backend puede mostrar brevemente un estado antiguo
connection_throttle ventana de tiempo para nuevas conexiones no es una protección completa contra bots o DDoS
forge_support soporte adicional para el handshake de Forge comprueba aparte la compatibilidad del modloader

servers: nombrar los backends

Cada clave bajo servers es un nombre interno. address debe ser accesible desde el proceso del proxy. restricted: true exige el permiso bungeecord.server.<nombre>, pero no impide el acceso directo por red al puerto del backend.

Evita usar el mismo dominio público del proxy como dirección de backend: eso puede crear un bucle. Usa una dirección concreta interna, privada o de otro modo habilitada específicamente para el proxy.

listeners: entradas públicas

host debe coincidir con la asignación de proxy correspondiente. priorities es la lista ordenada para el arranque y el fallback. Un error tipográfico como Lobby en lugar de lobby basta para que no se encuentre ningún destino predeterminado.

force_default_server: true hace que las conexiones nuevas pasen por la lógica de prioridades/forced-host. Con false, BungeeCord puede intentar restaurar un destino usado anteriormente.

max_players no es player_limit

listeners.*.max_players controla el número de jugadores que se muestra en la lista de servidores. player_limit es el límite global estricto. Configura ambos de forma consciente; una cifra bonita no sustituye una medición real de capacidad.

forced_hosts y DNS

forced_hosts asigna un nombre de host a un nombre de servidor interno. El DNS sigue apuntando a BungeeCord. Para dominio y puerto distinto, usa la guía de dominio/SRV.

No confundas estos campos

  • proxy_protocol es para un emisor previo de HAProxy/PROXY Protocol, no para el forwarding normal de BungeeCord.
  • query_enabled abre, si es necesario, un servicio UDP independiente; no lo actives por precaución.
  • ping_passthrough adopta el MOTD y el estado de un destino, pero hace más visible una caída del backend.
  • restricted es un permiso de BungeeCord, no un firewall.
  • /greload no aplica de forma fiable todos los cambios de plugins y permisos; prevé un reinicio.

Configurar el backend correctamente

Ajusta server.properties a online-mode=false y settings.bungeecord: true en spigot.yml. En Paper, proxies.bungee-cord.online-mode debe coincidir con el online_mode del proxy. Antes de hacer un cambio, lee la guía de forwarding seguro y crea una copia de seguridad probada mediante el proceso de copia/rollback descrito en la guía de cambio de versión.

Validación

  1. Usa solo espacios, nunca tabulaciones.
  2. Comprueba la indentación y las cadenas con caracteres especiales.
  3. Compara todos los nombres en priorities y forced_hosts con servers.
  4. Reinicia por completo el backend y el proxy.
  5. Prueba por separado TCP, el ping de Minecraft y una conexión real al lobby.
  6. Comprueba desde una fuente independiente que el puerto del backend está bloqueado.

Si BungeeCord no consigue alcanzar ningún lobby, te ayuda la guía de errores de fallback. Instala los plugins de proxy y backend en el nivel correcto solo después de superar esta prueba básica.

FAQ

¿Por qué no debería copiar el config.yml de un tutorial?

Porque los campos y los valores predeterminados cambian entre builds. Deja que BungeeCord genere el archivo con tu propia versión instalada y traslada solo los valores que realmente quieras ajustar. Un campo de un ejemplo antiguo puede faltar en tu build o tener un significado distinto.

¿Cuál es la diferencia entre max_players y player_limit?

listeners.*.max_players es puramente informativo: el número que ven los clientes en la lista de servidores. player_limit es el límite global estricto a partir del cual el proxy rechaza conexiones (0 o menos significa ilimitado). Configura ambos de forma consciente: una cifra alta no sustituye una medición real de capacidad.

¿Basta con restricted: true para proteger un backend?

No. restricted es un permiso de BungeeCord y exige bungeecord.server.<nombre> para cambiar a través del proxy. No impide que nadie acceda directamente al puerto del backend. Esa protección corresponde al firewall o a la red privada, no a la configuración del proxy.

¿Tengo que reiniciar tras un cambio, o basta con /greload?

Prevé un reinicio. /greload vuelve a leer la configuración, pero no traslada de forma fiable todos los cambios de plugins y permisos al estado en ejecución. Para cambios en listeners, servidores o forwarding, el reinicio completo es la única vía fiable.

¿Por qué no puede figurar el dominio del proxy como dirección de backend?

Porque entonces el proxy se apuntaría a sí mismo como destino y se crearía un bucle. En servers.<nombre>.address debe ir la dirección con la que el proceso del proxy alcanza el backend: una dirección interna o privada, no el nombre público al que apunta el DNS de tu red.

Fuentes primarias