Una network es varios servidores de Minecraft que se ven como uno solo: el jugador entra por una IP, aparece en un lobby y desde ahí pasa al survival, al skyblock o a los minijuegos sin desconectarse. Lo que hace posible ese truco es un proxy, y hoy el proxy que recomienda el propio equipo de Paper es Velocity. Esta guía monta una network desde cero con lo que de verdad hace falta, incluye los archivos de configuración completos y cubre lo que casi todas las guías en español se saltan: la seguridad de los backends, Geyser para que entren jugadores de Bedrock, backends con Forge o Fabric y los errores que vas a ver en la consola.

Todo lo técnico está comprobado contra la documentación oficial de Velocity, Paper y Geyser a octubre de 2026. Las versiones citadas (Minecraft 26.3, Velocity 4.2, Paper 26.3) son las actuales a esa fecha; la mecánica es la misma para versiones anteriores salvo donde se indica.

¿Necesitas una network?

No siempre. Si tienes un survival y quieres añadir un mundo creativo, un plugin de multimundo en un solo servidor te resuelve la vida sin proxy. La network compensa cuando:

Las modalidades son incompatibles entre sí (un survival con plugins y un modpack de Forge, por ejemplo).
Una modalidad tiene tanto tráfico que arrastraría el TPS de las demás si compartieran proceso.
Quieres reiniciar o caer una modalidad sin tirar a todos los jugadores.
Tienes gente suficiente para llenar más de un servidor a la vez.

Si estás empezando con diez amigos, no la necesitas todavía. Si ya tienes 40-50 personas conectadas y dos modalidades que no caben en un proceso, sí.

Cómo funciona por dentro

El proxy escucha en el puerto público (el que repartes a los jugadores) y, cuando alguien se conecta, lo autentica con Mojang y lo envía al servidor que toque. Los servidores de atrás (los backends) no hablan con el jugador directamente: hablan con el proxy. Eso tiene una consecuencia de seguridad enorme que vamos a resolver en el paso 4: los backends tienen que arrancar con online-mode=false y, si están expuestos a internet, cualquiera podría entrar con el nombre de otro jugador.

Velocity frente a BungeeCord: Paper recomienda Velocity sobre BungeeCord y Waterfall (que ya no se desarrolla). La diferencia que importa es que Velocity tiene reenvío de información del jugador seguro ("modern forwarding"), consume menos recursos y es el proxy que recibe el desarrollo. BungeeCord sigue funcionando y sus plugins no corren en Velocity, así que si dependes de un plugin solo-Bungee puede ser motivo para quedarte; si empiezas de cero, Velocity.

Lo que vas a necesitar

Un servidor para el proxy. Velocity es ligero: la documentación oficial arranca con 1 GB de RAM y para cientos de jugadores sobra. Necesita Java 25 (Velocity 4.x).
Un servidor por modalidad. Lobby, survival, minijuegos… cada uno con su RAM según lo que corra. El lobby es pequeño (2-4 GB suelen sobrar); el survival o el modpack, lo que les toque. Usa la calculadora de RAM por servidor, no para la suma.
Las IPs y puertos de cada backend. En un hosting con panel, cada servidor tiene su IP:puerto; apúntalos.

En TaroHosting cada pieza es un servidor del panel (Velocity está como tipo de servidor instalable), con su consola, sus backups y su Anti-DDoS. No hace falta un VPS: en VPS o hosting explicamos cuándo compensa cada camino.

Paso 1: prepara los backends con Paper

En cada servidor de modalidad instala Paper (o Purpur) de la misma versión que vayan a usar tus jugadores. Arráncalos una vez para que generen sus archivos y luego, en cada uno:

En server.properties pon online-mode=false. Es obligatorio: el proxy será quien autentique a los jugadores, no el backend.
En spigot.yml deja settings.bungeecord: false. Con Velocity y reenvío moderno tiene que estar en false.
Anota el puerto de cada backend. Si en el mismo panel el proxy y los backends comparten máquina y el host lo permite, poner server-ip=127.0.0.1 en los backends los esconde de internet; en un hosting con varios nodos no siempre es posible, y lo resolvemos en el paso 4.

Paso 2: instala Velocity y genera la configuración

En el servidor del proxy, con el jar de Velocity (desde papermc.io) y Java 25, arranca una vez. El primer arranque crea dos cosas: velocity.toml y forwarding.secret, un archivo con una clave aleatoria que vas a copiar a cada backend. Detén el proxy con end y edita velocity.toml. Esta es una configuración mínima real para un lobby, un survival y unos minijuegos:

bind = "0.0.0.0:25565"
motd = "<#09add3>Mi network</#09add3>"
show-max-players = 500
online-mode = true
force-key-authentication = true
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"

[servers]
lobby = "IP_DEL_LOBBY:PUERTO"
survival = "IP_DEL_SURVIVAL:PUERTO"
minijuegos = "IP_DE_MINIJUEGOS:PUERTO"
try = [ "lobby" ]

[forced-hosts]
"survival.tunetwork.com" = [ "survival" ]

Lo que significa cada línea:

bind: puerto público del proxy. En un panel será el puerto que te asignaron, no necesariamente 25565.
motd: el mensaje de la lista de servidores, en formato MiniMessage (no los códigos &a clásicos). Nuestro editor de MOTD te ayuda a diseñarlo.
show-max-players: solo decorativo; Velocity no limita jugadores por aquí.
online-mode = true: el proxy autentica con Mojang. Si tu network es no premium, aquí es donde se cambia (y solo aquí).
player-info-forwarding-mode = "modern": el modo recomendado por la documentación para Minecraft 1.13 o superior. legacy existe por compatibilidad con 1.12 y la documentación lo describe como inseguro por diseño; bungeeguard es legacy con un token para hosts compartidos.
[servers]: cada backend con su IP y puerto. try es el orden en que el proxy intenta meter al jugador al entrar y cuando lo expulsan de un servidor.
[forced-hosts]: opcional; permite que survival.tunetwork.com mande directo al survival.

Paso 3: activa el reenvío moderno en cada backend

Copia el contenido de forwarding.secret del proxy. En cada backend abre config/paper-global.yml y rellena el bloque de Velocity:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "PEGA_AQUI_LA_CLAVE_DE_forwarding.secret"

Tres detalles que la documentación remarca: online-mode en este bloque debe coincidir con el online-mode del proxy (si el proxy es premium, aquí true); el secret tiene que ser idéntico en todos los backends y en el proxy; y en Paper 1.18.2 o inferior estas opciones vivían en paper.yml bajo settings.velocity-support. Reinicia los backends y luego arranca el proxy.

Prueba: entra por la IP del proxy. Deberías aparecer en el lobby y ver en la consola del lobby tu nombre con tu UUID real (no uno "offline"). Para moverte, /server survival.

Paso 4: cierra los backends (esto no es opcional)

La propia documentación de Velocity lo dice: con los backends en online-mode=false, en teoría alguien que conozca su IP y puerto podría entrar suplantando a cualquier jugador, y el reenvío moderno no sustituye a un cortafuegos. Las opciones, de más a menos segura:

Cortafuegos: que el puerto de cada backend solo acepte conexiones desde la IP del proxy. En un VPS es una regla de iptables o ufw; en un hosting con panel, pregunta a soporte si pueden limitar el puerto del backend a la IP del proxy.
Misma máquina: si proxy y backends comparten servidor físico, server-ip=127.0.0.1 en cada backend y las direcciones 127.0.0.1:puerto en velocity.toml. Así los backends no escuchan en internet.
Plugin de guardia (del tipo BungeeGuard, o el modo bungeeguard de Velocity): mejor que nada, pero la guía de seguridad de Spigot lo deja claro: no es tan seguro como un cortafuegos.

Hazlo antes de abrir la network al público, no después del primer susto.

Paso 5: permisos y datos compartidos

Cada backend tiene sus propios plugins. Lo que suele querer una network es que rangos y permisos sean los mismos en todos: LuckPerms lo resuelve si todas sus instancias (una por backend y, opcionalmente, una en el proxy) apuntan a la misma base de datos MySQL o MariaDB, no a los archivos locales. En la config de LuckPerms de cada servidor: storage-method: mysql con las mismas credenciales, messaging-service: pluginmsg si hay un solo proxy, y un nombre distinto en server por instancia para poder dar permisos "solo en el survival". Instalar LuckPerms en el proxy sirve para los comandos de plugins del proxy; los permisos del juego los siguen comprobando los backends, así que ahí va siempre.

Economía, inventarios y estadísticas compartidas son otra historia: necesitan plugins pensados para red (con base de datos central) y es donde las networks grandes invierten más tiempo. Empieza con permisos compartidos; lo demás, cuando la comunidad lo pida.

Paso 6: jugadores de Bedrock en la network (Geyser en el proxy)

La documentación de Geyser es tajante: en una network, Geyser se instala solo en el proxy, no en los backends. Pon Geyser-Velocity.jar y Floodgate-Velocity.jar en la carpeta plugins/ del proxy, arranca, y en plugins/Geyser-Velocity/config.yml deja auth-type: floodgate para que los jugadores de Bedrock entren sin cuenta Java. Geyser escucha en el puerto 19132 (configurable) y lo usa tanto por UDP como por TCP, así que ese puerto tiene que estar abierto en los dos protocolos y no puede ser el mismo que el del proxy.

Dos avisos de la documentación: Geyser se presenta ante la network como un cliente Java de la versión más nueva que soporta (hoy, 26.3), así que todos los backends tienen que aceptar esa versión; si alguno va en una versión anterior, instala ViaVersion en ese backend. Y si quieres usar la API de Floodgate en un backend (por ejemplo para que un plugin distinga a los jugadores de Bedrock), instala Floodgate también ahí, activa send-floodgate-data: true en la config de Floodgate del proxy y copia el key.pem del proxy a la carpeta de Floodgate de ese backend. Esa clave no se comparte con nadie.

Si es tu primera vez con Geyser, la guía de crossplay Java + Bedrock explica la parte de un solo servidor, y la de "Outdated Geyser proxy", el error más común tras cada actualización del juego.

Paso 7: versiones distintas en la misma network

Si el survival va en 26.3 y los minijuegos siguen en una versión anterior por sus plugins, los jugadores no podrían saltar de uno a otro. ViaVersion resuelve eso y se puede instalar en el proxy o en los backends; la documentación dice que basta con uno de los dos sitios, y avisa de que instalado en el proxy el anticheat de los backends puede funcionar peor. ViaBackwards deja entrar clientes más viejos que el servidor; ViaRewind, clientes 1.7 y 1.8.

Paso 8: backends con Forge, NeoForge o Fabric

Un backend con mods necesita entender el reenvío moderno, y los cargadores no lo traen de serie. En Fabric se instala FabricProxy-Lite (Fabric no tiene mod soportado para reenvío legacy, así que el modo tiene que ser modern); en Forge 1.14 o superior, ProxyCompatibleForge. Además, los servidores con modpacks tardan en responder al proxy durante el arranque y en los cambios de mundo, y Velocity los desconecta por tiempo de espera: la FAQ oficial recomienda subir read-timeout en la sección [advanced] de velocity.toml y, en el backend, el argumento -Dfml.readTimeout al mismo valor en segundos (por ejemplo read-timeout = 120000 y -Dfml.readTimeout=120).

Recuerda que los jugadores del backend con mods necesitan esos mods en su launcher, así que el lobby debe avisarles antes de mandarlos.

Errores que vas a ver y qué significan

"If you wish to use IP forwarding, please enable it in your Bungeecord config as well!": el backend espera reenvío y el proxy no lo manda, o los modos no coinciden. Revisa player-info-forwarding-mode y el bloque de Paper.
"This server requires you to connect with Velocity.": el backend tiene el reenvío moderno activado pero el jugador llegó sin pasar por Velocity (o Velocity no está en modo modern). Si te sale al entrar directo al backend, enhorabuena: significa que la puerta de atrás no está abierta del todo.
"Failed to verify username" al entrar por el proxy: un backend sigue con online-mode=true.
Jugadores con UUID offline o skins vacías: el reenvío no está funcionando; el secret no coincide o enabled sigue en false.
Desconexión al entrar al modpack (read timed out): sube read-timeout y -Dfml.readTimeout como en el paso 8.
Los de Bedrock ven "Outdated server" o "Outdated client": versión de Geyser frente a versión del juego; actualiza el que vaya atrás (guía enlazada arriba).

Cuánta RAM pide cada pieza

Proxy: 1 GB es el punto de partida de la documentación; con Geyser y ViaVersion encima, 2 GB van holgados para una network mediana.
Lobby: 2-4 GB; no genera terreno y tiene pocos jugadores a la vez.
Survival con plugins: 6-8 GB para 30-60 jugadores.
Modpack: lo que pida el pack, normalmente 8-16 GB.

Lo que de verdad limita una network no es la RAM sino la CPU por núcleo de cada backend: si los tres servidores comparten un nodo sobrevendido, bajan de TPS a la vez. Es lo que explicamos en qué causa el lag de verdad.

Lista de comprobación final

Backends: online-mode=false, bungeecord: false, bloque velocity en paper-global.yml con el mismo secret.
Proxy: modern, [servers] con IP:puerto correctos, try apuntando al lobby.
Backends inaccesibles desde internet salvo para el proxy (cortafuegos o 127.0.0.1).
LuckPerms con base de datos compartida.
Geyser y Floodgate solo en el proxy; puerto 19132 abierto en UDP y TCP.
Backups programados en cada backend, no solo en el survival.

Una network es el proyecto donde más se agradece tener a alguien que ya la haya montado. Si contratas los servidores con nosotros, el soporte te ayuda por Discord a dejar el proxy y el reenvío funcionando y a revisar que los backends no queden expuestos; es parte del servicio, no un extra. Y si ya tienes la network en otro sitio, la migración se hace servidor por servidor, el proxy al final.

Cómo crear una network de Minecraft con Velocity (lobby + modalidades)