Como configurar seu servidor DayZ do zero
Par Benjamin D. · PDG
· Mis à jour le 8 Gwengolo 2026 · Lecture 10 min
Sumário
O serverDZ.cfg DayZ é o arquivo que define o comportamento global da sua instância: nome exibido na lista, número de slots, aceleração do tempo, verificação de assinaturas e a missão carregada. Junto com os arquivos XML da economia central, ele controla spawn de jogadores, ciclo de loot e integração de mods. Abaixo, um guia técnico direto para editar cada bloco sem quebrar a persistência.
serverDZ.cfg DayZ: anatomia do arquivo e parâmetros que realmente importam
O arquivo fica na raiz da instalação do servidor, ao lado do executável, e é carregado pelo parâmetro -config=serverDZ.cfg. Ele usa sintaxe própria da Bohemia: pares chave = valor;, strings entre aspas duplas e uma classe final Missions que aponta para a pasta da missão dentro de mpmissions/.
hostname = "[BR] Chernarus Hardcore | PvE/PvP";
password = "";
passwordAdmin = "SenhaLongaEAleatoria2024";
enableWhitelist = 0;
maxPlayers = 60;
verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
disableVoN = 0;
vonCodecQuality = 20;
disable3rdPerson = 0;
disableCrosshair = 0;
disablePersonalLight = 1;
serverTime = "SystemTime";
serverTimeAcceleration = 8;
serverNightTimeAcceleration = 4;
serverTimePersistent = 0;
guaranteedUpdates = 1;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 500;
instanceId = 1;
storageAutoFix = 1;
respawnTime = 5;
timeStampFormat = "Short";
logAverageFps = 30;
logMemory = 30;
logPlayers = 30;
logFile = "server_console.log";
adminLogPlayerHitsOnly = 0;
adminLogPlacement = 1;
adminLogBuildActions = 1;
adminLogPlayerList = 1;
enableDebugMonitor = 0;
simulatedPlayersBatch = 20;
multithreadedReplication = 1;
speedhackDetection = 1;
networkRangeClose = 20;
networkRangeNear = 150;
networkRangeFar = 1000;
networkRangeDistantEffect = 4000;
networkObjectBatchLogSlow = 5;
networkObjectBatchCompute = 1000;
networkObjectBatchSendCreate = 10;
networkObjectBatchSendDelete = 10;
defaultVisibility = 1375;
defaultObjectViewDistance = 1375;
lightingConfig = 0;
class Missions
{
class DayZ
{
template = "dayzOffline.chernarusplus";
};
};
Os campos que mudam a experiência de jogo
| Parâmetro | Efeito prático | Valor de referência |
|---|---|---|
serverTimeAcceleration | Multiplicador do ciclo dia/noite (1 = tempo real) | 6 a 12 para sessões curtas |
serverNightTimeAcceleration | Acelera apenas a noite; multiplica o valor anterior | 4 a 8 se a comunidade reclama de noites longas |
serverTimePersistent | Mantém a hora do mundo entre reinícios | 1 em servidores de longo prazo |
verifySignatures | Exige assinaturas .bikey válidas em todos os PBOs | 2, sempre |
allowFilePatching | Permite clientes com arquivos não empacotados | 0 em produção |
instanceId | Separa a persistência entre instâncias diferentes | Único por mapa |
storageAutoFix | Corrige automaticamente bancos de persistência corrompidos | 1 |
lightingConfig | 0 = noites escuras (vanilla), 1 = brilhante | 0 para sobrevivência realista |
Uma armadilha clássica: editar o serverDZ.cfg com um editor que grava BOM ou quebras de linha CRLF/LF inconsistentes. O parser é tolerante, mas comentários mal fechados (// versus /* */) derrubam o carregamento com um erro genérico. Sempre valide o log server_console.log após qualquer alteração.
No painel Pterodactyl usado pela Fly-Serv, você edita esse arquivo direto no gerenciador de arquivos e reinicia pela console ao vivo, sem precisar de FTP externo. Se quiser um ambiente já pronto com Ryzen de alta frequência, NVMe e anti-DDoS ativo por padrão, veja a página de hospedagem DayZ e volte para aplicar as configurações abaixo.
Ajuste de spawn de jogadores, infectados e eventos dinâmicos
Nada disso está no arquivo principal: o comportamento do mundo mora em mpmissions/dayzOffline.chernarusplus/. É lá que ficam init.c, cfgplayerspawnpoints.xml, cfgeventspawns.xml, cfggameplay.json e a pasta db/ com a economia central.
Pontos de nascimento dos jogadores
O cfgplayerspawnpoints.xml separa três grupos: fresh (novo personagem), hop (server hopping) e travel (troca de mapa). Cada grupo tem uma lista de generator_posbubbles com coordenadas X/Z e um raio.
<fresh>
<generator_posbubbles>
<pos x="6642.0" z="2600.0" a="0"/>
<pos x="10504.0" z="2226.0" a="0"/>
</generator_posbubbles>
</fresh>
Para reduzir o "spawn kill" em servidores PvP, aumente o número de bolhas e distribua-as ao longo da costa. Se você quiser um único ponto central (estilo roleplay), deixe apenas uma entrada — mas espere filas visuais de jogadores nascendo no mesmo lugar.
Infectados, animais e veículos: events.xml
O arquivo db/events.xml comanda tudo o que é gerado dinamicamente. Cada evento tem nominal (alvo), min, max, lifetime, restock e uma lista de children.
<event name="VehicleSedan02">
<nominal>10</nominal>
<min>6</min>
<max>12</max>
<lifetime>1800</lifetime>
<restock>0</restock>
<saferadius>500</saferadius>
<distanceradius>500</distanceradius>
<cleanupradius>200</cleanupradius>
<position>fixed</position>
<limit>mixed</limit>
<active>1</active>
<children>
<child lootmax="0" lootmin="0" max="6" min="3" type="Sedan_02"/>
</children>
</event>
As posições de cada evento vêm de cfgeventspawns.xml. Se você aumentar o max de veículos sem adicionar coordenadas correspondentes, o servidor simplesmente não gera os extras. Para hordas de infectados, edite InfectedArmy, InfectedCity e afins, e cheque ZombieMaxCount em db/globals.xml — esse teto global limita todos os eventos somados e impacta diretamente o uso de CPU.
globals.xml: os limites do mundo
ZombieMaxCount— teto de infectados simultâneos (padrão 1000). Reduza para 600–800 em servidores com muitos jogadores e mods pesados.AnimalMaxCount— mesma lógica para a fauna.CleanupLifetimeDefault— segundos até um item solto no chão desaparecer.CleanupLifetimeDeadPlayer— persistência do corpo do jogador.IdleModeCountdown— tempo até o servidor entrar em modo ocioso quando vazio (economiza CPU).TimeHopping/TimeLogin— penalidades de conexão contra combat logging.
Controle fino do loot: types.xml e cfgspawnabletypes.xml
O coração da economia central é db/types.xml. Cada item tem uma entrada com atributos que definem quantos existem no mundo, por quanto tempo e onde.
<type name="Mosin9130">
<nominal>30</nominal>
<lifetime>14400</lifetime>
<restock>0</restock>
<min>20</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="Hunting"/>
<usage name="Village"/>
<value name="Tier2"/>
<value name="Tier3"/>
</type>
O que cada atributo faz de verdade
| Tag | Função |
|---|---|
nominal | Quantidade-alvo no mundo. Só é respeitada se houver pontos de loot compatíveis com usage e value. |
min | Piso que dispara o reabastecimento. Sempre menor que nominal. |
lifetime | Segundos até o item ser limpo se ninguém interagir com ele. |
restock | Espera antes de repor após atingir min. Use 0 para reposição imediata. |
quantmin/quantmax | Percentual de munição, líquido ou carga. -1 desativa. |
usage | Categoria de local: Military, Police, Village, Town, Industrial, Farm, Hunting, Medic, Coast, Prison. |
value | Tier de raridade da região (Tier1 a Tier4, além de Unique). Define em quais zonas do mapa o item aparece. |
flags | count_in_cargo e count_in_hoarder determinam se itens guardados em bases contam para o nominal. |
Erro mais comum: aumentar o nominal de armas militares e não ver diferença. Isso ocorre porque a quantidade de pontos de loot em prédios com usage="Military" é fixa (definida em mapgroupproto.xml). Se todos os pontos já estão ocupados, subir o nominal não gera nada. A saída é reduzir o lifetime dos itens de baixo valor para liberar slots, ou usar flags count_in_cargo="0" para que estoques em bases não travem a economia.
Definindo anexos e conteúdo com cfgspawnabletypes.xml
Esse arquivo controla o que nasce dentro ou acoplado a um item. Útil para dar chance de spawn de carregadores em armas ou combustível em veículos.
<type name="Mosin9130">
<attachments chance="0.30">
<item name="PUScopeOptic" chance="0.40"/>
<item name="Mosin_Compensator" chance="0.60"/>
</attachments>
<cargo chance="0.20">
<item name="Ammo_762x54" chance="1.00"/>
</cargo>
</type>
Arquivos personalizados sem sobrescrever o vanilla
Em vez de editar o types.xml original a cada atualização, registre arquivos adicionais em cfgeconomycore.xml:
<economycore>
<classes>...</classes>
<defaults>...</defaults>
<ce folder="custom">
<file name="mod_types.xml" type="types"/>
<file name="ajustes_militar.xml" type="types"/>
</ce>
</economycore>
Crie a pasta mpmissions/dayzOffline.chernarusplus/custom/ e coloque os XML lá. Assim, um patch oficial que substitua o db/types.xml não apaga suas alterações. Depois de mexer na economia, apague storage_1/ apenas se quiser resetar a persistência — caso contrário, mantenha e deixe o storageAutoFix trabalhar.
Instalação de mods, ordem de carregamento e chaves de assinatura
Mods do DayZ vêm da Steam Workshop (App ID 221100) e o servidor dedicado usa o App ID 223350. Com SteamCMD:
# Atualizar o servidor dedicado
./steamcmd.sh +force_install_dir /home/dayz/server \
+login anonymous +app_update 223350 validate +quit
# Baixar um mod da Workshop (requer conta Steam com DayZ)
./steamcmd.sh +force_install_dir /home/dayz/workshop \
+login SEU_USUARIO +workshop_download_item 221100 1559212036 validate +quit
Fluxo correto de instalação
- Copie a pasta do mod para a raiz do servidor renomeando para
@NomeDoMod(o prefixo@é obrigatório). - Copie todos os arquivos
.bikeyde@NomeDoMod/keys/para a pastakeys/do servidor. Sem isso e comverifySignatures = 2, ninguém conecta. - Adicione o mod ao parâmetro de inicialização, separando com ponto e vírgula, sem espaços.
- Registre os
typesdo mod emcfgeconomycore.xml, senão os itens novos nunca aparecem no loot.
# Linux
./DayZServer -config=serverDZ.cfg -port=2302 -profiles=profiles \
-dologs -adminlog -netlog -freezecheck \
-mod=@CF;@VPPAdminTools;@BuilderItems \
-servermod=@ServerSideMod
# Windows
DayZServer_x64.exe -config=serverDZ.cfg -port=2302 "-profiles=profiles" ^
-dologs -adminlog -netlog -mod=@CF;@VPPAdminTools
Ordem de carregamento
A ordem importa. Frameworks e bibliotecas vêm primeiro (por exemplo, @CF antes de qualquer mod que dependa dele). Mods que sobrescrevem classes vanilla devem vir depois dos que apenas adicionam conteúdo. Use -servermod= para mods que só rodam no servidor: assim os jogadores não precisam baixá-los.
Checklist de diagnóstico quando um mod quebra o servidor
- Servidor não aparece na lista: confira
steamQueryPort(padrão 2305 quando a porta de jogo é 2302) e se as portas UDP 2302–2305 estão abertas. - "You cannot play/edit this content": mod ausente no cliente ou
.bikeynão copiado. - Crash no boot com
Class 'X' not found: dependência faltando ou ordem de carregamento invertida. - Itens do mod não spawnam: arquivo de types do mod não declarado em
cfgeconomycore.xml, ouusage/valueincompatíveis. - Loot sumindo depois de reiniciar:
lifetimebaixo demais ou pastastorage_1apagada por script de reinício.
Depois de cada atualização oficial, todos os mods precisam ser recompilados pelos autores. Manter forceSameBuild = 1 evita que clientes desatualizados entrem e corrompam a persistência. A documentação de referência dos parâmetros está no wiki oficial da Bohemia Interactive.
Desempenho, reinícios programados e proteção dos dados
DayZ é sensível à frequência de clock do processador: a simulação de IA dos infectados e a replicação de rede são majoritariamente single-thread. Por isso, CPUs Ryzen de alta frequência com NVMe reduzem os picos de latência muito mais do que simplesmente adicionar núcleos.
Boas práticas de administração
- Reinícios a cada 3–4 horas: o processo do DayZ acumula memória; reinícios programados pela console do painel evitam quedas de FPS do servidor ao fim da sessão.
- Backups da pasta
storage_1: é onde vivem bases, veículos e a economia. Automatize e mantenha ao menos 7 dias de histórico. - Monitore o
logAverageFps: abaixo de 15 FPS do servidor, os infectados começam a "teletransportar". ReduzaZombieMaxCountesimulatedPlayersBatch. - Senha administrativa longa e única em
passwordAdmin, nunca reutilizada em outro serviço. - Whitelist (
enableWhitelist = 1) para comunidades fechadas, combinada com uma lista de Steam64 IDs emprofiles/whitelist.txt. - Se você administra a máquina diretamente, use chaves SSH em vez de senha, ative
ufwliberando só as portas UDP necessárias e instalefail2ban.
# Exemplo de endurecimento básico em Linux
ssh-keygen -t ed25519 -C "admin-dayz"
sudo ufw allow 2302:2305/udp
sudo ufw allow OpenSSH
sudo ufw enable
sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
Proteção contra ataques volumétricos já é tratada na camada de infraestrutura, então o seu foco fica na configuração e nos backups. Se administra vários jogos além do DayZ, vale conferir Todos os nossos servidores de jogos e os tutoriais publicados no Blog da Fly-Serv.
Rotina de validação após qualquer alteração
- Valide os XML em um parser (erro de sintaxe = economia inteira não carrega).
- Reinicie e leia o
server_console.logprocurando porERROReUnknown type. - Conecte-se e teste o loot em uma zona correspondente ao
usagealterado. - Confirme que a persistência continua íntegra depois de dois reinícios seguidos.
Conclusão
Configurar DayZ é um trabalho em camadas: o arquivo principal define as regras da sessão, os XML da economia central definem o mundo, e os mods se encaixam por cima. Altere um bloco por vez, leia os logs a cada reinício e mantenha backups da pasta de persistência. Com essa disciplina, ajustar loot, spawn e conteúdo modificado vira rotina previsível.
FAQ
Por que meu loot militar não aumenta mesmo depois de subir o nominal no types.xml?Porque o número de pontos de loot com usage="Military" é fixo e definido em mapgroupproto.xml. Se todos os pontos já estão ocupados, o nominal maior não gera nada. Reduza o lifetime de itens de baixo valor para liberar posições, ajuste os value (Tier) para incluir mais regiões do mapa, ou defina count_in_cargo="0" para que estoques em bases não travem a economia.
Não basta carregar o mod na linha de inicialização. Você precisa declarar o arquivo de types do mod em cfgeconomycore.xml, dentro de um bloco <ce folder="custom"> apontando para o XML. Depois, confirme que cada entrada tem usage e value válidos e reinicie. Verifique o server_console.log em busca de Unknown type, que indica classe inexistente ou mod não carregado.
Comece reduzindo ZombieMaxCount e AnimalMaxCount em globals.xml, já que a IA dos infectados é o maior consumidor de CPU. Ajuste simulatedPlayersBatch para 15–20, mantenha multithreadedReplication = 1 e diminua networkRangeFar se o mapa tiver muitas construções. Agende reinícios a cada 3–4 horas e acompanhe o valor registrado por logAverageFps.