Alojamiento Velocity para redes de Minecraft

Un Paper bien ajustado aguanta bastante gente antes de que un proxy tenga sentido. Lo que empuja el proyecto hacia Velocity es la cantidad de procesos Java en paralelo, no el aforo.

La cuenta cambia cuando las instancias dejan de ser compatibles: versiones distintas, cargadores de mods distintos, ciclos de reinicio distintos. Nada de eso cabe en un solo servidor, y ahí es donde el proxy se paga.

Lo contrario vale igual de fuerte: el proxy es un servicio más que vigilar y el punto por el que pasa todo el mundo. Si tienes un servidor y solo quieres un mundo más, un plugin multimundo resuelve mejor.

Quien autentica al jugador contra Mojang es el proxy, así que los backends corren con online-mode apagado y se creen lo que él cuenta sobre quién ha llegado. En el forwarding heredado esa información viaja pegada al handshake, sin firma.

El modern forwarding cierra el hueco con un secreto compartido: Velocity firma los datos del jugador con el contenido de forwarding.secret y el backend rechaza la conexión si la firma no cuadra. En Paper, en paper-global.yml.

Dos detalles tumban a más gente que la teoría. El secreto tiene que coincidir byte a byte, y un salto de línea de más al final del archivo ya rechaza a todo el mundo. Y quien entra por el proxy recibe UUID online: activar el forwarding en un servidor antiguo obliga a migrar inventario y permisos.

Un backend con online-mode apagado acepta cualquier nombre. Si su puerto responde en internet, alguien conecta desde fuera diciendo que es el dueño y entra con todos los permisos. No es fallo de Velocity ni de BungeeCord: es el precio de delegar la autenticación y quedarse a medias.

La regla: solo el puerto del proxy queda público, el 25577 por defecto, y cada backend acepta conexión únicamente desde su IP. Con UFW es una regla por backend más la denegación por defecto de entrada. Después prueba desde otra red: si la conexión directa completa, la red está abierta.

Velocity no carga chunks, no simula entidades y no guarda mundo. Lee un paquete, decide el destino y lo vuelve a escribir, por jugador y en ambos sentidos. Subir el heap no cambia casi nada: lo que aprieta primero es la tasa de paquetes y el límite de conexiones abiertas.

Por eso una VPS pequeña sostiene el proxy mientras los backends viven en máquinas con holgura de CPU. Lo que no se puede ahorrar es distancia: cada salto entre los extremos entra en el ping, y con los dos en São Paulo esa capa desaparece de la cuenta.