DayZ Server Settings Reference

The performance guide tells you what to paste into your DayZ server's config and stops there on purpose. This page is for everything else: every DayZ server setting an operator is likely to meet — across serverDZ.cfg, the launch parameters, dayzsetting.xml and the economy files — with what it does, its default, and how we know. Where we have not verified something, the row says so; an honest "unmeasured" here beats a confident number from a guide that never checked.

How to read the evidence column

label	meaning
measured	we ran an experiment and observed the behaviour; the platform is named
verified in the server program	established by inspecting the server's own executable or its shipped scripts, not documentation
shipped files	checked against an untouched install from Bohemia
vendor documentation	Bohemia's docs or example files say so; we have not verified it — and we have caught this source publishing sample values as "defaults" more than once
unmeasured	nobody has measured it that we can find, including us
plumbing	a value you choose (a name, a password, a path) — there is no claim to verify

Where a setting carries more than one claim, the cell names which claim each label applies to.

A note on defaults: you cannot discover a default by writing a value and reading it back — the server echoes whatever you wrote, whether or not it uses the key. Defaults on this page are only called verified when they were established some other way.

serverDZ.cfg — identity and access

setting	what it does	default / value	evidence
`hostname`	server name in the browser	—	plumbing
`password`	join password (empty = public)	`""`	plumbing
`passwordAdmin`	admin login password — change it	—	plumbing
`maxPlayers`	the player cap. More players is more work, and the late-session slowdown on busy servers arrives with population	60 in most examples	population→load relation: measured on live fleets
`verifySignatures`	clients must run signed files. ⚠️ A value of 0 or below is silently discarded — it means unset, not off	2	discard behaviour: verified in the server program (Windows); key present on Linux too
`forceSameBuild`	clients must match the server build	1	vendor documentation
`instanceId`	identifies this server's persistence folder; unique per server on a box	1	shipped files

setting	what it does	default / value	evidence
`loginQueueConcurrentPlayers`	how many players are processed into the world at once	5	semantics: vendor documentation. Bohemia's stated reason (protecting the server during a post-restart login rush) is their claim; the protective effect is unmeasured
`loginQueueMaxPlayers`	how many may wait in the queue	500	vendor documentation; queue length, not a performance knob
`storageAutoFix`	described by Bohemia as repairing corrupted persistence at boot rather than failing. Any value above 0 is "on"	1	read-at-boot: verified in the server program (Windows). The repair behaviour itself: unmeasured

serverDZ.cfg — network ranges

These are the bubbles around each player inside which the server sends things. We do not recommend writing any of these keys — see the guide for why lowering networkRangeFar is a combat change, not an optimisation.

setting	what it covers	claimed default	evidence
`networkRangeClose`	containers with items in them	20 m	semantics and value: vendor documentation, unverified
`networkRangeNear`	loose inventory items	150 m	semantics and value: vendor documentation, unverified
`networkRangeFar`	everything that is not an inventory item — including other players and bullets in flight	1000 m	what it carries: verified in the server program (Windows). The value: vendor documentation, unverified. The claimed 15–20% bandwidth saving circulating in guides: unmeasured, no source
`networkRangeDistantEffect`	a much larger bubble for sound — this, not Far, is distant gunfire	4000 m	attribution: verified in the server program (Windows). The value: vendor documentation, unverified

serverDZ.cfg — logging and the admin log

setting	what it does	evidence
`logAverageFps` (needs `-doLogs`)	writes a server-FPS line to the log each second. Relative number, not a score — compare your server against itself	instrument agreement checked against an independent counter: measured (Windows, ~0.3% at one operating point)
`logMemory` (needs `-doLogs`)	writes memory use to the log	cost of the whole `log` block: measured* below anything we could resolve on an idle server. Whether memory growth tracks the slowdown: unmeasured
`logFile`	keeps console output on disk. Grows without bound — nothing trims it	growth: measured (~19 MB on an idle test server); rate on a busy server: unmeasured
`adminLogPlayerHitsOnly = 0`, `adminLogPlacement`, `adminLogBuildActions`, `adminLogPlayerList` (need `-adminLog`)	the .ADM admin log: hits, placements, building, a periodic player list	keys: verified in the server program (its shipped scripts). Per-player cost on a busy server: unmeasured — our cheap-logging measurement explicitly did not cover these

serverDZ.cfg — simulation and replication keys

The keys the "optimisation" folklore is about. None of them belongs in your config.

setting	what we know	evidence
`simulatedPlayersBatch`	⚠️ Works the opposite way round to how guides describe it. The default is −1: every player is serviced every pass, so writing any positive number is a cap, not an increase. The widely-quoted "default 20" is a sample value from documentation, not the default	default −1: verified in the server program (Windows; Linux default unverified). Cost of capping real players: unmeasured
`multithreadedReplication`	a real key; what it does to a real server is unknown. On an empty test server we could not detect the switch changing anything observable	key: verified in the server program. Effect: unmeasured
`networkObjectBatchCompute` / `SendCreate` / `SendDelete`	real keys; the pasted values (1000 / 10 / 10) trace to documentation whose "defaults" have been wrong before	keys: verified in the server program (both platforms). Defaults: vendor documentation, unverified. Effect of writing them: unmeasured
`networkObjectBatchSend`	documented by Bohemia for over a year, then removed from their docs; the name is still in the server program on both platforms. Whether it does anything today	key name: verified in the server program (both platforms). Effect: unmeasured
`networkObjectBatchLogSlow`	logs slow replication batches. Default is −1.0 (off) — the "default 5" quoted in guides is wrong	default: verified in the server program (Windows)
`entitySimulationMultiThreaded`	off by default. ⚠️ Turning it on cost +80 µs per frame on an idle Windows test server — the largest single-key cost we have measured — with nothing to simulate. Under real load it could be better or worse; nobody knows	idle cost: measured (Windows, empty server, two instruments). At load: unmeasured
`entitySimulationPerformingCatchup`	a real key name in the server program; effect unknown	key name: verified in the server program. Effect: unmeasured

Launch parameters

parameter	what it does	evidence
`-config`, `-port`, `-profiles`, `-BEpath`, `-mod`, `-serverMod`	plumbing: which config, port, profile dir, BattlEye dir, and mods to load	plumbing
`-doLogs`	enables the `log*` config keys above	measured in daily use — with the flag the logs appear, without it they do not
`-adminLog`	enables the .ADM admin log	measured in daily use — same
`-freezeCheck`	a freeze detector: first `FROZEN_` crash dump within about ten seconds of a freeze, another every ten seconds or so after. ⚠️ It marked our test server for a forced crash after about five minutes but did not actually terminate it — a genuinely wedged server sat there until it recovered on its own. If you need automatic recovery, run an external watchdog	measured (Windows, one kind of induced freeze; Linux and other freeze kinds unmeasured)
`-cpuCount`	⚠️ Does not size the helper-thread pool, despite nearly every guide saying it does — `maxcores` in `dayzsetting.xml` does. We have seen no sign the flag costs anything, and no sign it does anything	measured (Windows): raising `maxcores` created helper threads and silenced the too-few-workers warning; `-cpuCount` (confirmed received) created none
`-limitFPS`	caps the server's frame rate. A way to share a machine, not a way to speed a server up — see the guide. ⚠️ The value you ask for is not necessarily the value you get: on Windows delivered rates snap to a coarse timer grid (asking 200, 180 or 100 all delivered ~64; 60 delivered ~32; 30 delivered ~16). On Linux, a 200 cap delivered ~190 on our servers, and values above 200 are clamped to 200. Always read `Average server FPS` after setting it	Windows grid: measured (7 values). Linux 200→~190 and the >200 clamp: measured. Full Linux value ladder: queued — see the lab

dayzsetting.xml

A small file beside the server executable that almost no guide mentions — and it holds the knob -cpuCount is believed to be.

setting	what it does	shipped value	evidence
`maxcores`	sizes the pool of helper ("job") threads	2	measured (Windows): raising it creates helper threads. Whether more helpers improve anything a player feels: unmeasured
`reservedcores`	cores held back from that pool	1	shipped files; behaviour beyond the count: unmeasured

Economy (`db/globals.xml`)

All six values below are Bohemia's shipped values — checked against an untouched install.

setting	what it does	shipped value	evidence
`ZombieMaxCount`	cap on infected alive at once. Count is not cost: with nobody nearby, spawned infected consumed no simulation time we could measure — what costs is infected near players	1000	value: shipped files. Idle-count null: measured (empty server). Cost at population: unmeasured
`AnimalMaxCount`	cap on animals	200	value: shipped files
`CleanupLifetimeDeadPlayer`	seconds a player corpse persists	3600	value: shipped files. Performance effect of shortening: unmeasured
`CleanupLifetimeDeadInfected`	seconds an infected corpse persists	330	value: shipped files. Same
`CleanupLifetimeDeadAnimal`	seconds an animal corpse persists	1200	value: shipped files. Same
`CleanupLifetimeRuined`	seconds ruined items persist	330	value: shipped files. Same

Settings that do not exist

Names invented by guides. The engine silently ignores unknown keys, so pasting these "works" — it just does nothing. Listed so nobody re-imports them.

claimed setting	where it circulates	the reality
`quantityOfZombiesMultiplier` (as a serverDZ.cfg key)	hosting-company guides	not in the server program, the docs, or any shipped file. Infected volume is controlled by `ZombieMaxCount` and the mission's event/territory files
`lootProxySpawnReductionRadiusMax`	hosting-company guides	not in the server program, the docs, or any shipped file. Loot placement is controlled from `globals.xml`
`cleanupLifetimeDeadPlayer` (as a serverDZ.cfg key)	hosting-company guides	a real setting — in the wrong file. It lives in `db/globals.xml`, not `serverDZ.cfg`

Settings Bohemia ships that the server ignores

Worse than folklore, because "it's in the official example" feels like proof. It is not.

setting	where it ships	the reality
`guaranteedUpdates`	Bohemia's example `serverDZ.cfg`, and nearly every guide	not read by the server program on Windows or Linux — the name appears nowhere in either executable, while every setting that is read appears in an obvious list beside its neighbours. Harmless to leave; pointless to tune; any guide describing what it "costs" is describing a setting the server never reads
`disableColdAreaBuildingCheck`	the shipped `cfggameplay.json`	the game script's actual member is named `…PlacementCheck`, so the shipped key is silently ignored

This page is maintained against our internal, evidence-tiered key research; rows change when a measurement lands. What is queued to be measured next — with the pass/fail thresholds fixed before the data — is on the performance lab page. Corrections to previously published claims are logged on the performance guide.