BungeeCord y Velocity: crea una red de Minecraft

BoxToPlay-helper · July 28, 2026, 4:29pm

Este tutorial te guía desde la creación de los vínculos en el panel de BoxToPlay hasta las primeras transferencias dentro del juego. Elegirás el servidor de entrada, probarás los comandos, decidirás si algunos backends deben compartir sus inventarios, construirás un portal en el lobby y sabrás cuándo resulta útil repartir la carga.

Si todavía no has elegido un proxy, consulta nuestra comparativa entre BungeeCord y Velocity. También puedes consultar la documentación oficial de BungeeCord y Velocity.

El recorrido más corto es el siguiente:

Vincula cada servidor Minecraft con el proxy desde el panel.
Reinicia primero los servidores Minecraft afectados y después el proxy.
Conéctate con la dirección y el puerto del proxy.
Comprueba cada destino con /server.
Si varios backends deben compartir inventarios, configura una única solución de sincronización y guarda primero una copia de los datos de los jugadores.
Instala Advanced Portals en el lobby si quieres un portal dentro del juego.
Añade un plugin de reparto al proxy solo cuando varias instancias ofrezcan el mismo modo de juego.

Entender la función del proxy

BungeeCord y Velocity se colocan delante de tus servidores Minecraft. Los jugadores se conectan a una única dirección pública, la del proxy, que después los envía a uno de los servidores vinculados.

Jugador
  ↓
Dirección del proxy
  ↓
BungeeCord o Velocity
  ├── lobby
  ├── survival
  ├── creative
  └── minigames

En este tutorial:

Un backend es un servidor Minecraft situado detrás del proxy.
Un destino es el nombre de un vínculo, por ejemplo survival.
Una instancia es un servidor concreto entre varios que ofrecen el mismo modo de juego, por ejemplo survival-1.

Cada backend conserva sus propios mundos, plugins y datos. El proxy permite pasar de uno a otro, pero no sincroniza automáticamente los inventarios, la economía, los rangos, las sanciones ni el chat.

1. Completar la vinculación en BoxToPlay

Abre tu servidor BungeeCord o Velocity en el panel de BoxToPlay:

Haz clic en Enlaces del Servidor en el menú de la izquierda.
Haz clic en Enlazar un Servidor de Minecraft.
En Nombre del Servidor, escribe un identificador corto sin espacios, por ejemplo lobby o survival.
Deja BoxToPlay marcado si el servidor Minecraft pertenece a la misma cuenta y selecciónalo en Elección del Servidor.
Con BungeeCord, también puedes definir el MOTD asociado a esta entrada y activar Restringido para exigir el permiso bungeecord.server.nombre-del-servidor. Estos dos campos no están disponibles en el formulario de Velocity.
Haz clic en Validar.

Esta primera vista enumera los servidores que ya están vinculados. El botón Enlazar un Servidor de Minecraft abre la ventana siguiente.

El nombre del vínculo es un identificador técnico. Si eliges survival, escribe exactamente survival en los comandos, portales y plugins. No es el nombre del mundo, la dirección IP ni el puerto del servidor.

Servidor Minecraft alojado en BoxToPlay

Cuando el backend pertenece a la misma cuenta de BoxToPlay, el panel registra el destino en el proxy y prepara automáticamente los archivos compatibles del servidor Minecraft. En un backend Paper, Purpur o Spigot, esto incluye especialmente el cambio al modo offline y la activación del método de forwarding compatible con el proxy.

El modo offline es necesario porque ahora el proxy autentica al jugador. Sin embargo, hace peligroso cualquier acceso directo al backend: quien evite el proxy podría intentar suplantar a un jugador. Por tanto, los puertos de los backends solo deben ser accesibles desde el proxy y los servicios técnicos necesarios.

BungeeCord utiliza su forwarding histórico. Velocity puede utilizar el forwarding compatible con BungeeCord o el forwarding moderno de Velocity, con un secreto compartido. Paper admite este protocolo moderno en el backend. El secreto añade protección, pero no sustituye al filtrado de red.

BoxToPlay automatiza los ajustes que admite el software del backend. Un servidor Forge, NeoForge o Fabric puede necesitar un mod de compatibilidad adicional: el panel no cambia automáticamente su software ni instala ese mod.

Servidor Minecraft alojado en otro proveedor

Para un servidor externo, el panel registra el destino en el proxy, pero debes configurar manualmente el backend en el otro proveedor. Utiliza el mismo modo de forwarding en ambos lados, introduce el secreto de Velocity cuando sea necesario e impide el acceso directo al puerto del backend.

Aplicar los cambios

Después de añadir o modificar un vínculo:

Reinicia los backends afectados.
Reinicia BungeeCord o Velocity después.
Comprueba que todos los backends estén iniciados antes de la primera prueba.

Velocity ofrece /velocity reload para volver a leer velocity.toml, pero el proceso de vinculación de BoxToPlay puede modificar varios elementos. El reinicio completo sigue siendo el método esperado. Con BungeeCord, no confíes en /greload para aplicar de forma fiable un cambio importante.

2. Elegir el servidor de entrada

El servidor de entrada suele ser un lobby. Allí, los jugadores pueden leer la información de la red, elegir un modo de juego y utilizar un portal, un NPC o un menú.

Con BungeeCord

En la configuración del proxy de BoxToPlay, selecciona tu servidor predeterminado. Se convertirá en la primera prioridad de BungeeCord.

La opción Forzar el servidor predeterminado cambia el comportamiento al volver a conectarse:

Activada: el jugador siempre vuelve al servidor predeterminado.
Desactivada: BungeeCord puede intentar devolver al jugador a su último servidor conocido cuando está disponible.

Las prioridades definen un orden de intentos. Si el primer servidor no está disponible, BungeeCord puede probar el siguiente. No eligen un destino según el número de jugadores ni el consumo de recursos.

Con Velocity

Velocity utiliza una lista ordenada llamada try. El primer servidor disponible se convierte en el destino inicial. Los siguientes sirven como alternativas durante la conexión. También pueden recibir a un jugador después de una desconexión inesperada de un backend si está activada la opción failover-on-unexpected-server-disconnect.

En el panel de BoxToPlay, el servidor elegido como prioritario se coloca primero y los demás vínculos aparecen después. Velocity también sigue un orden. No selecciona de forma nativa el servidor con menos carga.

3. Probar las transferencias con comandos

Los comandos permiten validar la red antes de añadir un portal o un menú. Conéctate en el juego con la dirección y el puerto del proxy y utiliza:

/server

Este comando indica el servidor actual y ofrece los destinos disponibles. Para entrar en uno:

/server lobby
/server survival
/server minigames

Para consultar los jugadores conectados:

/glist

En Velocity, /glist exige velocity.command.glist y /glist all muestra los jugadores por servidor. En BungeeCord, /glist utiliza bungeecord.command.list.

Un miembro autorizado del equipo de administración puede mover a un jugador o a todos los jugadores:

/send Steve survival
/send all lobby

BungeeCord y Velocity también aceptan current para mover a todos los jugadores que están en el mismo backend que la persona que ejecuta el comando:

/send current lobby

current debe ejecutarlo un jugador conectado, porque la consola del proxy no tiene un servidor actual. Reserva bungeecord.command.send y velocity.command.send al equipo de administración. El comando /server es suficiente para la navegación normal de los jugadores.

4. Sincronizar inventarios entre varios servidores

BungeeCord y Velocity no transportan el inventario del jugador entre backends. Debes instalar una solución de sincronización en cada servidor que comparta la misma progresión.

Todos los planes de servidores Minecraft de BoxToPlay ya incluyen una base de datos MySQL sin coste adicional. Actívala desde la página Base de datos MySQL del panel eligiendo una contraseña de administrador y usa sus credenciales en la configuración siguiente. No necesitas añadir una base de datos externa.

Paper, Spigot, Purpur y Folia

MC-Data-Bridge es compatible con redes Minecraft 1.21.x, 26.1.x y 26.2. Instala el mismo archivo JAR en la carpeta plugins de cada backend correspondiente y también en el proxy BungeeCord o Velocity. Configura la misma base de datos MySQL o MariaDB en todas partes y asigna un server-id único a cada servidor.

Las versiones 2.1.3 a 2.1.8 de MC-Data-Bridge requieren Java 25, incluso con Minecraft 1.21.x. Las versiones 2.1.2 y anteriores funcionan con Java 21, pero no incluyen las últimas correcciones relacionadas con las transferencias y la protección contra la duplicación de objetos. Utiliza preferentemente la última versión estable compatible.

Si tu red debe permanecer en Java 21, MySql Player Bridge es otra posibilidad. Instala primero NBT-API y después coloca MySql Player Bridge en plugins en cada backend que quieras sincronizar. Configura la misma base de datos MySQL o MariaDB en plugins/MySqlPlayerBridge/mysql.yml y activa únicamente los datos necesarios en plugins/MySqlPlayerBridge/config.yml. No hace falta instalar ningún plugin adicional en el proxy.

Forge y NeoForge

Para Forge o NeoForge, PlayerSync ofrece archivos para varias combinaciones de Minecraft y loader. Elige siempre el archivo que corresponda exactamente a tu versión de Minecraft y a Forge o NeoForge. Colócalo en mods en cada backend, configura la misma base de datos MySQL o MariaDB en config/playersync.toml y asigna un Server_id diferente a cada servidor.

Utiliza el mismo modpack y las mismas versiones de los mods en todo el grupo sincronizado. Prueba los objetos añadidos por los mods antes de abrir la red.

¿Hay que sincronizar el lobby?

Para conservar el mismo inventario en el lobby y en el servidor PvP, ambos backends deben utilizar la misma solución y el mismo almacenamiento. En la mayoría de las redes es preferible mantener el lobby separado: su brújula, sus menús y sus objetos cosméticos no deben sustituir al inventario de PvP o Survival.

Por ejemplo, puedes mantener lobby independiente, sincronizar pvp-1 y pvp-2 entre sí y dejar survival en otro grupo.

Antes de activar la sincronización, guarda una copia de los datos de los jugadores y prueba varios cambios de servidor con una cuenta secundaria. Mantén la misma versión de Minecraft dentro de cada grupo y no combines varias soluciones de sincronización en un mismo grupo. Los rangos, las sanciones, la economía y el chat se comparten por separado con plugins diseñados para redes.

5. Crear un portal dentro del juego con Advanced Portals

El vínculo en el panel informa al proxy de que existe un destino. El comando /server survival pide después al proxy que transfiera allí al jugador. Un plugin instalado en el lobby puede activar el mismo traslado cuando un jugador entra en una zona.

Crear el vínculo no crea ningún portal físico. Un portal del Nether normal cambia de dimensión dentro del mismo backend: no envía al jugador a otro servidor.

Utilizaremos Advanced Portals, un plugin Bukkit compatible, entre otros, con Paper, Spigot, Purpur y Folia.

El método siguiente utiliza la etiqueta bungee:. Para este caso, instala el plugin en el backend que sirve de lobby, donde construirás el portal. No lo instales en el servidor de destino y los jugadores no necesitan añadir nada en sus ordenadores. Advanced Portals también ofrece un componente para el proxy destinado a la etiqueta proxy: y a funciones avanzadas, pero no es necesario para el portal sencillo de este tutorial.

Si el lobby solo utiliza Vanilla, Forge, NeoForge o Fabric, este plugin Bukkit no puede instalarse allí directamente. La sección dedicada a los servidores modificados explica qué opciones debes comprobar.

Instalar Advanced Portals en el lobby

En el panel de BoxToPlay:

Abre el servidor Minecraft utilizado como lobby.
Entra en Plugins y Mods y después en Instalación de plugins.
Abre la pestaña Modrinth.
Busca Advanced Portals.
Instala una versión compatible con tu versión de Minecraft.
Reinicia completamente el lobby.

Preparar Velocity

Si utilizas Velocity con la etiqueta bungee:, comprueba antes de crear el portal que bungee-plugin-message-channel esté activado en velocity.toml. Esta opción permite que los plugins de los backends utilicen el canal de mensajes compatible con BungeeCord. Es independiente del modo de forwarding de la información del jugador.

No permite que Velocity cargue directamente un plugin BungeeCord en el proxy.

Construir el portal hacia `survival`

Conéctate mediante el proxy y confirma primero que /server survival funciona. Después, desde el lobby con una cuenta administradora:

Construye el marco y deja vacío su interior.
Escribe /portal wand para recibir la herramienta de selección.
Haz clic izquierdo en una esquina interior y clic derecho en la esquina opuesta.
Crea el portal:

/portal create name:portal_survival bungee:survival triggerblock:NETHER_PORTAL

Escribe /portal portalblock y coloca los bloques recibidos dentro de la zona seleccionada.
Atraviesa el portal y comprueba que llegas al destino correcto.

En este comando:

name:portal_survival es el nombre único del portal.
bungee:survival pide al proxy que entre en el destino survival.
survival debe coincidir exactamente con el nombre de Enlaces del Servidor.
triggerblock:NETHER_PORTAL activa el traslado dentro de los bloques morados del portal.

El nombre histórico bungee: funciona con BungeeCord y Velocity cuando el canal compatible está activado. Utiliza /portal show para mostrar las zonas y /portal remove portal_survival para eliminar este ejemplo.

La siguiente captura, procedente de la documentación oficial de comandos de Advanced Portals, muestra el resultado de /portal show. Las partículas verdes delimitan los portales cercanos y la zona seleccionada actualmente. Permiten detectar con facilidad una selección demasiado grande, demasiado pequeña o desplazada.

Advanced Portals también permite crear destinos locales con los comandos /desti. El comando /desti show los representa mediante una flecha de partículas, como muestra la captura oficial siguiente.

Este segundo comando no es necesario para el portal de este tutorial: bungee:survival pide directamente al proxy que transfiera al jugador al servidor survival. Los comandos /desti solo se utilizan con portales que teletransportan a una posición local.

Puedes sustituir NETHER_PORTAL por WATER. Para un NPC o un menú, instala un plugin adecuado y configúralo con el mismo identificador de destino.

Este portal apunta a un destino fijo. No elige automáticamente entre survival-1 y survival-2.

6. Configurar el reparto de carga

Vincular lobby, survival y minigames reparte a los jugadores por actividad. No es un reparto de carga porque cada destino cumple una función diferente.

La necesidad aparece cuando varias instancias ofrecen el mismo modo Supervivencia:

survival-1: 78 jugadores
survival-2: 24 jugadores
survival-3: mantenimiento

Aquí, survival-1 es un identificador de destino, mientras que Supervivencia es el modo de juego ofrecido.

Un plugin de reparto instalado en el proxy puede elegir una instancia según las funciones que proporcione. Antes de elegirlo, comprueba que sepa gestionar:

La disponibilidad real de las instancias.
El número de jugadores y la capacidad máxima.
Las instancias en mantenimiento.
El comportamiento esperado cuando falla una instancia.
El destino que debe utilizarse después de una reconexión.

Principio general de configuración

Vincula cada instancia con un nombre distinto, por ejemplo survival-1, survival-2 y survival-3.
Prueba cada nombre con /server.
Instala un plugin compatible con tu proxy y tu versión.
Sigue su documentación para declarar las instancias y exponer su comando o destino de reparto.
Configura el portal, el NPC o el menú para llamar a esa función.
Prueba una instancia disponible, una instancia llena y una instancia detenida.

Los plugins de reparto no utilizan todos el mismo modelo de grupo, alias o comprobación de estado. No copies una configuración diseñada para otro plugin.

Advanced Portals no mide la carga. La etiqueta bungee:survival-1 siempre envía al jugador a ese destino concreto. Del mismo modo, priorities en BungeeCord y try en Velocity definen un orden de entrada o de respaldo: no alternan automáticamente a los jugadores ni seleccionan la instancia con menos carga.

Por último, varias instancias no se vuelven intercambiables por copiar un servidor. Los inventarios, permisos, monedas, sanciones y datos de plugins deben estar diseñados para funcionar en red, normalmente con plugins adecuados y una base de datos compartida.

7. Los subdominios no sustituyen a los portales

Una configuración avanzada puede asociar direcciones como survival.ejemplo.com o minigames.ejemplo.com con destinos iniciales diferentes. BungeeCord denomina a este mecanismo forced_hosts, mientras que Velocity ofrece una sección equivalente llamada forced-hosts.

Este enrutamiento se aplica cuando un jugador entra en la red. No mueve a un jugador que ya está conectado ni elige automáticamente la instancia con menos carga. Por tanto, los subdominios son un punto de entrada adicional, no un sustituto de los comandos, portales o menús.

Con BungeeCord, Forzar el servidor predeterminado debe permanecer desactivado para que los forced hosts seleccionen correctamente el destino inicial.

8. Proteger los servidores backend

Los jugadores deben entrar mediante el proxy. Los puertos de los backends no deben ofrecer un segundo punto de entrada público.

El forwarding moderno de Velocity comprueba un secreto compartido, pero no sustituye a un firewall. Con el forwarding histórico compatible con BungeeCord, las restricciones de red, una lista de IP autorizadas o BungeeGuard son especialmente importantes. En todos los casos, solo el proxy y los servicios técnicos necesarios deben poder acceder a los backends.

Comparte con los jugadores únicamente la dirección del proxy.

9. Casos especiales: Forge, NeoForge y Fabric

El recorrido más sencillo consiste en utilizar un lobby Paper o Purpur con Advanced Portals, aunque los destinos funcionen con Forge o NeoForge. Los jugadores seguirán necesitando la versión y el modpack exigidos por el destino.

Con Velocity 3.3.0 o una versión posterior:

La compatibilidad nativa con el protocolo Forge corresponde a versiones estrictamente posteriores a 1.20.2.
Para Forge 1.13 hasta 1.20.1, instala Ambassador en el proxy Velocity.
No supongas que Forge 1.20.2 está incluido en alguno de estos intervalos: comprueba la documentación y la versión exacta de tu servidor.

Para utilizar el forwarding moderno de Velocity hacia un backend Forge o NeoForge, instala una versión compatible de Proxy Compatible Forge en ese backend y utiliza el mismo secreto que el proxy. Para Fabric, la documentación de Velocity recomienda FabricProxy-Lite.

Ambassador gestiona la compatibilidad del protocolo Forge con Velocity. Proxy Compatible Forge y FabricProxy-Lite gestionan el forwarding de la información del jugador. Ninguno de estos componentes crea un portal.

Si el propio lobby utiliza Forge o NeoForge, busca un mod mantenido que proporcione explícitamente dos funciones para tu versión exacta: detectar una zona dentro del juego y enviar al jugador al nombre de un servidor BungeeCord o Velocity. En la fecha de redacción, no recomendamos una solución universal lista para usar en este caso. El proyecto forge-plugin-message anuncia varias versiones en su página, pero actualmente no ofrece ningún archivo público descargable en Modrinth. Por tanto, no puede servir como recomendación general en este tutorial.

Lista de comprobación

Antes de abrir la red:

La conexión a la dirección del proxy lleva al lobby esperado.
Cada nombre de Enlaces del Servidor funciona con /server nombre.
Los servidores BoxToPlay compatibles se han preparado automáticamente y los backends externos se han configurado manualmente.
Los backends se han reiniciado antes que el proxy.
Si se sincronizan inventarios, cada grupo utiliza una única solución, el mismo almacenamiento e identificadores de servidor distintos, después de guardar una copia de seguridad y probarlo con una cuenta secundaria.
El portal utiliza exactamente el mismo identificador de destino que el panel.
En Velocity, bungee-plugin-message-channel está activado antes de utilizar la etiqueta bungee:.
Un destino de respaldo funciona cuando un backend está detenido.
La conexión directa a la dirección y al puerto de un backend es rechazada.
Los permisos de /send, recarga y administración siguen reservados al equipo de administración.

¿Qué método debes elegir?

Para comprobar un vínculo: utiliza /server.
Para compartir inventarios entre varios backends: utiliza una solución compatible con su software, un almacenamiento común e identificadores de servidor distintos.
Para guiar a los jugadores desde un lobby: utiliza un portal, un NPC o un menú.
Para elegir un destino al conectarse: configura el servidor de entrada o subdominios avanzados.
Para repartir instancias equivalentes: añade al proxy un plugin de reparto compatible.

Una vez terminadas estas comprobaciones, el proxy se convierte en el único punto de entrada de la red. Entonces podrás mejorar el lobby, sincronizar únicamente los datos que deban compartirse y añadir un reparto de carga cuando varias instancias cumplan realmente la misma función.

Recursos útiles

BungeeCord

Velocity

Plugins y mods

¿Listo para crear el punto de entrada de tu red? Descubre los servidores BungeeCord y Velocity de BoxToPlay, enlaza tus servidores Minecraft desde el panel y valida después cada transferencia con este tutorial.