← Blog

Servidor dedicado de Valheim : por qué mejora tu experiencia de juego

Par Benjamin Dayan · PDG

· Mis à jour le 13 de octubre de 2026 · Lecture 6 min

Índice

Un servidor Valheim que permanece encendido las 24 horas cambia por completo cómo evoluciona el mundo: la vegetación crece, los biomas avanzan y las criaturas siguen actuando aunque ningún jugador esté conectado. Este artículo explica cómo la tasa de refresco, la persistencia del mapa y la estabilidad de un servidor Valheim permanente difieren de una partida gestionada desde el propio PC de un jugador anfitrión.



Por qué el mundo de Valheim avanza distinto en un servidor permanente

Valheim simula el mundo con un bucle de servidor que calcula el tiempo transcurrido, los eventos aleatorios y el crecimiento de la vegetación de forma independiente a la presencia de jugadores. En una partida con un jugador como anfitrión, ese bucle vive dentro del propio cliente del juego: si esa persona cierra Valheim o apaga su PC, toda la simulación se detiene en seco. Un servidor dedicado Valheim, en cambio, ejecuta el binario valheim_server.x86_64 sin interfaz gráfica, de forma continua, lo que permite que el calendario del juego, los asedios programados y la regeneración de recursos sigan contando días reales de actividad en lugar de sesiones de juego fragmentadas.

Esta diferencia se nota especialmente en comunidades con varios husos horarios: con un servidor dedicado Valheim siempre activo, el mundo mantiene su reloj interno aunque los jugadores se conecten en horarios distintos, y el panel permite reiniciar el proceso sin perder el estado del mapa. Puedes consultar el detalle técnico de esta configuración en la página de hosting Valheim.



Tasa de refresco y persistencia del mapa: servidor Valheim frente a partida con un jugador como anfitrión

La tasa de refresco del mundo en Valheim no se mide en FPS sino en ciclos de simulación: crecimiento de cultivos, respawn de criaturas, progreso de los eventos de bioma (invasiones de esqueletos, trolls, hordas) y el avance del contador de días para desbloquear jefes. Todos estos ciclos dependen de que el proceso servidor esté activo, no de que haya jugadores conectados en ese instante.

Diferencias prácticas entre ambos modelos

CriterioPartida con jugador anfitriónServidor dedicado Valheim
Simulación del mundoSe detiene al cerrar el juegoContinúa mientras el proceso esté activo
Recursos de CPUCompartidos con el renderizado del juegoDedicados a la simulación del mundo
Latencia para invitadosDepende de la conexión residencial del anfitriónDepende de la infraestructura de red del proveedor
EstabilidadVulnerable a cortes, actualizaciones del SO, cierres accidentalesProceso aislado, reiniciable sin afectar al resto de servicios
Persistencia tras desconexiónEl mundo queda congeladoEl mundo sigue avanzando según el reloj del servidor

En la práctica, un servidor dedicado Valheim evita el problema clásico de las partidas caseras: el jugador que aloja la sesión en su equipo necesita mantener el PC encendido, el puerto redirigido y la conexión estable durante toda la partida de los demás. Si su router se reinicia o su ISP corta la conexión, el resto del grupo se desconecta aunque estuviera jugando con normalidad.

Comandos de arranque habituales

#!/bin/bash
export templdpath=$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=./linux64:$templdpath
./valheim_server.x86_64 -nographics -batchmode \
  -name "MiMundoPersistente" -port 2456 \
  -world "Midgard" -password "contraseña_segura" \
  -crossplay -public 1 \
  -saveinterval 1200 -backups 4 -backupshort 7200 -backuplong 43200
export LD_LIBRARY_PATH=$templdpath

El parámetro -saveinterval controla cada cuántos segundos se guarda el mundo en disco, mientras que -backups, -backupshort y -backuplong definen la rotación de copias automáticas del archivo de mundo, una capa adicional frente a cualquier corte inesperado.



Configuración técnica para mantener la persistencia del mundo

El mundo de Valheim se guarda en dos archivos por partida: uno con extensión .db (datos del mundo, construcciones, terreno modificado) y otro .fwl (metadatos como semilla y nombre). Estos archivos viven en la carpeta worlds_local del proceso servidor, y cualquier corrupción en el .db suele originarse por un apagado brusco mientras se escribía el guardado automático.

Buenas prácticas de persistencia

  • Dejar que el servidor complete el ciclo de guardado antes de forzar un reinicio desde el panel.
  • Conservar al menos tres copias recientes del mundo antes de instalar mods o actualizar la versión del juego.
  • Separar la whitelist y la administración mediante adminlist.txt, permittedlist.txt y bannedlist.txt para controlar quién modifica el mundo.
  • Revisar la consola en vivo tras cada actualización de Valheim antes de abrir el acceso a toda la comunidad.
# Ejemplo de adminlist.txt (SteamID64, uno por línea)
76561198000000001
76561198000000002

Para quienes gestionan el proceso sobre su propio VPS Linux, es habitual envolver el arranque en un servicio systemd para que la persistencia sobreviva a reinicios del sistema operativo:

sudo systemctl enable valheim-server.service
sudo systemctl start valheim-server.service
sudo systemctl status valheim-server.service
sudo ufw allow 2456:2458/udp
sudo ufw enable

Esta combinación (servicio systemd más reglas de firewall explícitas) reduce el riesgo de que el proceso se quede colgado tras una actualización del kernel o un corte eléctrico, algo que en una partida casera suele traducirse en horas de mundo perdidas.



Panel, sauvegardas y mantenimiento de un servidor Valheim estable

Más allá del archivo de mundo, la estabilidad depende del proceso que lo ejecuta. Un panel tipo Pterodactyl permite ver la consola en vivo, editar adminlist.txt o los archivos de configuración sin acceso SSH directo, programar sauvegardas automáticas y reiniciar el servidor tras instalar mods vía BepInEx sin perder el mundo guardado. También facilita crear sub-usuarios para que otros administradores de la comunidad gestionen el mundo sin compartir credenciales completas.

Checklist antes de abrir el mundo a toda la comunidad

  1. Confirmar que el intervalo de guardado automático está activo y que hay al menos una copia de seguridad reciente.
  2. Probar el reinicio del servidor desde el panel y verificar que el mundo carga sin errores en la consola.
  3. Fijar una contraseña de RCON o de administración robusta, distinta de la contraseña de acceso de los jugadores.
  4. Documentar la semilla y el nombre del mundo para poder recrearlo si fuera necesario migrar de infraestructura.

Con anti-DDoS incluido a nivel de infraestructura, los picos de tráfico hacia el puerto UDP del servidor no afectan a la disponibilidad del mundo persistente, un punto especialmente relevante para servidores públicos listados en el buscador de Valheim. Puedes comparar este enfoque con el resto de juegos de supervivencia disponibles en Todos nuestros servidores de juegos.

La documentación comunitaria sobre parámetros de lanzamiento y archivos de configuración está disponible en el wiki de Valheim, útil como referencia técnica complementaria.



Mantener un mundo de Valheim coherente a lo largo de semanas exige que el reloj del servidor nunca se detenga, que los guardados automáticos se respeten y que la configuración de administración esté bien documentada. Con esos tres elementos cubiertos, la persistencia del mapa deja de depender de la disponibilidad de un solo jugador anfitrión.



FAQ

¿Por qué mi mundo de Valheim deja de avanzar cuando cierro el juego?

Porque la simulación corre dentro del propio cliente que actúa como anfitrión. En cuanto ese proceso se cierra, el reloj del mundo se detiene por completo hasta la próxima conexión.

¿Cómo evito que el archivo .db del mundo se corrompa?

Evita apagados forzados durante el guardado automático, mantén activas las copias de seguridad rotativas con los parámetros -backups y -backupshort, y conserva una copia externa antes de instalar mods o actualizar la versión del juego.

¿Los mods de BepInEx afectan a la persistencia del mundo guardado?

Algunos mods modifican datos que se escriben en el .db, así que conviene instalarlos con el servidor detenido, probar en una copia del mundo primero y revisar la consola tras el reinicio antes de abrir el acceso a todos los jugadores.

Sigue leyendo