Configurar un servidor DayZ privado: parámetros y gestión

Par Benjamin D. · PDG

8 de septiembre de 2026 · Mis à jour le 8 de septiembre de 2026 · Lecture 10 min

Índice

El archivo serverDZ.cfg DayZ es el punto donde se define casi todo lo que ocurre en tu partida: número de jugadores simultáneos, ciclo de día y noche, logs administrativos, mensajes automáticos y control de acceso. Entender cada parámetro evita reinicios a ciegas y partidas mal calibradas. Aquí repasamos los ajustes clave, la economía del loot y las opciones de whitelist.

Dónde vive serverDZ.cfg DayZ y cómo se estructura

En una instalación estándar de DayZ Server, el archivo serverDZ.cfg se encuentra en la raíz del directorio de la instancia, junto al ejecutable DayZServer (Linux) o DayZServer_x64.exe (Windows). En un panel Pterodactyl lo verás directamente en el gestor de archivos, en la carpeta raíz, al mismo nivel que mpmissions/, battleye/ y profiles/.

La sintaxis es la de los ficheros de configuración de Bohemia: una clave, un signo igual, un valor y punto y coma. Las cadenas van entre comillas dobles, los números sin ellas. Al final del fichero hay un bloque class Missions que indica qué misión (mapa) se carga.

hostname = "Chernarus Hardcore - PVE/PVP";
password = "";
passwordAdmin = "CambiaEstoPorAlgoLargo";
maxPlayers = 60;
verifySignatures = 2;
forceSameBuild = 1;
disableVoN = 0;
vonCodecQuality = 20;
disable3rdPerson = 1;
disableCrosshair = 1;
serverTime = "SystemTime";
serverTimeAcceleration = 6;
serverNightTimeAcceleration = 4;
serverTimePersistent = 1;
guaranteedUpdates = 1;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 500;
instanceId = 1;
storageAutoFix = 1;
steamQueryPort = 27016;
respawnTime = 5;

class Missions
{
    class DayZ
    {
        template = "dayzOffline.chernarusplus";
    };
};

El parámetro que más gente olvida es instanceId: identifica la carpeta de persistencia dentro de mpmissions/<misión>/storage_<id>. Si lo cambias, arrancas con un mundo vacío, sin bases ni vehículos. Es útil para un wipe controlado, pero nunca debe modificarse por accidente.

El arranque se hace por línea de comandos y ahí también se pasan los mods y los logs. Un ejemplo funcional en Linux:

./DayZServer -config=serverDZ.cfg -port=2302 \
  -BEpath=battleye -profiles=profiles \
  -mod=@CF;@VPPAdminTools;@DayZ-Expansion-Core \
  -servermod=@BaseBuildingPlus \
  -dologs -adminlog -netlog -freezecheck

Si quieres partir de una base ya montada, con puertos abiertos, consola en vivo y persistencia intacta desde el primer arranque, nuestra página de alojamiento servidor DayZ detalla la configuración exacta que aplicamos por defecto.

Parámetros clave: jugadores, seguridad, logs y red

Slots y cola de conexión

maxPlayers fija el número de supervivientes simultáneos. En DayZ no es un valor cosmético: cada jugador añade simulación de zombis, loot dinámico y replicación de red. Con procesadores Ryzen de alta frecuencia y almacenamiento NVMe la persistencia se escribe rápido, pero el motor sigue siendo muy dependiente del rendimiento monohilo. Subir de 60 a 100 slots sin ajustar simulatedPlayersBatch y los rangos de red suele traducirse en caídas de FPS del servidor y en desincronizaciones de disparos.

loginQueueConcurrentPlayers controla cuántos jugadores entran a la vez (valores altos generan picos de carga al cargar personajes) y loginQueueMaxPlayers el tamaño de la cola de espera.

Tabla de parámetros que sí conviene tocar

Parámetro	Valor habitual	Qué hace
`maxPlayers`	40–80	Slots simultáneos
`password`	cadena o vacío	Contraseña de acceso a la partida
`passwordAdmin`	cadena larga	Login administrativo por RCON/consola
`verifySignatures`	2	Obliga a firmas válidas en los mods del cliente
`forceSameBuild`	1	Impide clientes con versión distinta
`allowFilePatching`	0	Bloquea clientes con archivos no firmados
`disable3rdPerson`	0 / 1	Fuerza primera persona (hardcore)
`disableBaseDamage`	0 / 1	Protege construcciones del raideo
`disableContainerDamage`	0 / 1	Protege tiendas, barriles y cajas
`enableCfgGameplayFile`	1	Activa `cfggameplay.json` (stamina, construcción, mapa)
`respawnTime`	5	Segundos antes de poder reaparecer
`lightingConfig`	0 / 1	0 = noches oscuras y brillantes, 1 = iluminación suavizada
`speedhackDetection`	1	Detección de velocidad anómala

Logs administrativos

Sin logs no hay moderación posible. Activa el bloque completo y revisa los ficheros en profiles/ después de cada incidencia:

timeStampFormat = "Short";
logAverageFps = 1;
logMemory = 1;
logPlayers = 1;
logFile = "server_console.log";
adminLogPlayerHitsOnly = 0;
adminLogPlacement = 1;
adminLogBuildActions = 1;
adminLogPlayerList = 1;

adminLogPlacement y adminLogBuildActions son los dos que resuelven la mayoría de reportes por bases destruidas o duplicación de objetos. Con logAverageFps = 1 obtienes además el FPS del servidor en el log, la métrica más honesta para saber si el mundo está sobrecargado.

Rangos de red y visibilidad

Estos valores afectan directamente a la latencia percibida y al ancho de banda:

networkRangeClose = 20;
networkRangeNear = 150;
networkRangeFar = 1000;
networkRangeDistantEffect = 4000;
defaultVisibility = 1375;
defaultObjectViewDistance = 1375;
simulatedPlayersBatch = 20;
multithreadedReplication = 1;

Bajar defaultObjectViewDistance reduce carga en mapas modificados muy densos. simulatedPlayersBatch reparte la simulación de jugadores por lotes: valores bajos alivian el CPU pero pueden generar micro-tirones en combates masivos.

Horarios de día y noche: serverTime y aceleración

Cómo funcionan los tres parámetros

serverTime: hora de arranque. "SystemTime" usa la hora de la máquina; también acepta un formato fijo "2025/7/12/9/30" (año/mes/día/hora/minuto).
serverTimeAcceleration: multiplicador global del paso del tiempo, de 0 a 64.
serverNightTimeAcceleration: multiplicador adicional que se aplica solo de noche, y se multiplica por el anterior.
serverTimePersistent: si vale 1, la hora se guarda entre reinicios en lugar de reiniciarse.

Cálculo práctico

Con serverTimeAcceleration = 1 el día dura 24 horas reales. Con 6, un ciclo completo son 4 horas. La noche se acelera aparte: si pones serverTimeAcceleration = 6 y serverNightTimeAcceleration = 4, la noche corre a velocidad 24 y pasa en unos 30 minutos reales, mientras el día conserva ritmo jugable.

Perfil de partida	serverTimeAcceleration	serverNightTimeAcceleration	Resultado
Casual / PVP activo	8	8	Día de ~2,5 h, noche casi testimonial
Equilibrado	6	4	Día largo, noche de ~30 min
Inmersivo	3	2	Noches reales, linternas obligatorias
Hardcore nocturno	1	1	Tiempo real, muy exigente

Si quieres un horario fijo (por ejemplo, amanecer permanente para una comunidad que juega de noche), combina serverTime con un valor fijo, serverTimePersistent = 0 y reinicios programados cada 4 horas desde el panel. Cada reinicio devuelve el reloj a la hora indicada.

Para un control más fino puedes editar init.c en mpmissions/dayzOffline.chernarusplus/ y forzar la fecha, lo que también cambia la estación visual del mapa:

void main()
{
    // año, mes, día, hora, minuto
    GetGame().GetWorld().SetDate(2025, 8, 14, 7, 30);
    ...
}

Loot, economía central y whitelist

El loot no está en serverDZ.cfg

Un error frecuente: buscar la densidad de loot dentro del fichero de configuración principal. La economía vive en mpmissions/<misión>/db/ y en cfgeconomycore.xml. Los ficheros que realmente importan:

db/types.xml: cada objeto con su nominal, min, lifetime, restock, usage y tier.
db/globals.xml: variables globales (número máximo de zombis, animales, limpieza de cadáveres).
db/events.xml: eventos dinámicos como vehículos, helicrashes, convoyes y hordas.
cfgspawnabletypes.xml: qué accesorios y munición aparecen con cada arma.
cfgplayerspawnpoints.xml: puntos de aparición de nuevos supervivientes.

Un ejemplo de entrada en types.xml para subir la presencia de un rifle:

<type name="Mosin9130">
    <nominal>25</nominal>
    <lifetime>7200</lifetime>
    <restock>0</restock>
    <min>15</min>
    <quantmin>-1</quantmin>
    <quantmax>-1</quantmax>
    <cost>100</cost>
    <flags count_in_cargo="0" count_in_hoarder="0" count_in_map="1" count_in_player="0" crafted="0" deloot="0"/>
    <category name="weapons"/>
    <usage name="Military"/>
    <usage name="Hunting"/>
</type>

nominal es el objetivo de unidades en el mundo, min el umbral que dispara nuevas apariciones y lifetime los segundos que el objeto permanece antes de desaparecer. Subir nominal de forma masiva infla la tabla de economía y penaliza el rendimiento: es más limpio ajustar categorías concretas y bajar lifetime de la basura para liberar espacio.

En globals.xml, los tres valores que más se retocan son ZombieMaxCount, AnimalMaxCount y CleanupLifetimeDeadPlayer. Reducir el número de zombis es la palanca más directa cuando el FPS del servidor baja con muchos jugadores conectados.

Ajustar antes y después de cada cambio

Detén la instancia desde la consola del panel; no edites XML con el mundo corriendo.
Descarga una copia de db/ o lanza una copia de seguridad manual antes de tocar nada.
Valida el XML (un solo </type> mal cerrado y la economía no carga; verás el error en profiles/).
Arranca y revisa server_console.log buscando líneas CE con avisos.

Whitelist y acceso restringido

DayZ no incluye una whitelist nativa en su fichero de configuración. Hay tres enfoques reales, de menor a mayor control:

1. Contraseña de acceso

La opción más simple: define password = "TuClave";. Solo entra quien la conoce. Sirve para grupos pequeños o para una fase de pruebas, pero la clave circula y termina filtrándose.

2. BEC y fichero de whitelist

Con BattlEye Extended Controls puedes mantener una lista de Steam64 IDs autorizados. Se activa en Config.cfg de BEC y se alimenta con un fichero de texto:

[Misc]
Whitelist = On
WhitelistFile = Whitelist.txt
WhitelistKickMessage = No estas en la whitelist. Solicita acceso en Discord.

# Whitelist.txt
76561198000000001
76561198000000002

BEC también gestiona reinicios programados y mensajes automáticos, lo que evita depender de tareas externas.

3. Mods de administración

Herramientas como VPPAdminTools o los módulos de administración de Expansion añaden whitelist, prioridad de cola, baneos por UID y logs enriquecidos, todo desde el juego. Requieren instalar el framework correspondiente y declararlo en -mod=. Instálalos siempre en el orden de dependencias que indique cada mod.

Complementa el acceso con mensajes automáticos en el propio fichero de configuración:

motd[] = {"Bienvenido al servidor","Reinicios cada 4h - guarda tu loot"};
motdInterval = 30;

Buenas prácticas de administración y rendimiento

Copias de seguridad y persistencia

La persistencia de DayZ es delicada: un corte durante la escritura puede dejar bases fantasma o vehículos sin inventario. Mantén storageAutoFix = 1, programa copias automáticas y descarga una copia local antes de cada actualización mayor del juego o de un mod. En nuestra infraestructura las copias se generan de forma automática, pero conviene conservar también una externa antes de un wipe parcial.

Seguridad básica

passwordAdmin largo y único, distinto de la contraseña del panel.
verifySignatures = 2 y allowFilePatching = 0 en producción.
forceSameBuild = 1 para evitar clientes desfasados tras un parche.
Sub-usuarios del panel con permisos limitados para tu equipo de moderación, en lugar de compartir credenciales.
Si administras la máquina tú mismo, claves SSH en lugar de contraseña, ufw con solo los puertos necesarios (2302–2306 UDP y 27016 UDP) y fail2ban activo. La protección anti-DDoS volumétrica ya está aplicada en la red.

Rendimiento y latencia

El motor de DayZ agradece frecuencia de reloj alta y almacenamiento rápido: la escritura de persistencia y la carga de la economía central son operaciones intensivas en disco. Si el FPS del servidor cae por debajo de 20 con la sala llena, revisa en este orden: número de zombis en globals.xml, eventos activos en events.xml, mods de construcción con muchos objetos persistentes y, por último, maxPlayers.

La documentación oficial de Bohemia detalla cada clave admitida y sus rangos válidos: consulta la Source antes de aplicar valores exóticos. Si administras varias comunidades a la vez, en Todos nuestros servidores de juegos encontrarás la misma lógica de panel para otros títulos de supervivencia, y en el Blog de Fly-Serv publicamos guías técnicas por juego.

Conclusión

Dominar el fichero de configuración principal, el ciclo de día y noche, la economía central y el control de acceso te da una partida estable y con identidad propia. Trabaja siempre con copias, cambia un parámetro a la vez y valida en los logs. Es la diferencia entre una comunidad que se queda y una que abandona tras el primer reinicio caótico.

FAQ

¿Por qué mis cambios en serverDZ.cfg no se aplican al reiniciar?

Casi siempre por tres motivos: el arranque no apunta a ese fichero (revisa -config=serverDZ.cfg en la línea de comandos), hay un punto y coma o comilla mal cerrada que invalida la línea, o estás editando una copia en otra carpeta. Revisa profiles/server_console.log justo tras el arranque: los parámetros mal formados aparecen ahí.

¿Cómo consigo noches cortas sin acelerar el día entero?

Usa serverNightTimeAcceleration, que se multiplica por serverTimeAcceleration. Con serverTimeAcceleration = 6 y serverNightTimeAcceleration = 4, el día mantiene ritmo cómodo y la noche pasa a velocidad 24, unos 30 minutos reales. Añade serverTimePersistent = 1 para que el reloj no se reinicie en cada arranque.

¿Subir el loot rompe el rendimiento de la partida?

Puede hacerlo si inflas nominal en cientos de entradas de types.xml: la economía central mantiene más objetos en memoria y la limpieza tarda más. Es preferible aumentar categorías concretas, reducir el lifetime de objetos irrelevantes y controlar los eventos de events.xml.