El servidor de Palworld se cae una y otra vez: cómo diagnosticarlo y solucionarlo

La versión corta

Palworld tiene una fuga de memoria de larga data en su compilación de servidor dedicado. El uso de RAM sube de forma constante mientras el servidor está en marcha, aproximadamente en proporción a cuántos jugadores hay conectados y cuántos Pals existen en el mundo, y nunca se libera. Al final el proceso agota la RAM asignada y el sistema operativo lo mata. Desde fuera parece una caída aleatoria, y por eso tanta gente culpa primero a su proveedor.

Los operadores de servidores describen su forma de manera uniforme: un mundo de cuatro jugadores con unos 80 Pals suele pasar de unos 3 GB a más de 8 GB en cuatro horas, y un servidor de comunidad concurrido de 16 jugadores puede llegar a 12 GB en media hora. Esas cifras varían según tu mundo, pero el patrón no. Si tus caídas llegan según un calendario aproximado y no al azar, es la fuga.

Los dos fallos que no parecen una caída

Un fallo es el caso fácil: el proceso muere y cualquier cosa que lo vigile se entera. Los dos fallos que generan más tickets de soporte confusos dejan el proceso vivo y todas las comprobaciones de estado en verde. Diagnosticamos ambos a partir de 22 horas de muestras de un minuto del servidor de 16GB de un cliente, y se ven así:

Ninguno de estos es la fuga de memoria. El fallo de descarga del mundo ocurrió tres veces en dos horas en un servidor que usaba menos de 2.3GB, así que no es la fuga ni el límite de RAM. Lo que los hace costosos es que la comprobación de estado habitual, si el proceso del juego está en ejecución, pasa en ambos estados, por lo que nada reinicia el servidor y puede quedarse muerto durante horas mientras duermes.

Confirma que es la memoria antes de cambiar nada

Abre el gráfico de recursos en tu panel y observa la RAM a lo largo de una sesión. La fuga de memoria tiene una firma difícil de confundir:

• La RAM sube casi en línea recta desde el momento en que arranca el servidor y nunca baja cuando los jugadores se van.
• La caída ocurre cuando esa línea llega al techo de tu plan, no en un evento concreto del juego.
• No hay ningún mensaje de error útil. El proceso simplemente desaparece, porque el sistema operativo lo mató en lugar de que el juego decidiera salir.
• Reiniciar el servidor lo soluciona por completo, durante unas horas más.

Si en cambio tu servidor muere exactamente en el mismo momento siempre, o falla a los pocos segundos de arrancar, salta a la última sección. Son problemas distintos con soluciones distintas.

Solución 1: reiniciar según un horario

Esta es la respuesta poco glamurosa y también la eficaz. Como la fuga es lineal y un reinicio la borra por completo, un reinicio programado reinicia el reloj antes de llegar al techo. Los operadores con experiencia suelen reiniciar cada tres a seis horas en un servidor público concurrido, y una o dos veces al día en uno privado pequeño.

Un reinicio de Palworld tarda aproximadamente un minuto y el mundo se guarda antes, así que el coste para los jugadores es pequeño. Elige un hueco en el que tu grupo suela estar desconectado, anúncialo en Discord y el problema deja de serlo. En Flux puedes reiniciar desde el panel con un clic y, como un reinicio también aplica cualquier actualización pendiente del juego, sirve además como tu rutina de parches.

Una trampa que conviene conocer si lo alojas tú mismo o usas otro proveedor: el script de reinicio programado de la imagen estándar del servidor de Palworld pide al servidor que guarde primero y se niega a apagar si ese guardado falla. En un servidor con fugas, congelado o sin mundo, es decir, el único tipo de servidor para el que existe un reinicio nocturno, el guardado es justo lo que falla. Así que el reinicio no hace nada en silencio precisamente las noches en que hacía falta, y los registros lo muestran como ejecutado. Comprueba que el tuyo realmente se reinició en lugar de dar por hecho que lo hizo.

Solución 2: desactivar a los Pals invasores

Los asaltos generan oleadas de Pals hostiles que el servidor mantiene en memoria mucho después de que termine el asalto. Desactivarlos es lo más parecido que tiene Palworld a una solución acordada por la comunidad para la fuga, y los operadores informan sistemáticamente de que después la RAM sube a más o menos la mitad de velocidad.

En PalWorldSettings.ini pon bEnableInvaderEnemy=False y reinicia. Pierdes los asaltos a las bases, que algunos grupos echarán de menos y muchos no, y a cambio duplicas aproximadamente el tiempo entre reinicios. Edita el archivo desde el editor de configuración del panel; no hace falta abrir un terminal.

Solución 3: limitar lo que crece

La fuga crece en proporción a la cantidad de mundo que hay que mantener en memoria, así que limitar lo que pueden crear tus jugadores la ralentiza. Dos ajustes hacen la mayor parte del trabajo:

Un gremio que ha dejado 50 Pals trabajadores en cada una de varias bases mantiene una gran cantidad de simulación persistente en RAM, y cada uno de esos Pals contribuye a la fuga. Limitar el número de trabajadores no es solo una solución de memoria: es la palanca más importante sobre la carga de CPU del servidor en Palworld, así que normalmente mejora también el lag.

Solución 4: dale margen

Nada de lo anterior detiene la fuga, solo la ralentiza. La variable restante es cuánto margen tiene el servidor antes de llegar al techo, y eso es el tamaño de tu plan. Si ejecutas 16 jugadores con 8 GB, estás pidiendo a la fuga que acabe contigo en menos de una hora por bien que configures el mundo.

Esos niveles ya dan por hecho un servidor con fuga y no uno inactivo teórico. Si te caes en el nivel que corresponde a tu número de jugadores, la causa habitual es un mundo muy construido, y los dos ajustes de arriba te ayudarán más que el plan siguiente. Si estás un nivel por debajo de tu número de jugadores, sube. Escalar la RAM en Flux no toca el guardado de tu mundo.

Cómo mantener un servidor de Palworld en línea 24/7

Todo lo anterior ralentiza los fallos. Nada de ello hace que vuelva un servidor que ya ha fallado, y esa es la diferencia entre un servidor que está activo casi todo el tiempo y uno que está activo todo el tiempo. Algo tiene que darse cuenta y actuar mientras duermes.

Ese es el hueco que cierra nuestra imagen del servidor de Palworld, y por eso construimos la nuestra en lugar de usar la estándar. Comprueba el servidor cada minuto, desde dentro del contenedor, en lo que un jugador realmente notaría: si el socket de red se está vaciando, si la API de administración responde, si el mundo está cargado y en marcha y si el archivo de guardado sigue en disco. Si la respuesta es no, reinicia el servidor. No hay nada que activar ni ajuste que buscar.

La contención importa tanto como el disparador, porque un monitor que reinicia servidores sanos es peor que ninguno:

• Necesita el mismo veredicto tres veces seguidas, con un minuto de diferencia, antes de actuar: una sola muestra mala no es un fallo.
• Nunca actúa sobre un servidor que todavía no ha visto funcionar, ni durante los primeros minutos tras el arranque. Cargar un mundo grande lleva tiempo, y un bucle de reinicios no ayuda a un servidor que arrancó roto.
• Anuncia el reinicio en el juego y cuenta atrás 60 segundos, con avisos a los 30 y a los 10 segundos, y luego toma una última muestra. Un servidor que se recuperó durante la cuenta atrás se deja en paz y la cuenta atrás se cancela en voz alta.
• Nunca guarda. En todos los estados que llegan hasta aquí el mundo en memoria ya se ha perdido o está congelado, y pedirle a un servidor roto que guarde corre el riesgo de escribir ese vacío sobre tu último buen guardado. Lo que te cuesta un reinicio son los minutos desde el último autoguardado, que ya estaban perdidos cuando ocurrió el fallo.

El reinicio nocturno de esta imagen también está corregido. Avisa a tus jugadores, guarda solo si el mundo sigue cargado y en marcha de verdad, pide al servidor que se apague y luego deja de pedirlo: pasado un periodo de gracia termina el proceso, y unos segundos después hay un servidor nuevo en marcha. Nunca se omite en silencio.

Algo que merece la pena hacer tú mismo: establece una contraseña de administrador en la pestaña Ajustes del servidor. Las comprobaciones del socket y del archivo de guardado funcionan igualmente, pero las comprobaciones que detectan un mundo descargado hablan con la API de administración del servidor, y un servidor sin contraseña rechaza esas llamadas. Deliberadamente nunca tratamos una llamada rechazada como un servidor muerto, porque eso reiniciaría mundos sanos cada pocos minutos, así que dejarlo en blanco da una protección más silenciosa, no más ruidosa.

Cuando no es la fuga de memoria

Se cae segundos después de arrancar, justo tras una actualización del juego

Pocketpair publica juntas las actualizaciones del cliente y del servidor, y un servidor que sigue en la compilación anterior rechazará conexiones o fallará en cuanto se una un cliente actualizado. Actualiza el servidor en cuanto llegue el parche del cliente en lugar de esperar un aviso de tus jugadores. En Flux un reinicio descarga la imagen actual, así que basta un clic.

Se cae siempre en el mismo punto

Una caída que se reproduce exactamente igual, por ejemplo cada vez que un jugador concreto inicia sesión o cada vez que el mundo llega a una zona determinada, apunta a un guardado corrupto y no a la memoria. Restaura la copia de seguridad más reciente anterior al inicio del problema. Mantén copias de seguridad programadas precisamente por esto: un guardado al que no puedes volver atrás es un guardado que puedes perder.

Nunca llega a arrancar

Si el servidor nunca ha llegado a arrancar, se trata de un problema de configuración o de puertos y no de una caída. Comprueba que UDP 8211 es el puerto al que se conectan tus jugadores y que PalWorldSettings.ini es válido, ya que una sola línea mal formada impide que se lea el archivo. La guía de configuración explica ambas cosas.

Una lista de comprobación que puedes seguir

1. Identifica qué fallo tienes. Una subida continua de la RAM hasta el techo es la fuga. En línea pero sin poder unirse es un bloqueo. Se puede entrar pero sin mundo es un mundo descargado. Requieren respuestas distintas.
2. Establece bEnableInvaderEnemy=False en PalWorldSettings.ini y reinicia.
3. Limita BaseCampWorkerMaxNum a un valor sensato para tu grupo y limita BaseCampMaxNum al número de jugadores.
4. Programa un reinicio cada tres a seis horas en un servidor concurrido, o a diario en uno privado.
5. Confirma que la RAM de tu plan se corresponde con tu número de jugadores y sube un nivel si no es así.
6. Mantén las copias de seguridad automáticas activadas, para que un guardado corrupto sea una molestia y no el fin del mundo.
7. Define una contraseña de administrador para que las comprobaciones que detectan un mundo descargado puedan llegar a tu servidor.
8. Asegúrate de que algo reinicie el servidor cuando deja de responder, no solo cuando muere. En Flux eso viene integrado en la imagen del servidor.

Sigue ese orden y la gran mayoría de los informes de caídas de Palworld desaparecen. Lo que queda es una limitación del motor del juego que nadie puede parchear por ti, así que la pregunta deja de ser cómo evitar todos los fallos y pasa a ser con qué rapidez vuelve el servidor tras uno.