Montar un servidor de 7 Days to Die en un VPS (2026): V3.1, SteamCMD, puertos, copias de seguridad y actualizaciones

A fecha de agosto de 2026, The Fun Pimps ha publicado la versión estable V3.1.0 Henpocalypse. El anuncio oficial también recuerda específicamente: cuando el servidor dedicado no puede conectarse, hay que confirmar que el servidor ha seleccionado Default Public Version, es decir, la rama estable actual V3.1.0.

Así que un servidor nuevo no necesita añadir latest_experimental ni parámetros de la antigua rama Alpha. El cliente y el servidor deben usar versiones compatibles; si los compañeros se quedan en la rama experimental mientras el servidor usa la rama estable por defecto, el resultado más habitual es un desajuste de versión o la imposibilidad de unirse.

V3.1 ajustó opciones de sandbox como la densidad de enemigos y animales de día y de noche y las tasas de aparición, por lo que los códigos de preajustes antiguos pueden dejar de funcionar. Haz una copia de seguridad antes de actualizar un servidor existente y no pruebes directamente sobre tu única partida guardada. Este artículo está diseñado para un servidor nuevo; los mundos existentes de V2.6/V3.0 deben verificarse primero en una copia.

Las preguntas frecuentes oficiales de soporte dan un punto de partida mínimo de cuatro núcleos a 2,8 GHz, 8 GB de memoria y 20 GB de espacio disponible, y recomiendan cuatro núcleos a 3,2 GHz y 16 GB de memoria. También advierten de que un mapa aleatorio grande puede ocupar por sí solo unos 15 GB, y que cuantos más jugadores haya, mayores serán los requisitos de memoria y ancho de banda.

A continuación se ofrecen recomendaciones de partida más adecuadas para comprar un VPS; no son garantías de rendimiento:

7 Days to Die es sensible al rendimiento de un solo núcleo, la memoria y la latencia del disco. No te fijes solo en la etiqueta "8 núcleos"; los nodos baratos con sobreventa grave suelen dar tirones al generar mapas, cargar chunks nuevos o durante la noche de horda. Antes de comprar, puedes leer primero Especificaciones de VPS para servidores de juegos y elección de ruta de red.

Este artículo usa SteamCMD + systemd porque, cuando surgen problemas de versión, puertos o partidas guardadas, puedes ver directamente los archivos y registros oficiales. Si la misma máquina también ejecuta Minecraft, Rust o Project Zomboid, puedes considerar entonces Panel de servidores de juegos Pterodactyl.

El puerto base por defecto es 26900. Los puertos de entrada que figuran actualmente en las preguntas frecuentes oficiales de soporte son:

Por tanto, las reglas mínimas del cortafuegos son 26900/tcp y 26900:26903/udp. No abras todos los puertos altos por comodidad, ni expongas el Web Dashboard o Telnet a todo Internet.

Si cambias ServerPort, los puertos UDP relacionados también se desplazan con el puerto base. Este artículo mantiene 26900 para evitar que los números no coincidan en la configuración del servidor, UFW y el grupo de seguridad de la nube.

Primero actualiza el sistema e instala los componentes básicos:

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates tar lib32gcc-s1 ufw

Crea una cuenta de servicio que no pueda iniciar sesión directamente con contraseña:

sudo adduser --system --group --home /home/sdtd --shell /bin/bash sdtd
sudo install -d -o sdtd -g sdtd /opt/steamcmd
sudo install -d -o sdtd -g sdtd /opt/7dtd-server
sudo install -d -o sdtd -g sdtd /srv/7dtd-data
sudo install -d -m 750 -o root -g sdtd /var/backups/7dtd

No ejecutes el juego como root. Una cuenta dedicada limita los permisos del servicio y también evita que las actualizaciones de SteamCMD generen archivos propiedad de root, lo que provoca que la siguiente actualización o guardado falle.

Cambia al usuario sdtd y descarga SteamCMD oficial de Valve:

sudo -iu sdtd
cd /opt/steamcmd
curl -fsSL https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz \
  -o steamcmd_linux.tar.gz
tar -xzf steamcmd_linux.tar.gz
./steamcmd.sh +quit

Confirma que el punto de entrada es ejecutable:

test -x /opt/steamcmd/steamcmd.sh

El App ID de Steam del 7 Days to Die Dedicated Server es 294420. El inicio de sesión anónimo basta para descargarlo:

/opt/steamcmd/steamcmd.sh \
  +force_install_dir /opt/7dtd-server \
  +login anonymous \
  +app_update 294420 validate \
  +quit

El comando no tiene el parámetro -beta, por lo que obtiene la rama estable por defecto actual. Tras la instalación, comprueba los archivos clave:

test -x /opt/7dtd-server/startserver.sh
test -f /opt/7dtd-server/serverconfig.xml
grep -n 'buildid' /opt/7dtd-server/steamapps/appmanifest_294420.acf
du -sh /opt/7dtd-server

Sal de la cuenta de servicio:

exit

Las actualizaciones de SteamCMD pueden sobrescribir la configuración de ejemplo del directorio de instalación. Primero copia el archivo que incluye la versión actual al directorio de datos:

sudo -u sdtd cp /opt/7dtd-server/serverconfig.xml \
  /srv/7dtd-data/serverconfig.xml
sudo -u sdtd cp /srv/7dtd-data/serverconfig.xml \
  /srv/7dtd-data/serverconfig.xml.initial
sudo -u sdtd nano /srv/7dtd-data/serverconfig.xml

Modifica solo las propiedades que ya existen en el archivo actual; no lo sobrescribas entero con un tutorial antiguo. Como mínimo, revisa estos elementos:

<property name="ServerName" value="My 7 Days to Die Server"/>
<property name="ServerDescription" value="Private V3.1 survival server"/>
<property name="ServerWebsiteURL" value=""/>
<property name="ServerPassword" value="REPLACE_WITH_PLAYER_PASSWORD"/>
<property name="ServerLoginConfirmationText" value=""/>
<property name="Region" value="Asia"/>
<property name="Language" value="Chinese"/>
<property name="ServerPort" value="26900"/>
<property name="ServerVisibility" value="2"/>
<property name="ServerMaxPlayerCount" value="8"/>
<property name="ServerReservedSlots" value="0"/>
<property name="ServerAdminSlots" value="1"/>
<property name="EACEnabled" value="true"/>
<property name="WebDashboardEnabled" value="true"/>
<property name="WebDashboardPort" value="8080"/>
<property name="TelnetEnabled" value="false"/>

Genera una contraseña de jugador dedicada:

openssl rand -base64 24

Sustituye el resultado en ServerPassword. Es la contraseña pública para unirse al servidor, no una contraseña de Steam, y no debe reutilizarse con claves SSH, cuentas de panel o contraseñas de administrador.

El archivo de configuración también tiene opciones de protocolo de red, multiplataforma, perfiles de jugador y sandbox. Mantén por ahora los valores predeterminados actuales de V3.1 y cámbialos cuando el servidor vanilla pueda unirse de forma estable. En particular, para ServerDisabledNetworkProtocols, no copies un valor de un tutorial antiguo para sobrescribir la configuración actual.

Para el primer despliegue se recomienda usar el mundo oficial Navezgane:

<property name="GameWorld" value="Navezgane"/>
<property name="GameName" value="MyV31World"/>
<property name="GameDifficulty" value="2"/>
<property name="DayNightLength" value="60"/>
<property name="DayLightLength" value="18"/>

Así puedes verificar primero la versión, los puertos, EAC y el inicio de sesión de jugadores, separando los problemas de red de los de generación de mapas aleatorios.

Tras confirmar que Navezgane funciona, cambia a un mapa aleatorio en una ventana de mantenimiento. Las propiedades del mundo aleatorio en el archivo de configuración de V3.1 deben seguir el ejemplo actual; el enfoque habitual es establecer el tipo de mundo aleatorio, una semilla única y un tamaño de 6144. Durante la generación, el uso de CPU, memoria y disco aumenta notablemente, así que no lo hagas con jugadores conectados.

GameName determina el identificador de la partida guardada. No lo cambies a la ligera una vez que el servidor esté en producción, de lo contrario el servidor puede parecer que "ha perdido la partida" cuando en realidad solo ha iniciado otro directorio de juego.

Ejecútalo primero en primer plano para ver directamente la generación del mundo, EAC, los puertos y los errores de configuración:

sudo -u sdtd /opt/7dtd-server/startserver.sh \
  -configfile=/srv/7dtd-data/serverconfig.xml \
  -UserDataFolder=/srv/7dtd-data

El primer arranque puede tardar varios minutos. No des por hecho que el servidor está listo solo porque veas un proceso Java/Unity; espera a que el registro muestre que el mundo del juego ha terminado de cargarse y está escuchando en el puerto del servidor.

Crea un usuario de Web Dashboard en la consola:

createwebuser

Sigue las indicaciones para crear una cuenta de administrador dedicada y una contraseña segura. Después, introduce en la consola:

saveworld
shutdown

Espera a que el mundo se guarde y salga normalmente. No cierres SSH directamente ni uses kill -9. Comprueba el directorio de datos:

sudo -u sdtd find /srv/7dtd-data -maxdepth 3 -type f | sort | head -n 120
sudo du -sh /srv/7dtd-data

Crea la unidad de servicio:

sudo nano /etc/systemd/system/7dtd.service

Escribe:

[Unit]
Description=7 Days to Die Dedicated Server
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=sdtd
Group=sdtd
WorkingDirectory=/opt/7dtd-server
ExecStart=/opt/7dtd-server/startserver.sh -configfile=/srv/7dtd-data/serverconfig.xml -UserDataFolder=/srv/7dtd-data
Restart=on-failure
RestartSec=20
KillSignal=SIGINT
TimeoutStopSec=300
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Carga e inicia:

sudo systemctl daemon-reload
sudo systemctl enable --now 7dtd
sudo systemctl status 7dtd --no-pager
sudo journalctl -u 7dtd -n 250 --no-pager

LimitNOFILE=65535 sirve para evitar alcanzar el límite bajo de archivos abiertos de Linux con mundos grandes o muchos jugadores. Las preguntas frecuentes oficiales de soporte también han documentado específicamente el problema de nofile=1024 que provoca que el servicio no arranque.

Tras detener el servicio, confirma que el proceso ha terminado antes de hacer la copia de seguridad:

sudo systemctl stop 7dtd
sudo systemctl status 7dtd --no-pager

Si tras 300 segundos sigue sin terminar, revisa primero los registros y el espacio en disco; no lo mates a la fuerza de inmediato. Una terminación forzada puede corromper chunks o datos de jugador que se están escribiendo.

Mantén abierta la sesión SSH actual, permite primero SSH y luego añade los puertos del juego:

sudo ufw allow OpenSSH
sudo ufw allow 26900/tcp
sudo ufw allow 26900:26903/udp
sudo ufw status numbered
sudo ufw enable

El grupo de seguridad del proveedor de nube también debe añadir las mismas reglas. Comprueba la escucha:

sudo ss -lntup | grep -E ':26900|:26901|:26902|:26903'

No añadas reglas públicas para 8080/tcp ni 8081/tcp. Accede al Web Dashboard mediante un túnel SSH y mantén Telnet cerrado.

En tu propio ordenador, ejecuta:

ssh -L 8080:127.0.0.1:8080 [email protected]

Mantén la sesión SSH y luego abre:

http://127.0.0.1:8080

Inicia sesión con el usuario web creado en el primer arranque en primer plano. Como UFW y el grupo de seguridad de la nube no abren el 8080, los escáneres públicos no pueden acceder directamente a esta entrada de administración.

Si el puerto local 8080 ya está ocupado, puedes cambiarlo al local 18080:

ssh -L 18080:127.0.0.1:8080 [email protected]

Luego visita http://127.0.0.1:18080.

No trates la contraseña pública para unirse al servidor como un sistema de permisos. Los administradores deben usar su propia identidad de Steam/EOS y dar permisos solo a quienes realmente los necesiten.

Añade un administrador en la consola del servidor o en el Web Dashboard protegido por el túnel SSH:

admin add STEAM64_ID 0

Añade a la lista blanca:

whitelist add STEAM64_ID

Consulta la lista actual:

admin list
whitelist list
ban list

El formato específico de identidad y la ayuda de comandos pueden cambiar según la versión y la plataforma de red; antes de ejecutar, introduce primero help admin y help whitelist en la consola actual de V3.1. No copies directamente serveradmin.xml de un servidor desconocido; puede contener identidades erróneas, IDs de plataforma antiguos o cuentas de alto privilegio innecesarias.

Primero haz que un jugador se conecte directamente usando la IP pública:

IP: 203.0.113.20
Port: 26900
Password: serverconfig.xml 中的 ServerPassword

Sustituye la IP de ejemplo por la dirección real del VPS. Cuando la conexión directa funcione, comprueba la lista de servidores y la conexión multiplataforma, así es más fácil distinguir problemas de actualización de la lista, de EOS/Steam y de red básica.

Un dominio puede crear un registro A normal que apunte a la IPv4 del VPS, pero el proxy HTTP normal de Cloudflare (nube naranja) no puede reenviar los puertos de juego de 7 Days to Die y debe configurarse como DNS only.

Este artículo usa explícitamente:

-UserDataFolder=/srv/7dtd-data

Por tanto, los mundos, jugadores, registros y mapas generados fuera de la configuración se concentran en /srv/7dtd-data. Los subdirectorios pueden cambiar según la versión y el tipo de mundo; no adivines las rutas solo a partir de tutoriales, confírmalas primero con los archivos reales:

sudo -u sdtd find /srv/7dtd-data -maxdepth 4 -type f | sort | head -n 200
sudo du -h -d 3 /srv/7dtd-data | sort -h | tail -n 40

/opt/7dtd-server son archivos de programa que se pueden reinstalar con SteamCMD, mientras que /srv/7dtd-data son los mundos, jugadores, permisos, registros y mapas generados que no se deben perder.

Lo más seguro es detener el servidor en una ventana de mantenimiento y empaquetar todo el directorio de datos:

sudo systemctl stop 7dtd
sudo tar -C /srv -czf \
  "/var/backups/7dtd/7dtd-data-$(date -u +%Y%m%dT%H%M%SZ).tar.gz" \
  7dtd-data
sudo systemctl start 7dtd
sudo systemctl is-active 7dtd

Comprueba el archivo:

sudo ls -lh /var/backups/7dtd
sudo tar -tzf /var/backups/7dtd/7dtd-data-YYYYMMDDTHHMMSSZ.tar.gz | head -n 120

Sustituye el nombre de archivo de ejemplo por el archivo real. Conserva al menos una copia en otra máquina o en almacenamiento de objetos, y establece un periodo de retención; guardar las copias solo en el mismo disco del VPS significa que se perderán juntas si la máquina falla. Para una solución completa, consulta Copias de seguridad y simulacros de restauración en VPS.

Detén el servidor antes de restaurar y conserva el directorio actual como reversión temporal:

sudo systemctl stop 7dtd
sudo tar -tzf /var/backups/7dtd/7dtd-data-YYYYMMDDTHHMMSSZ.tar.gz | head -n 120
sudo mv /srv/7dtd-data \
  "/srv/7dtd-data.before-restore-$(date -u +%Y%m%dT%H%M%SZ)"
sudo tar -C /srv -xzf \
  /var/backups/7dtd/7dtd-data-YYYYMMDDTHHMMSSZ.tar.gz
sudo chown -R sdtd:sdtd /srv/7dtd-data
sudo systemctl start 7dtd

Verifica tras restaurar:

sudo systemctl status 7dtd --no-pager
sudo journalctl -u 7dtd -n 300 --no-pager
sudo du -sh /srv/7dtd-data

Haz que un jugador de prueba se una y comprueba personajes, inventario, bases, reclamaciones de terreno, misiones, exploración del mapa y permisos de administrador. No borres 7dtd-data.before-restore-* antes de completar la aceptación; es el punto de reversión de este simulacro.

Detén el servidor y haz copia de seguridad antes de actualizar, y después actualiza solo la rama estable por defecto. Crea el script:

sudo nano /usr/local/sbin/update-7dtd-server

Escribe:

#!/usr/bin/env bash
set -euo pipefail

backup_dir=/var/backups/7dtd
stamp=$(date -u +%Y%m%dT%H%M%SZ)
was_active=0

install -d -m 750 -o root -g sdtd "$backup_dir"

if systemctl is-active --quiet 7dtd; then
  was_active=1
  systemctl stop 7dtd
fi

restart_service() {
  if [ "$was_active" -eq 1 ]; then
    systemctl start 7dtd
  fi
}
trap restart_service EXIT

tar -C /srv -czf \
  "$backup_dir/7dtd-before-update-$stamp.tar.gz" \
  7dtd-data

sudo -u sdtd /opt/steamcmd/steamcmd.sh \
  +force_install_dir /opt/7dtd-server \
  +login anonymous \
  +app_update 294420 \
  +quit

test -x /opt/7dtd-server/startserver.sh
test -f /srv/7dtd-data/serverconfig.xml

Establece permisos y ejecútalo manualmente:

sudo chown root:root /usr/local/sbin/update-7dtd-server
sudo chmod 750 /usr/local/sbin/update-7dtd-server
sudo /usr/local/sbin/update-7dtd-server
sudo systemctl is-active 7dtd
sudo journalctl -u 7dtd -n 250 --no-pager

El script no tiene -beta latest_experimental, por lo que no cambiará activamente a la rama experimental. Tras una actualización correcta, confirma en los registros la versión, la carga del mundo y la conexión de jugadores; no des por terminado el mantenimiento solo porque SteamCMD devolvió éxito.

Un servidor privado vanilla puede buscar actualizaciones a diario en una ventana fija; los servidores con mods y los públicos son más adecuados para mantenimiento manual, para evitar que el servidor se actualice primero mientras los clientes o los mods aún no se han puesto al día.

Crea un servicio oneshot:

sudo nano /etc/systemd/system/7dtd-update.service

[Unit]
Description=Update 7 Days to Die Dedicated Server

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/update-7dtd-server

Crea un temporizador:

sudo nano /etc/systemd/system/7dtd-update.timer

[Unit]
Description=7 Days to Die daily maintenance window

[Timer]
OnCalendar=*-*-* 05:40:00
RandomizedDelaySec=10m
Persistent=true

[Install]
WantedBy=timers.target

Carga y consulta:

sudo systemctl daemon-reload
sudo systemctl enable --now 7dtd-update.timer
systemctl list-timers 7dtd-update.timer

Cuando salga una gran versión estable, se convierta el mundo o la compatibilidad de mods no esté clara, desactiva primero el temporizador:

sudo systemctl disable --now 7dtd-update.timer

El anuncio oficial de V3.1 indica que las partidas antiguas normalmente se pueden actualizar, pero también recomienda hacer copia de seguridad; las nuevas opciones de densidad día/noche y de aparición también pueden invalidar los códigos de preajustes de sandbox antiguos. El proceso seguro es:

1. Detén el servicio antiguo y haz copia de seguridad de todo el directorio de datos de usuario.
2. Anota el build del servidor antiguo, la lista de mods y serverconfig.xml.
3. Copia la partida guardada a un directorio independiente; no toques el único mundo de producción.
4. Desactiva primero los mods de terceros y carga la copia con la versión estable actual.
5. Revisa los preajustes de sandbox personalizados, jugadores, bases, chunks y misiones.
6. Solo cuando la copia pase la aceptación, programa el cambio en producción.

No "arregles" un desajuste de versión borrando la partida guardada. Si las ramas del servidor y del cliente son distintas, unifica primero las versiones; la corrupción de chunks, los preajustes inválidos y los conflictos de mods requieren registros y copias de seguridad para diagnosticarse.

Para la detención, el archivado completo de datos y las comprobaciones de restauración en servidores de mundo abierto similares, también puedes consultar el Proceso de copia de seguridad del servidor dedicado de Project Zomboid para establecer un hábito de mantenimiento fijo.

Primero haz que el servidor vanilla V3.1 funcione de forma estable y luego añade mods. Añade solo unos pocos a la vez y anota la fuente, la versión y la configuración. Que la página de un mod diga "compatible con V3" no significa que ya sea compatible con V3.1.

EACEnabled=true es adecuado para servidores vanilla y servidores que necesitan anticheat. Algunos mods requieren desactivar EAC, pero eso cambia el límite de seguridad. Cámbialo solo cuando la documentación del mod lo exija explícitamente y todos los jugadores entiendan el riesgo, y no trates "desactivar EAC" como una solución universal para cualquier error de arranque.

Antes de actualizar mods, completa:

• Copia de seguridad del mundo y de los datos de jugadores.
• Guarda los archivos de mod actuales y la lista de versiones.
• Prueba el arranque y la conexión en un mundo copia.
• Revisa los registros en busca de errores de XML, Harmony, EAC y red.
• Conserva la versión anterior de los archivos para poder revertir rápido.

Registra datos durante la generación de mapas aleatorios, la noche de horda y la exploración dispersa de varios jugadores:

free -h
df -h /opt/7dtd-server /srv/7dtd-data /var/backups/7dtd
uptime
ps -eo pid,%cpu,%mem,rss,etime,cmd | grep '[7]DaysToDieServer'
sudo journalctl -u 7dtd --since "30 minutes ago" --no-pager

Fenómenos habituales:

• Memoria y CPU altas durante mucho tiempo al generar el mapa: espera primero a que termine la generación, no reinicies con frecuencia.
• Un solo núcleo al máximo en la noche de horda: reduce el número de jugadores, la densidad de enemigos o cambia a un VPS con mejor rendimiento de un solo núcleo.
• Tirones cuando los jugadores exploran por separado: revisa la latencia del disco, la memoria y la carga de chunks nuevos.
• Partidas guardadas cada vez más grandes: deja espacio para copias locales, sincronización externa y extracción de restauración.
• Latencia notable en hora punta de la tarde-noche: compara la pérdida de paquetes UDP y las rutas del centro de datos, no solo añadas memoria.

• SteamCMD instaló el App ID 294420, sin usar parámetros de la rama experimental.
• Cliente y servidor están en la rama estable pública por defecto actual V3.1.
• El servicio usa un usuario sdtd dedicado y no se ejecuta como root.
• La configuración proviene del serverconfig.xml incluido en la versión actual, sin sobrescribirlo entero con una plantilla antigua.
• systemctl is-active 7dtd devuelve active.
• LimitNOFILE=65535 está en efecto en systemd.
• 26900 TCP y 26900–26903 UDP están abiertos en UFW y en el grupo de seguridad.
• El Web Dashboard solo se accede por túnel SSH y Telnet no está expuesto a Internet.
• Los jugadores pueden unirse por IP pública:26900, y los problemas de la lista de servidores se investigan por separado.
• Los administradores usan identidades personales y no se comparte la cuenta de máximo privilegio.
• /srv/7dtd-data se ha copiado por completo a otra máquina o almacenamiento de objetos.
• Se ha hecho un simulacro de restauración y se han revisado personajes, bases, chunks y permisos.
• Antes de actualizaciones de gran versión y de mods, se detiene el servidor, se hace copia de seguridad y se conserva una copia de reversión.

• The Fun Pimps: anuncio de la versión estable V3.1.0 Henpocalypse
• The Fun Pimps: FAQ de soporte y puertos del servidor dedicado
• Valve Developer Community: 7 Days to Die Dedicated Server
• Valve Developer Community: SteamCMD

Donde realmente falla un servidor de 7 Days to Die no es en SteamCMD, sino en la rama de versión, los puertos, los mapas aleatorios y las copias de seguridad. Primero haz funcionar V3.1, 26900 TCP y 26900–26903 UDP con el mundo vanilla Navezgane, y luego añade mapas aleatorios y mods; la solución de problemas será mucho más sencilla.

Para la operación a largo plazo, trata /srv/7dtd-data como el activo principal: detén el servidor normalmente antes de actualizar, haz copia de seguridad completa y restaura de verdad una vez. Así, aunque te encuentres con cambios en los preajustes de sandbox, conflictos de mods o corrupción de chunks, podrás volver a un mundo confirmado como funcional, en lugar de jugártela con tu única partida guardada.