Montar un servidor de Minecraft merece la pena cuando quieres controlar quién entra, qué versión usáis y cuánta estabilidad estás dispuesto a pagar con tiempo o dinero. La parte de cómo hacer un servidor de Minecraft no va de clicar un botón, sino de elegir bien la base para no pelearte luego con el rendimiento o con la red.
En esta guía voy a ir a lo práctico: qué tipo de servidor te conviene, cómo arrancarlo paso a paso, qué tocar en la configuración, cómo abrirlo a Internet sin líos y cuándo compensa dejar de usar tu propio ordenador. También te diré en qué se suele equivocar la gente, que es donde más tiempo se pierde.
Lo esencial para no empezar por el lado equivocado
- Este artículo está pensado para Minecraft Java Edition; si buscas Bedrock, la ruta cambia bastante.
- Para pocos amigos, Paper suele dar mejor equilibrio entre rendimiento y flexibilidad que un servidor puro.
- Como referencia rápida, 2-4 GB de RAM sirven para un grupo pequeño; con plugins o mods, sube a 4-8 GB o más.
- Si vas a exponerlo a Internet, el puerto habitual es 25565/TCP y conviene usar whitelist.
- Si tu conexión usa CGNAT, alojarlo en casa puede complicarse más de lo que parece.
Lo que conviene decidir antes de montar nada
Yo siempre empiezo por la edición y por el tipo de servidor, porque aquí se decide casi todo. Este tutorial está pensado para Java Edition; si querías jugar desde móvil, consola o con Bedrock, la arquitectura cambia y no basta con seguir estos pasos tal cual.
- Vanilla si quieres la experiencia más limpia, sin capas extra ni dependencias.
- Paper si buscas mejor rendimiento y quieres usar plugins sin complicarte demasiado.
- Forge o Fabric si lo que te interesa de verdad son mods y packs completos.
Si no sabes cuál elegir, yo empezaría por Paper para un grupo pequeño o mediano. Va fino, tiene buena documentación y te deja crecer sin rehacerlo todo desde cero. Lo importante es no mezclar mods y plugins a ciegas: cada enfoque tiene su lógica y su coste. Con la base clara, el siguiente filtro es el hardware y la conexión, porque ahí se decide cuánta gente aguantará sin lag.
Requisitos reales que importan más que la marca del PC
Cuando alguien pregunta por cómo montar un servidor, casi siempre mira primero el procesador o la RAM. Yo miraría cuatro cosas: memoria, CPU, SSD y subida real de Internet. El resto importa, pero menos de lo que suele creerse.
| Escenario | RAM orientativa | CPU | Disco | Subida real |
|---|---|---|---|---|
| 2-4 jugadores vanilla | 2-4 GB | 1 núcleo moderno potente | SSD | 5 Mbps |
| 5-10 jugadores o algunos plugins | 4-6 GB | Alta frecuencia mejor que muchos núcleos lentos | SSD o NVMe | 10 Mbps |
| Modpacks o mundo grande | 8-12 GB o más | CPU fuerte y estable | NVMe preferible | 20 Mbps o más |
La CPU manda más de lo que parece, porque Minecraft suele castigar bastante el rendimiento por núcleo. Y el SSD cambia la sensación del servidor más de lo que muchos esperan: menos pausas al cargar chunks, menos tirones al guardar el mundo y menos sufrimiento cuando se reinicia. Si vas a usar tu propio ordenador, yo no le daría todo el margen de RAM al servidor; deja siempre 1-2 GB para el sistema y para no convertir tu PC en una tostadora lenta. Con la base física resuelta, ya podemos pasar a la instalación real.
Montarlo paso a paso sin perder tiempo
La instalación no es difícil si respetas el orden. Primero descargas el archivo del servidor, luego lo arrancas una vez, aceptas la licencia y después ajustas la configuración. La ayuda oficial de Minecraft insiste precisamente en esos dos puntos que tanta gente se salta: iniciar el .jar desde la carpeta correcta y cambiar el eula.txt a true antes del arranque válido.
- Crea una carpeta limpia solo para el servidor, por ejemplo
minecraft-server. - Descarga el archivo del servidor que vayas a usar y colócalo dentro de esa carpeta.
- Abre una terminal o consola en esa ubicación.
- Arráncalo por primera vez con un comando simple.
java -jar server.jar nogui- Cuando se detenga, abre
eula.txty cambiaeula=falseporeula=true. - Vuelve a iniciarlo y deja que genere el resto de archivos, incluido
server.properties. - Si quieres evitar escribir el comando cada vez, crea un
start.baten Windows o unstart.shen Linux.
Si usas Paper, cambia server.jar por paper.jar. La lógica es la misma. Y si el comando se cierra al instante, casi siempre el problema es Java mal instalado, una ruta equivocada o un nombre de archivo que no coincide. Yo también suelo empezar sin flags raras en JVM modernas y solo añado memoria cuando realmente hace falta. Una vez que el servidor arranca, toca abrirlo a amigos sin crear un agujero de red.

Abre el servidor al exterior sin romper la red
Si solo vais a jugar en casa, no abras nada: usa la opción de LAN y ahórrate el lío del router. En cambio, si quieres que entren desde fuera, el camino correcto es bastante más simple de lo que parece, pero hay que hacerlo con orden.
- Reserva una IP local fija para el ordenador o haz una reserva DHCP en el router.
- Redirige el puerto 25565/TCP hacia esa IP local.
- Abre ese mismo puerto en el cortafuegos del sistema.
- Comparte con tus amigos tu IP pública o usa un DNS dinámico si cambia a menudo.
- Si tu operador usa CGNAT, el redireccionamiento no bastará y tendrás que pedir IP pública o mover el servidor a un VPS o hosting.
Yo no abriría el puerto hasta tener la IP local fijada. Ese detalle pequeño evita que, tras un reinicio del router, el servidor deje de responder sin que entiendas por qué. También conviene no publicar un servidor público sin más: si lo vas a enseñar a gente que no conoces, deja activa la whitelist y revisa quién tiene permisos de operador. Cuando la puerta de entrada ya funciona, lo que marca la diferencia es la configuración interna.
Afinar la configuración para que vaya fluido
El archivo server.properties es donde un servidor pasa de “funciona” a “se siente cómodo”. No hace falta tocarlo todo; de hecho, yo recomiendo cambiar solo lo que realmente influye en estabilidad, seguridad y rendimiento.
| Ajuste | Qué hace | Recomendación inicial |
|---|---|---|
online-mode |
Verifica cuentas | true salvo casos muy concretos |
white-list |
Limita el acceso | true en servidores privados |
view-distance |
Chunks visibles para cada jugador | 6-8 si el servidor va justo |
simulation-distance |
Chunks que el servidor procesa de verdad | 4-6 para ahorrar CPU |
max-players |
Límite visible de usuarios | Ajusta según RAM y CPU reales |
difficulty |
Dificultad del mundo | normal o hard |
Yo tocaría primero view-distance y simulation-distance; ahí suele haber más margen del que la gente imagina. Bajar de 10 a 6 o 8 en visión y de 10 a 4 o 6 en simulación quita carga de forma bastante limpia. online-mode=true debería quedarse activado en casi todos los casos, porque es la barrera básica contra accesos no deseados. Y si notas que un amigo no entra, antes de culpar al router revisa la versión: la propia dinámica multijugador de Minecraft castiga mucho cuando servidor y cliente no van alineados. Con el servidor afinado, la siguiente decisión es dónde alojarlo si no quieres depender de tu propio PC.
Dónde alojarlo si no quieres depender de tu ordenador
Si piensas dejarlo encendido muchas horas, vale la pena comparar las opciones con números. Los precios de debajo son orientativos, pero sirven para entender qué compras en cada caso.
| Opción | Coste orientativo | Ventaja principal | Peor punto | La elegiría si... |
|---|---|---|---|---|
| PC de casa | 0 € extra, salvo electricidad | Control total | Dependes de tu red y del encendido | Estás probando o sois pocos |
| VPS | 5-15 €/mes | IP pública y servicio 24/7 | Requiere tocar Linux y administrar mejor | Quieres estabilidad y aprender |
| Hosting especializado | 8-25 €/mes | Panel sencillo y soporte | Menos control por euro invertido | Prefieres comodidad |
| Realm | Cuota fija mensual | La vía más simple | Menos flexible para personalizar | Solo quieres entrar y jugar |
Mi regla es simple: si vas a montar algo pequeño para aprender, el ordenador de casa vale. Si quieres estabilidad de verdad, un VPS compensa muy rápido. Y si tu prioridad es no tocar consola, firewall ni mantenimiento técnico, un hosting específico te ahorra tiempo a cambio de pagar más por la comodidad. Para grupos muy pequeños, una solución cerrada como Realm también cumple, pero no es la mejor si piensas meter plugins o ir afinando el servidor con el tiempo. Con el alojamiento resuelto, solo queda cerrar los detalles que separan un servidor jugable de uno que se convierte en problema.
Lo que yo dejaría cerrado antes de invitar a la primera partida
Antes de pasar la IP al grupo, yo dejaría tres frentes bien atados: copias de seguridad, acceso y prueba real. Es la parte menos emocionante, pero también la que te ahorra la mayoría de disgustos.
- Backup automático de la carpeta del mundo antes de cada actualización importante.
- Whitelist activada si no quieres que entren jugadores por accidente.
- Prueba de carga con una o dos personas antes de abrirlo al grupo entero.
- Plugins mínimos al principio: cada uno añade mantenimiento y posibles fallos.
- Control de recursos para vigilar RAM, CPU y lag de chunks tras cada cambio.
Yo prefiero este enfoque porque convierte el servidor en algo estable desde el principio, no en un experimento que se rompe a la primera actualización. Si haces bien la elección de edición, el arranque, la red y la configuración, ya tienes la parte difícil resuelta; lo demás es mantener el equilibrio entre comodidad y control.