DayZ-Server richtig konfigurieren: Performance und Stabilität verstehen

Par Benjamin D. · PDG

4. September 2026 · Mis à jour le 4. September 2026 · Lecture 9 min

Inhaltsverzeichnis

Eine saubere DayZ Server Konfiguration entscheidet darüber, ob 60 Spieler flüssig durch Chernarus laufen oder ob Zombies teleportieren, Loot verschwindet und Clients beim Login hängen bleiben. In diesem Artikel geht es um die Parameter der serverDZ.cfg, um Server-FPS und Netzwerklast, um realistischen RAM-Bedarf je nach Modliste und um die Verbindungsfehler, die im Alltag am häufigsten auftreten.

DayZ Server Konfiguration: was die serverDZ.cfg wirklich steuert

Die serverDZ.cfg liegt im Root-Verzeichnis der DayZ-Serverdateien und wird beim Start über den Parameter -config=serverDZ.cfg geladen. Sie steuert Spielerlimit, Zeitzyklus, Netzwerk-Sichtweiten, Logging und die Missionszuweisung. Viele Performance-Probleme sind keine Hardware-Probleme, sondern Folge von zu großzügig gesetzten Netzwerkwerten oder aktiviertem Debug-Logging im Dauerbetrieb.

Eine funktionale Basiskonfiguration sieht in etwa so aus:

hostname = "Chernarus Hardcore | PvE/PvP";
password = "";
passwordAdmin = "EinLangesAdminPasswort!2024";
enableWhitelist = 0;
maxPlayers = 60;

verifySignatures = 2;
forceSameBuild = 1;
disableVoN = 0;
vonCodecQuality = 20;

disable3rdPerson = 1;
disableCrosshair = 1;
disablePersonalLight = 1;

serverTime = "SystemTime";
serverTimeAcceleration = 12;
serverNightTimeAcceleration = 2;
serverTimePersistent = 1;

guaranteedUpdates = 1;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 500;
instanceId = 1;
storageAutoFix = 1;

steamQueryPort = 27016;
respawnTime = 5;
timeStampFormat = "Short";
logAverageFps = 60;
logMemory = 60;
logPlayers = 60;
logFile = "server_console.log";

adminLogPlayerHitsOnly = 0;
adminLogPlacement = 0;
adminLogBuildActions = 0;
adminLogPlayerList = 0;

enableDebugMonitor = 0;
allowFilePatching = 0;
simulatedPlayersBatch = 20;
multithreadedReplication = 1;
speedhackDetection = 1;

networkRangeClose = 20;
networkRangeNear = 150;
networkRangeFar = 1000;
networkRangeDistantEffect = 4000;

defaultVisibility = 1375;
defaultObjectViewDistance = 1375;

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

Die drei Werte mit dem größten Hebel auf die Serverlast sind networkRangeFar, defaultObjectViewDistance und simulatedPlayersBatch. Wer networkRangeFar von 1000 auf 2000 hochzieht, verdoppelt grob die Menge an Entities, die pro Spieler synchronisiert werden. Auf einer stark bebauten Karte mit vielen Basen ist das der schnellste Weg zu einbrechenden Server-FPS.

Wenn du die Konfiguration lieber direkt an einem lauffähigen System testen willst, statt lokal eine Instanz nachzubauen: bei Fly-Serv kannst du einen DayZ Server mieten und die serverDZ.cfg direkt über den Dateimanager des Pterodactyl-Panels bearbeiten, mit Live-Konsole und automatischen Sicherungen im Hintergrund.

Startparameter: der zweite Teil der Konfiguration

Ein Teil des Verhaltens wird nicht in der cfg-Datei, sondern in der Startzeile definiert. Typisch für einen Linux-Server:

./DayZServer -config=serverDZ.cfg \
  -port=2302 \
  -profiles=profiles \
  -BEpath=battleye \
  -mod=@CF;@VPPAdminTools;@Community-Online-Tools \
  -servermod=@ServerSideModOnly \
  -cpuCount=4 \
  -dologs -adminlog -netlog -freezecheck

-cpuCount: sollte der Anzahl der real verfügbaren Kerne entsprechen. Ein höherer Wert bringt nichts und erzeugt zusätzlichen Scheduling-Overhead.
-mod: Clientseitige Mods, die jeder Spieler laden muss. Reihenfolge ist relevant – Framework-Mods wie CF gehören nach vorn.
-servermod: Serverseitige Mods, die der Client nicht besitzt. Wer hier clientseitige Mods einträgt, produziert direkt Verbindungsfehler.
-freezecheck: erzeugt einen Crashdump statt eines endlos hängenden Prozesses. Für die Fehlersuche unverzichtbar.
-netlog: nur temporär aktivieren, es schreibt viel auf die Platte.

Server-FPS, Tickrate und Latenz richtig einordnen

DayZ arbeitet nicht mit einer festen Tickrate wie viele Shooter. Die Simulationsrate ist an die Server-FPS gekoppelt: fällt der Serverprozess auf 8–10 FPS, sinkt die Update-Frequenz für KI, Physik und Netzwerksynchronisation entsprechend. Genau das erleben Spieler als teleportierende Infizierte, verzögerte Türinteraktionen und Loot, der erst nach Sekunden erscheint.

Server-FPS auslesen

Mit logAverageFps = 60; schreibt der Server jede Minute einen Durchschnittswert in die Konsole. In der Live-Konsole des Panels oder in der server_console.log findest du Zeilen dieser Art:

Average server FPS: 34.21 (over 60 seconds)
Used memory: 5 812 340 kB

Praktische Orientierung aus dem Betrieb:

Server-FPS	Spielgefühl	Handlungsbedarf
> 30	Sauber, KI reagiert direkt	keiner
15–30	Leichte Verzögerungen bei vollem Server	Netzwerkwerte und Modliste prüfen
8–15	Zombie-Rubberbanding, spürbarer Delay	View Distance senken, CE-Limits prüfen
< 8	Unspielbar, Kicks häufen sich	Mods/Basen-Anzahl reduzieren, CPU-Takt prüfen

Warum der CPU-Takt wichtiger ist als die Kernanzahl

Die Simulationsschleife von DayZ ist stark singlethread-lastig. Replikation lässt sich mit multithreadedReplication = 1; auslagern, aber der Hauptthread bleibt der Flaschenhals. Deshalb bringt eine CPU mit hoher Taktfrequenz pro Kern – etwa aktuelle Ryzen-Generationen – deutlich mehr als eine Maschine mit vielen langsamen Kernen. Auf geteilter Hardware ohne feste Kernzuteilung schwanken die Server-FPS zusätzlich, weil Nachbarinstanzen Rechenzeit ziehen.

Storage und Central Economy

Die Central Economy schreibt permanent Persistence-Daten. Jede geöffnete Kiste, jede platzierte Wand, jeder gespawnte Loot-Eintrag landet irgendwann in storage_1. Auf klassischen Festplatten führen die CE-Loops zu spürbaren Frame-Einbrüchen im Minutentakt; auf NVMe-SSDs verschwindet dieses Muster praktisch komplett. Prüfe zusätzlich die Datei cfgeconomycore.xml und die types.xml: sehr hohe nominal-Werte erhöhen die Anzahl aktiver Entities dauerhaft und kosten Simulationsleistung.

<type name="AKM">
    <nominal>8</nominal>
    <lifetime>7200</lifetime>
    <restock>1800</restock>
    <min>4</min>
    <quantmin>-1</quantmin>
    <quantmax>-1</quantmax>
    <cost>100</cost>
</type>

Ein zu kurzes lifetime in Kombination mit hohem restock erzeugt ständiges Despawnen und Neuspawnen – unnötige Last ohne Mehrwert für die Spieler.

RAM-Bedarf je nach Modliste realistisch planen

Der Arbeitsspeicher ist bei DayZ die zweite harte Grenze. Der Serverprozess lädt Map, Missionsdaten und sämtliche Modinhalte in den Speicher. Mit logMemory = 60; siehst du den tatsächlichen Verbrauch minütlich im Log – das ist die einzige verlässliche Basis für die Planung.

Setup	Typischer RAM-Bedarf	Anmerkung
Vanilla Chernarus, 30–40 Slots	ca. 3–4 GB	stabil, kaum Wachstum
Vanilla Livonia, 50–60 Slots	ca. 4–5 GB	kleinere Karte, dichtere Objekte
Leichte Modliste (5–10 Mods, QoL)	ca. 6–8 GB	CF, Admin Tools, Traderpakete
Mittlere Modliste (15–25 Mods, Waffen, Fahrzeuge)	ca. 8–12 GB	Wachstum über die Wipe-Laufzeit beachten
Große Modpacks / Custom Maps (Namalsk, Deer Isle, Expansion)	12–16 GB und mehr	Custom Maps laden zusätzliche Terraindaten

Speicherfresser identifizieren

Custom Maps wie Deer Isle oder Banov bringen eigene Terrain- und Objektdaten mit und liegen beim Grundverbrauch deutlich über Chernarus.
Expansion-Pakete mit Fahrzeugen, Basenbau und Marktsystem addieren mehrere Gigabyte und erhöhen gleichzeitig die Entity-Zahl.
Basenbau über Wochen: Der RAM-Verbrauch steigt zwischen zwei Wipes kontinuierlich. Ein Server, der frisch mit 8 GB startet, kann nach sechs Wochen bei 11 GB liegen. Plane immer 20–30 % Reserve ein.
Aktives Admin-Logging (adminLogPlacement, adminLogBuildActions) erzeugt zusätzlichen Speicher- und I/O-Druck.

Mods sauber aktualisieren

Version-Mismatches zwischen Server und Client sind die häufigste Ursache für Login-Probleme nach einem Workshop-Update. Auf einem selbst verwalteten Linux-System läuft das Update über SteamCMD:

steamcmd +force_install_dir /home/dayz/server \
  +login anonymous \
  +workshop_download_item 221100 1559212036 \
  +quit

# Keys nach jedem Mod-Update neu kopieren
cp /home/dayz/server/steamapps/workshop/content/221100/*/keys/*.bikey \
   /home/dayz/server/keys/

Vergessene .bikey-Dateien im keys/-Ordner sind bei verifySignatures = 2; ein sofortiger Verbindungsabbruch. Im Panel lässt sich derselbe Schritt über die Dateiverwaltung erledigen; wer stattdessen alles selbst orchestriert, arbeitet direkt auf einem Linux VPS mit eigenem Update-Skript.

Häufige Verbindungsfehler und ihre Behebung

„Bad version, server rejected connection"

Client und Server laufen auf unterschiedlichen Buildnummern, oder eine Mod-Version weicht ab. Prüfe zuerst, ob der Server nach dem letzten Spielpatch neu geladen wurde. forceSameBuild = 1; ist bewusst strikt – auf 0 setzen ist keine Lösung, sondern erzeugt später schwer reproduzierbare Desyncs. Nach jedem größeren Update: Serverdateien aktualisieren, alle Workshop-Mods neu ziehen, Keys erneuern.

„You cannot play/edit this mission; it is dependent on downloadable content that has been deleted"

Eine Mod ist im Startparameter eingetragen, aber der Ordner fehlt oder ist unvollständig. Kontrolliere die exakte Schreibweise inklusive @-Präfix und Groß-/Kleinschreibung – Linux ist hier case-sensitive, Windows nicht. Ein Mod, der lokal funktioniert und auf dem Server scheitert, ist fast immer ein Schreibfehler im Ordnernamen.

Server erscheint nicht im Launcher

Der Launcher liest den Steam-Query-Port, nicht den Spielport. Standard ist 27016, gesetzt über steamQueryPort in der cfg. Wenn Port 2302 offen ist, aber 27016 nicht, kann man per Direktverbindung joinen, sieht den Server aber in keiner Liste. Auf einer selbst verwalteten Maschine:

sudo ufw allow 2302:2305/udp
sudo ufw allow 27016/udp
sudo ufw status numbered

Beachte, dass DayZ mehrere aufeinanderfolgende UDP-Ports belegt. Nur 2302 freizugeben reicht nicht.

„Connecting…" bleibt hängen oder Spieler landen im Queue-Limbo

Meist eine Kombination aus großer Modliste und langsamem Storage. loginQueueConcurrentPlayers = 5; begrenzt, wie viele Spieler gleichzeitig geladen werden – nach einem Neustart mit voller Warteschlange verhindert das, dass der Server unter der Ladelast einbricht. Wer den Wert zu hoch setzt, produziert genau die Massentimeouts, die er vermeiden wollte.

„Session Lost" / BattlEye-Kicks

Prüfe den Pfad -BEpath=battleye und die BEServer_x64.cfg im Profilordner. Ein leeres oder schwaches RCon-Passwort ist hier nicht nur ein Sicherheitsrisiko, sondern führt bei fehlerhafter Syntax auch zu abgelehnten Verbindungen:

RConPassword EinSehrLangesRconPasswort_2024
RestrictRCon 0
MaxPing 350

Loot verschwindet, Basen sind nach Neustart weg

Das deutet auf beschädigte Persistence-Daten hin. storageAutoFix = 1; versucht, defekte Storage-Einträge beim Start zu reparieren. Wichtiger ist aber die Sicherung: Der Ordner mpmissions/dayzOffline.chernarusplus/storage_1 gehört in jedes Backup-Konzept. Automatische Sicherungen im Panel nehmen dir diesen Schritt ab – prüfe trotzdem regelmäßig, ob ein Restore auch wirklich funktioniert.

Ping-Spitzen und Paketverlust

Setze pingWarning und pingCritical auf sinnvolle Werte (z. B. 200 / 250), damit du hohe Latenzen im Log siehst statt sie zu erraten. Volumetrische Angriffe werden bei Fly-Serv infrastrukturseitig über den standardmäßig aktiven Anti-DDoS-Schutz abgefangen; was du selbst kontrollierst, sind Serverstandort, Modlast und Netzwerk-Sichtweiten. Wie andere Survival-Titel mit ähnlichen Anforderungen aufgebaut sind, findest du in der Übersicht Alle unsere Gameserver, weitere technische Artikel im Fly-Serv Blog.

Checkliste für die Fehlersuche

Konsole live mitlesen und nach ERROR, Cannot open file und Warning Message filtern.
logAverageFps und logMemory aktivieren, 30 Minuten Vollbetrieb beobachten.
Modliste halbieren und testen – so isolierst du eine problematische Mod in zwei Durchgängen.
Netzwerkwerte schrittweise senken, nicht alle gleichzeitig.
Nach jeder Änderung neu starten und dieselbe Metrik erneut messen.

Die offiziellen Parameterlisten und aktuelle Änderungen findest du in der Community-Dokumentation zur DayZ Server Configuration.

Fazit

Stabilität bei DayZ entsteht aus drei Faktoren: sauber gesetzte Netzwerk- und Sichtweitenwerte, ausreichend Arbeitsspeicher für die tatsächliche Modliste und ein schneller Hauptthread. Wer logAverageFps und logMemory dauerhaft mitschreibt, erkennt Engpässe, bevor die Spieler sie melden. Änderungen immer einzeln testen, Persistence regelmäßig sichern – damit sind die meisten Probleme reproduzierbar lösbar.

FAQ

Wie viel RAM braucht ein DayZ-Server mit 20 Mods für 60 Spieler?

Rechne mit etwa 8–12 GB, abhängig von Kartengröße und Umfang der Mods. Aktiviere logMemory = 60; und beobachte den Verbrauch über mehrere Wochen: Durch Basenbau und Persistence-Daten steigt er zwischen zwei Wipes deutlich an. Plane 20–30 % Reserve über dem Startwert ein.

Warum haben die Spieler niedrigen Ping, aber Zombies rubberbanden trotzdem?

Das ist kein Netzwerkproblem, sondern niedrige Server-FPS. Prüfe den Wert in der Konsole: Unter 15 FPS sinkt die Simulationsrate für KI und Physik. Reduziere networkRangeFar und defaultObjectViewDistance, senke simulatedPlayersBatch und prüfe, ob eine einzelne Mod die Hauptlast erzeugt.

Der Server läuft, taucht aber im Launcher nicht auf – woran liegt das?

Fast immer am Steam-Query-Port. Kontrolliere steamQueryPort = 27016; in der serverDZ.cfg und stelle sicher, dass dieser UDP-Port zusätzlich zu 2302–2305 freigegeben ist. Nach der Änderung ist ein vollständiger Neustart nötig, ein Reload der Mission reicht nicht.