Cómo elegir hosting para tu servidor de Minecraft: lo que importa

Elige hosting según tres cosas: lo rápido que es un solo núcleo de CPU, lo cerca que está la máquina de tus jugadores y si el proveedor te deja ejecutar lo que necesitas (tu propio jar de servidor, puertos extra, acceso completo a los archivos). La RAM solo importa hasta que caben tu mundo, tus plugins y tus jugadores, y para la mayoría de los servidores con plugins eso está entre 4 y 10 GB, no en los 32 GB que anuncian los planes grandes.

No vendemos hosting y esta página no lleva enlaces de afiliado. Sí tenemos un pinger que revisa cada servidor de la lista cada minuto, así que parte de esta guía sale de ver cómo se comportan los servidores en distintos tipos de hosting.

Qué limita de verdad a un servidor de Minecraft

Un servidor de Minecraft ejecuta el mundo en ticks, 20 por segundo, lo que da a cada tick un presupuesto de 50 milisegundos. En ese tiempo el servidor mueve todos los mobs cargados, ejecuta la redstone y los hoppers, hace crecer los cultivos, procesa todo lo que han hecho los jugadores y ejecuta el código de los plugins. Si un tick tarda más de 50 ms, el siguiente empieza tarde y todo el servidor lo nota.

El problema es que casi todo este trabajo se hace en orden, en un único hilo principal. Vanilla y Paper ya reparten la generación de chunks, la iluminación y la red entre otros hilos, pero las entidades, las actualizaciones de bloques, la redstone y la mayor parte de la lógica de los plugins corren en un solo núcleo por servidor. Para un único servidor de Minecraft, una CPU con 8 núcleos rápidos supera a una con 32 lentos. Folia es la excepción, porque divide el mundo en regiones que hacen tick en paralelo, y viene con grandes inconvenientes que nuestra guía de software para servidores explica.

El ancho de banda rara vez es el límite en un servidor pequeño: lo son la latencia y la pérdida de paquetes. Y cuando un plan dice "4 vCPU", pregunta qué significa: en muchas máquinas virtuales una vCPU es un solo hilo de hardware, a menudo en un núcleo que usan también otros clientes.

Cuánta RAM necesitas

No hay una cifra oficial, y las guías cuyas cifras van del simple al triple no tienen por qué estar equivocadas: simplemente imaginan servidores distintos. La memoria se llena con el mundo cargado (la distancia de visión multiplicada por lo dispersos que estén tus jugadores), las entidades, las cachés de los plugins (los renderizadores de mapas web y los plugins que registran bloques consumen mucho) y, sobre todo, los mods.

Estos son puntos de partida que le daríamos a un amigo, no mediciones:

Conviene conocer tres puntos de la documentación de PaperMC antes de elegir un plan (está en inglés, así que las citas son traducciones nuestras):

• Pon -Xms y -Xmx en el mismo valor. La memoria entre uno y otro es memoria que pagas y no usas.
• Deja entre 1.000 y 1.500 MB por encima de -Xmx para el proceso de Java y el sistema operativo, y, en palabras de la documentación, "no asignes toda la memoria disponible en un host compartido".
• Más no es siempre mejor. La misma página dice que comprar 32 GB para un servidor "solo malgastará tu dinero con beneficios mínimos", y recomienda "al menos 6-10 GB, por pocos jugadores que haya", porque sus ajustes de recolección de basura funcionan mejor con margen. Un servidor de amigos funciona con menos. Para un servidor público, apunta a esa cifra.

No juzgues la memoria por la barra de RAM del panel de tu hosting. Con -Xms igual a -Xmx, Java reserva toda la cantidad al arrancar, así que la barra parece llena desde el primer día. En su lugar, ejecuta /spark health y /spark gc (spark viene con Paper). Lo que importa es qué parte del heap sigue en uso justo después de una recolección y cuánto duran las pausas.

Hostings gratuitos: lo que ve nuestro pinger

Los hostings gratuitos mantienen bajos sus costes poniendo a dormir los servidores cuando no hay nadie conectado. Alguien tiene que volver a despertarlos, desde un panel web, un lobby o entrando y esperando. Para unos amigos es un buen trato. Para un servidor público significa que, la mayor parte del tiempo, quien comprueba tu dirección encuentra una página de espera en lugar de tu mundo.

Podemos medirlo porque nuestro pinger registra qué responde, no solo si algo responde. En los 30 días hasta el 16 de octubre de 2026, cinco fichas de nuestra lista usaban la dirección de un hosting gratuito que muestra una página de reposo (subdominios de Aternos y Falix). Nuestro pinger obtuvo alguna respuesta en el 66,5 % de sus intentos, pero detrás de esa respuesta había un servidor al que se podía entrar como mucho en el 5,6 %. Cuatro de las cinco fueron jugables cuatro horas o menos en todo el mes. En el mismo periodo, el resto de las fichas que fueron jugables al menos una vez tuvieron una mediana de uptime jugable del 98,9 %. En directo, para los últimos 30 días: 5 fichas en esas direcciones, que respondieron al 64,6 % de los pings.

6,2 %Uptime jugable de las fichas en hostings gratuitos con modo reposo, últimos 30 días

99,0 %Mediana del uptime jugable a 30 días del resto de fichas públicas que fueron jugables al menos una vez en el periodo, sin lobbies compartidos ni suplantaciones

Medido el 19 oct 2026, 23:25 UTCCómo medimos

Las respuestas que forman esa diferencia son las páginas de espera de los propios hostings, con primeras líneas como "This server is offline.", "Server is OFFLINE. Join to start it automatically!" o "Server not found." Una lista que solo comprueba si algo respondió daría esos servidores por activos. Nosotros los contamos como caídos, que es también como los trata nuestro informe de uptime.

Hosts gratuitos que duermen5 fichas

Todo lo demás207 fichas

• Nunca respondió
• Solo página de espera
• Menos del 50%
• 50 a 90%
• 90 a 99%
• 99 a 99,9%
• 99,9% o más

Los hosts gratuitos que responden con una página de reposo cuentan como respondidos pero no jugables, por eso están abajo del todo.

Medido el 19 oct 2026, 23:25 UTCCómo medimos

Minehut funciona de otra manera. Cuando un servidor de Minehut duerme, su dirección lleva al lobby propio de Minehut, así que un ping puede volver con miles de jugadores. El 18 de octubre de 2026, una dirección de Minehut de nuestra lista respondió con 4.759 jugadores y con un mensaje de que el servidor estaba apagado y se arrancaba desde el lobby con /join. Los jugadores eran reales, solo que estaban en el lobby. Por eso las direcciones de lobby compartido se dejan fuera de nuestros totales de network, como explica la metodología.

En serverlist.net el orden por defecto pone delante de los demás a los servidores que fueron jugables en las últimas 24 horas, y las páginas de espera no cuentan como jugables. Cómo conseguir tus primeros 100 jugadores explica qué ven los jugadores nuevos en sus primeros cinco minutos.

El hosting gratuito sigue siendo la opción correcta para probar plugins, aprender a llevar un servidor o para un grupo pequeño que arranca el servidor cuando queda para jugar. Si tu grupo no quiere nada de administración, Realms, el servicio de suscripción de Mojang para mundos privados, es la otra opción, sin plugins y sin ficha pública.

Hosting de juegos compartido, VPS o dedicado

El hosting de pago tiene cuatro formatos. La adecuada depende de cuánta máquina necesitas y de cuánto quieres gestionar tú.

Un camino habitual es el hosting de juegos compartido durante los primeros meses y una máquina dedicada cuando un perfil de spark muestra que el límite es la CPU (nuestra guía del lag enseña a leer uno).

Ubicación y ping

La luz en la fibra recorre unos 200.000 km por segundo, así que cada 1.000 km entre un jugador y tu servidor añade más o menos 10 ms al viaje de ida y vuelta, antes de que las rutas reales de cable añadan sus rodeos.

Nuestro pinger está en Europa occidental y registra la latencia mínima de cada servidor, el viaje de ida y vuelta más rápido de un periodo. Para los servidores jugables que declaran un solo país, las medianas entre las 21:00 UTC y la medianoche del 17 de octubre de 2026 fueron:

Valores en directo: Europa 10 ms, Norteamérica 78 ms, Asia 147 ms.

Pon la máquina donde esté la mayoría de tus jugadores en tus horas punta. Las estadísticas de tu ficha muestran de qué países vienen tus visitantes, y cuándo hay más gente en los servidores de Minecraft muestra cómo cambian las horas punta según la región. Los jugadores de PvP notan diferencias que los constructores de un SMP nunca notarán, así que cuanto más ajustado sea tu combate, más cerca debería estar el servidor. Si quieres atraer a jugadores de Europa y de Norteamérica a la vez, la costa este de Estados Unidos es el término medio habitual. Casi la mitad de los servidores norteamericanos de esa muestra (22 de 46) respondieron a nuestro pinger en 70 a 90 ms, más o menos lo que cuesta un viaje a través del Atlántico. Antes de pagar, haz ping a la dirección de prueba del proveedor desde donde viven tus jugadores, o pídeselo a tres de ellos.

Una trampa: 12 de esos 46 servidores norteamericanos respondieron a nuestro pinger europeo en menos de 15 ms. Están detrás de redes de protección que responden desde el nodo más cercano a quien pregunta, así que una prueba de ping mide ese nodo, no tu máquina. El trayecto desde ese nodo hasta tu servidor sigue ocurriendo en cada paquete.

Protección DDoS y proxies

Los servidores de Minecraft atraen ataques desproporcionados para su tamaño. Basta con un jugador baneado con ganas de venganza. La protección viene en tres capas, y conviene saber cuáles tienes antes del primer ataque.

1. El filtrado de red de tu hosting. Pregunta si está incluido y siempre activo, si entiende el tráfico de juegos o solo frena grandes inundaciones, y qué pasa durante un ataque grande: ¿se filtra, o se apaga tu IP unas horas (un null route)?
2. Un proxy de protección que entienda Minecraft. Los jugadores se conectan al nodo del proveedor, que pasa el tráfico limpio a tu servidor oculto. Entonces tu servidor necesita recuperar la IP real de cada jugador. Algunos proveedores traen su propio plugin para eso, y muchos usan el protocolo PROXY: haproxy-protocol = true en velocity.toml, o proxies.proxy-protocol: true en config/paper-global.yml de Paper cuando no hay Velocity. Actívalo solo cuando la protección esté de verdad delante, porque un servidor que espera cabeceras PROXY rechaza las conexiones normales.
3. Tu propia disciplina. Una IP oculta sigue oculta solo si nada más apunta a ella: un registro DNS antiguo, la dirección de Bedrock, el puerto de Votifier, una web en la misma máquina o un miembro del staff que pegó la IP numérica en Discord.

Comprueba Bedrock por separado. Geyser necesita su propio puerto, el 19132 por defecto, y la guía actual de redirección de puertos de GeyserMC pide que esté abierto tanto en TCP como en UDP. Algunos servicios de protección solo cubren el tráfico TCP de Java.

Preguntas que hacer a un hosting antes de pagar

1. ¿En qué modelo de CPU se ejecutará mi servidor, y sus núcleos son solo míos o compartidos? Busca el modelo en un benchmark público de rendimiento en un solo hilo.
2. ¿Qué tipo de almacenamiento ofrece? Los SSD NVMe mantienen rápidas la carga de chunks y los guardados.
3. ¿Qué ubicaciones puedo elegir, y hay una IP de prueba a la que hacer ping?
4. ¿Puedo conseguir puertos extra? NuVotifier necesita un puerto TCP (nuestra guía de NuVotifier), Geyser necesita el 19132 (nuestra guía de Geyser) y un mapa web también necesita uno.
5. ¿Tengo acceso completo a los archivos por SFTP, y puedo subir mi propio jar de servidor?
6. ¿Qué versiones de Java puedo elegir? Minecraft 26.1 y posteriores necesitan Java 25, según la tabla de requisitos de PaperMC.
7. ¿Cada cuánto se hacen copias de seguridad, dónde se guardan, cuánto tiempo se conservan y puedo restaurar una yo mismo?
8. ¿Qué filtra la protección DDoS, incluye UDP y qué pasa durante un ataque grande?
9. ¿Puedo pasar a un plan más grande sin migrar los archivos a mano?
10. ¿Cuál es el plazo de reembolso y qué pasa si el nodo en el que estoy se llena demasiado?
11. ¿Cuándo hay soporte disponible en mi zona horaria y con qué rapidez responde?

Un hosting que responde a la primera pregunta con "CPU de alto rendimiento" y nada más también te ha dicho algo.

Cambiar de hosting sin perder jugadores (registros DNS y SRV)

Los jugadores guardan tu dirección en su lista multijugador, así que la dirección debe ser tuya, no del hosting. Usa tu propio dominio desde el primer día y una mudanza se convierte en un cambio de DNS en lugar de una comunidad perdida.

1. Un día antes de la mudanza, baja el TTL de los registros DNS de tu servidor a 300 segundos, para que el cambio se propague en minutos cuando lo hagas.
2. Monta el servidor nuevo, copia los plugins y las configuraciones y pruébalo por su IP numérica.
3. Anuncia un corte breve. Para primero el servidor viejo y copia el mundo después, para que nadie siga jugando en una copia que vas a tirar. Desde Paper 26.1, el Nether y el End viven dentro de la carpeta world, en world/dimensions/. Las versiones anteriores de Paper los guardan al lado, como world_nether y world_the_end.
4. Arranca el servidor nuevo y apunta tu registro DNS hacia él.
5. Si puedes, conserva la máquina vieja un día o dos con un servidor minúsculo cuyo MOTD diga que te has mudado, para que los jugadores con una dirección antigua en caché vean un mensaje en vez de un timeout.
6. Si han cambiado el host o el puerto de Votifier, o la dirección de Bedrock, actualízalos en cada lista que uses. En serverlist.net eso está en tu panel, y el probador de Votifier confirma que los votos llegan.
7. Comprueba desde fuera con la herramienta de estado del servidor y vigila después la página pública de estadísticas de tu ficha: un escalón en el gráfico del tiempo de respuesta es la mudanza, y un hueco largo en el uptime significa que algo salió mal.

Si tu hosting te da un puerto distinto del 25565, un registro SRV permite que los jugadores de Java sigan escribiendo una dirección limpia. El nombre del registro es _minecraft._tcp. seguido de la dirección que escriben los jugadores:

_minecraft._tcp.play.example.com.  300  IN  SRV  0 5 25577 node7.example-host.net.

Los campos después de SRV son prioridad, peso, puerto y destino. El destino debe ser un nombre de host con su propio registro A, no una IP a secas. Si cambias de hosting, solo cambias esa línea y los jugadores nunca ven un puerto nuevo.

Dos límites. Bedrock ignora los registros SRV, así que los jugadores de Bedrock escriben ellos mismos el host y el puerto (19132, salvo que tu hosting haya asignado otro). Y si tu DNS está en Cloudflare, pon los registros de Minecraft en solo DNS, la nube gris: el proxy normal de Cloudflare transporta tráfico web, no conexiones de Minecraft.

Si la máquina nueva también va con lag, busca la causa antes de arreglarlo. Un plan más grande no cura una granja de hoppers.