CS2 Server Tuning 2026 – Tickrate, Config & Performance

Warum CS2 Server Tuning 2026 wichtiger denn je ist

Counter-Strike 2 hat die Art und Weise, wie Server mit Spieler-Inputs umgehen, grundlegend verändert. Valve hat mit dem Subtick-System einen Paradigmenwechsel eingeführt: Inputs werden nicht mehr nur zum nächsten Tick verarbeitet, sondern mit Zeitstempeln versehen und zwischen den Ticks ausgewertet. Das bedeutet aber nicht, dass Tickrate, Rates und Hardware-Optimierung obsolet geworden sind – im Gegenteil. Ein schlecht konfigurierter Server fällt 2026 stärker auf als zu CS:GO-Zeiten, weil Spieler bei 128 Tick und subtick-basiertem Netcode sofort spüren, wenn Hit-Registrierung, Interpolation oder Peeker's Advantage nicht sauber laufen.

In diesem Guide zeigen wir dir, wie du einen CS2 Dedicated Server unter Linux (Debian 12 / Ubuntu 24.04) von Grund auf performant aufsetzt. Wir behandeln Tickrate, Launch-Parameter, die optimale server.cfg, Kernel-Sysctl-Tuning, CPU-Governor, Docker-Setups, Monitoring und einen ehrlichen Preisvergleich zwischen Gameserver-Hosting und eigenem Root-Server.

Alle Befehle und Werte sind praxiserprobt und auf dem aktuellen CS2-Build (Stand Q1 2026) getestet. Wer bereits einen Server betreibt, kann direkt bei den Config- und Tuning-Abschnitten einsteigen.

Die richtige Tickrate für CS2: 64 oder 128?

CS2 unterstützt offiziell 128 Tick auf Community-Servern, sofern die Hardware mitspielt. Der Standard liegt bei 64 Tick. Valve betreibt seine offiziellen Premier-Server weiterhin mit 64 Tick, kompensiert das aber durch das Subtick-System. Für Community-Server, ESL-ähnliche Ligen, Faceit-Style-Portale und ambitionierte Publics ist 128 Tick dennoch die bessere Wahl – vorausgesetzt, die CPU stemmt die doppelte Tick-Frequenz.

Der Startparameter lautet schlicht:

./game/cs2.sh -dedicated -console -usercon +game_type 0 +game_mode 1 +map de_dust2 \
  -tickrate 128 -maxplayers_override 12 +sv_setsteamaccount DEIN_STEAM_TOKEN +exec server.cfg

Wichtig: Die Tickrate muss beim Start gesetzt werden. Ein nachträgliches sv_tickrate per RCON existiert nicht. Bei 128 Tick verdoppelt sich die CPU-Last pro Spieler-Input, weshalb du pro CS2-Instanz mindestens 1,5 bis 2 dedizierte CPU-Kerne mit hoher Single-Core-Leistung einplanen solltest.

Faustregel für 2026: 10 Slots bei 128 Tick = 2 Kerne. 20 Slots (Casual) = 3–4 Kerne. Bei mehr als 24 Slots solltest du auf 64 Tick zurückgehen oder horizontal skalieren.

Hardware-Anforderungen: CPU, RAM und NVMe

CS2 ist single-core-hungrig. Eine CPU mit 16 langsamen Kernen schlägt eine mit 8 schnellen Kernen nicht. Empfehlenswert sind Prozessoren mit hohem Boost-Takt und großem L3-Cache:

CPUKerneBoostCS2-Instanzen (128 Tick, 10 Slots)
AMD Ryzen 9 7950X16C/32T5,7 GHz6–8
Intel i9-13900K24C/32T5,8 GHz6–8
AMD Ryzen 7 77008C/16T5,3 GHz3–4
Intel Xeon E-2388G8C/16T5,1 GHz3–4
AMD EPYC 7443P24C/48T4,0 GHz4–5 (Taktlimit)

Beim RAM gilt: 2 GB pro CS2-Instanz plus 2 GB für das Betriebssystem. Ein Server mit vier Instanzen braucht also mindestens 10 GB, realistisch 16 GB. CS2 alloziert beim Map-Load kurzzeitig mehr Speicher, was bei zu knappem RAM zu OOM-Kills führt.

Storage: Eine NVMe-SSD ist Pflicht. Maps wie de_ancient oder de_nuke laden aus dem Workshop-Cache teils über 500 MB. Auf SATA-SSD dauert das Map-Loading 15–25 Sekunden, auf NVMe unter 5 Sekunden. Bei mehreren Instanzen solltest du die Workshop-Dateien über einen gemeinsamen Cache teilen (-noworkshop mit vorab synchronisiertem steamapps/workshop-Verzeichnis).

Betriebssystem-Tuning: Kernel-Sysctl und CPU-Governor

Ein frisch installiertes Debian oder Ubuntu ist für Gaming-Traffic nicht optimiert. Diese Sysctl-Werte gehören in /etc/sysctl.d/99-cs2.conf:

net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.netdev_max_backlog = 30000
net.core.somaxconn = 4096
net.ipv4.udp_mem = 65536 131072 262144
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_low_latency = 1
vm.swappiness = 1
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Danach sysctl --system ausführen. Der wichtigste Wert ist net.core.rmem_max – ohne diesen Wert kann der UDP-Receive-Buffer bei 128 Tick überlaufen, was sich in Form von Rubberbanding und Packet-Loss äußert.

Der CPU-Governor muss auf performance stehen. Standardmäßig schalten moderne CPUs in den powersave-Modus, was Latenz-Spikes von 5–15 ms verursacht:

apt install linux-cpupower -y
cpupower frequency-set -g performance
echo 'GOVERNOR="performance"' | tee /etc/default/cpupower
systemctl enable --now cpupower

Optional kannst du mit isolcpus=2-5 nohz_full=2-5 rcu_nocbs=2-5 in der GRUB-Kommandozeile CPU-Kerne exklusiv für CS2 reservieren und den Scheduler-Tick deaktivieren. Das reduziert Jitter messbar um 20–40 %.

Die optimale server.cfg für CS2

Die server.cfg liegt unter game/csgo/cfg/server.cfg. Für kompetitives Spiel (5v5, MR12) empfehlen wir folgende Basis:

hostname "HOSTAZAR CS2 | 128 Tick | DE"
rcon_password "SICHERES_PASSWORT_HIER"
sv_password ""
sv_lan 0
sv_cheats 0
sv_maxrate 0
sv_minrate 128000
sv_maxupdaterate 128
sv_minupdaterate 64
sv_maxcmdrate 128
sv_mincmdrate 64
sv_client_min_interp_ratio 1
sv_client_max_interp_ratio 2
sv_pausable 0
sv_allow_votes 1
mp_autoteambalance 0
mp_maxrounds 24
mp_roundtime 1.92
mp_freezetime 15
mp_buytime 20
mp_c4timer 40
mp_overtime_enable 1
mp_overtime_maxrounds 6
mp_match_can_clinch 0
mp_team_intro_time 6.5
mp_halftime 1
mp_halftime_duration 15
mp_solid_teammates 1
mp_forcecamera 1
mp_spectators_max 8
mp_limitteams 0
mp_warmuptime 60
mp_warmup_pausetimer 0
mp_endmatch_votenextmap 0
mp_match_end_restart 1
ammo_grenade_limit_total 4
ammo_grenade_limit_flashbang 2
sv_infinite_ammo 0
sv_deadtalk 1
sv_talk_enemy_dead 0
sv_talk_enemy_living 0
sv_full_alltalk 0
sv_auto_full_alltalk_during_warmup_half_end 1

Die Rate-Werte sind der kritischste Teil. sv_maxrate 0 bedeutet "unbegrenzt" und ist für moderne Server mit Gigabit-Uplink korrekt. sv_minrate 128000 (128 KB/s) verhindert, dass Spieler mit schlechter Verbindung das Spielgeschehen verlangsamen. Die Updaterates sollten exakt der Tickrate entsprechen (128/128), damit keine Inputs verworfen werden.

Die sv_client_min_interp_ratio 1 ist für 128 Tick optimal: Sie erlaubt Spielern mit stabiler Verbindung, mit minimaler Interpolation zu spielen, was den Peeker's Advantage reduziert. Wer auf maximalen Kompetitivitäts-Faktor setzt, kann zusätzlich sv_client_predict 1 und sv_client_cmdrate_difference 0 setzen.

Netzwerk-Tuning: Traffic Control und UDP-Optimierung

Auf Servern mit mehreren Instanzen solltest du den ausgehenden Traffic klassifizieren, damit CS2-Pakete bevorzugt behandelt werden. Mit tc (Traffic Control) richtest du eine Prioritätsklasse ein:

tc qdisc add dev eth0 root handle 1: htb default 20
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 800mbit ceil 1000mbit prio 1
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 200mbit ceil 1000mbit prio 2
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
  match ip dport 27015 0xffff flowid 1:10

Wichtiger ist jedoch die Interrupt-Affinity. Bei Multi-Gigabit-Netzwerkkarten (Intel X710, Mellanox ConnectX-5) verteilen IRQs die Last über mehrere Kerne. Mit ethtool -L eth0 combined 4 reduzierst du die Queues auf vier und bindest sie mit irqbalance oder manuell an dedizierte Kerne.

Prüfe regelmäßig den UDP-Puffer-Status mit netstat -su oder ss -u -a. Steigende Werte bei "packet receive errors" oder "receive buffer errors" deuten auf zu kleine Buffer oder überlastete NIC hin. Bei 128 Tick und 20 Spielern fließen etwa 3–5 MBit/s pro Instanz durch die Leitung.

Ein oft übersehener Punkt: IPv6. CS2 unterstützt IPv6 nur eingeschränkt. Deaktiviere es auf dem Server-Interface, um unnötige Verbindungsversuche zu vermeiden: sysctl -w net.ipv6.conf.all.disable_ipv6=1.

SourceMod, Metamod und Plugins 2026

Für Community-Server sind SourceMod (aktuell 1.12+) und Metamod:Source (2.0+) weiterhin Standard. Beachte: CS2 nutzt eine völlig neue Engine-Basis, weshalb viele CS:GO-Plugins nicht mehr funktionieren. Kompatible Plugins findest du auf sourcemod.net und im AlliedMods-Forum.

Plugin-Empfehlungen für Performance und Spielkomfort:

Warnung: Jedes Plugin kostet CPU-Zeit im Tick-Thread. Bei 128 Tick solltest du maximal 8–10 Plugins gleichzeitig aktiv haben. Nutze sm plugins list und sm prof, um CPU-Fresser zu identifizieren. Der SourceMod Profiler zeigt dir pro Plugin die verbrauchten Millisekunden pro Tick – alles über 0,5 ms pro Plugin ist problematisch.

Docker-Setup für CS2 Server

Containerisierung erleichtert Updates und Multi-Instanz-Betrieb. Das beliebteste Image ist joedwards32/cs2. Eine docker-compose.yml für eine 128-Tick-Instanz:

services:
  cs2-1:
    image: joedwards32/cs2:latest
    container_name: cs2-1
    environment:
      SRCDS_TOKEN: "DEIN_STEAM_TOKEN"
      CS2_SERVERNAME: "HOSTAZAR #1 | 128 Tick"
      CS2_PORT: 27015
      CS2_RCONPW: "sicheresPasswort"
      CS2_MAXPLAYERS: 12
      CS2_TICKRATE: 128
      CS2_GAMEALIAS: "competitive"
      CS2_STARTMAP: "de_dust2"
      CS2_ADDITIONAL_ARGS: "-norestart"
    ports:
      - "27015:27015/udp"
      - "27015:27015/tcp"
    volumes:
      - ./cs2-data:/home/steam/cs2-dedicated/
    cpus: "2.0"
    mem_limit: 4g
    restart: unless-stopped

Setze cpus: "2.0" und mem_limit: 4g, um Ressourcen sauber zu begrenzen. Ohne Limits kann eine einzige Instanz bei einem Map-Load alle Kerne fressen und andere Instanzen ausbremsen. Nutze cpuset statt cpus, wenn du harte Kern-Bindung willst: cpuset: "2-3".

Für Multi-Instanz-Setups empfiehlt sich ein gemeinsames Workshop-Volume. CS2 lädt Workshop-Maps in game/csgo/workshop/ – bei fünf Instanzen sind das schnell 30 GB. Ein Read-Only-Mount desselben Verzeichnisses spart Speicher und Bandbreite.

Monitoring: Latenz, Tick-Time und Packet-Loss

Ohne Monitoring fliegst du blind. Die wichtigsten Metriken für einen CS2-Server:

Für kontinuierliches Monitoring empfehlen wir Netdata oder Prometheus + Grafana. Netdata installiert sich in 30 Sekunden und zeigt dir CPU, RAM, Netzwerk und Disk in Echtzeit. Für Multi-Server-Setups lohnt sich ein zentrales Grafana-Dashboard mit Node-Exporter.

CS2-seitig kannst du mit sv_log_onefile 0 und sv_logfile 1 detaillierte Logs schreiben. Analysiere diese mit cs2-log-parser oder Logstash, um wiederkehrende Lags, Map-Crashes oder verdächtige Spieler zu identifizieren.

Preisvergleich: Gameserver-Hosting vs. eigener Root-Server

Für die meisten Admins ist die Wahl zwischen fertigem Gameserver-Hosting und einem eigenen Root-Server die zentrale Kostenfrage. Eine Übersicht (Stand Q1 2026):

Anbieter / ModellSpecsPreis/MonatGeeignet für
Nitrado CS2 12 SlotsShared, 128 Tick8,99 €Einsteiger, Clans
4Netplayers CS2 16 SlotsShared, 128 Tick11,99 €Public-Server
ZAP-Hosting CS2 20 SlotsShared, 128 Tick14,50 €Community
Hetzner Cloud CCX234 vCPU, 16 GB, NVMe26,00 €2–3 Instanzen
Hetzner AX42 (dediziert)Ryzen 7 7700, 64 GB47,00 €4–6 Instanzen
Hetzner AX52 (dediziert)Ryzen 9 7900, 128 GB67,00 €6–10 Instanzen

Die Rechnung ist eindeutig: Ab drei CS2-Instanzen ist ein dedizierter Root-Server günstiger und deutlich performanter. Ein AX42 für 47 € ersetzt sechs Gameserver-Slots im Wert von ~54 € – bei voller Hardware-Kontrolle, eigenem Kernel-Tuning und ohne geteilte CPU. Für einen einzelnen Clan-Server mit 10 Slots ist Nitrado oder 4Netplayers aber bequemer und günstiger.

Wichtig: Achte beim Root-Server auf unmetered Traffic (Hetzner: 20 TB bei dedizierten Servern) und DDoS-Schutz. CS2-Server werden häufig Opfer von UDP-Floods – ohne Schutz ist dein Server binnen Sekunden offline.

Häufige Fehler und Troubleshooting

Die fünf häufigsten Probleme, die wir bei CS2-Setups sehen:

  1. Server startet nicht – meist fehlender sv_setsteamaccount Token. Registriere den Server unter steamcommunity.com/dev/managegameservers.
  2. Rubberbanding trotz guter Hardware – fast immer zu kleiner UDP-Puffer. Prüfe net.core.rmem_max.
  3. Hohe Tick-Time – ein Plugin oder zu viele Spieler pro Kern. Nutze sm prof und mpstat.
  4. Map-Loading dauert ewig – kein NVMe oder kein Workshop-Cache. sv_workshop_allow_other_maps 1 setzen.
  5. Spieler beschweren sich über Hit-Reg – meist Client-seitig (Interp-Ratio, Rates). Erzwinge sv_minrate 128000 und sv_minupdaterate 64.

Für tiefes Debugging nutze net_graph 1 im Client, um die tatsächliche Updaterate zu sehen. Wenn die Client-Rate unter 128 liegt, obwohl der Server 128 Tick fährt, stimmt die Config nicht.

FAQ

Ist 128 Tick bei CS2 überhaupt noch sinnvoll?

Ja, aber der Vorteil ist geringer als in CS:GO. Das Subtick-System verarbeitet Inputs zeitunabhängig, weshalb 64 Tick auf offiziellen Servern kaum Nachteile bringt. Bei Community-Servern mit kompetitivem Anspruch ist 128 Tick dennoch Standard, weil die Updaterate für Clients höher ist und Peeker's Advantage reduziert wird – vorausgesetzt, die CPU schafft die doppelte Last.

Wie viele CS2-Server kann ich auf einem Root-Server betreiben?

Faustregel: 2 dedizierte CPU-Kerne pro 128-Tick-Instanz mit 10 Slots. Ein Hetzner AX42 (Ryzen 7 7700, 8C/16T) stemmt 4–6 Instanzen, ein AX52 (Ryzen 9 7900, 12C/24T) bis zu 10. RAM: 2 GB pro Instanz plus 4 GB für das OS. NVMe ist Pflicht.

Welche server.cfg-Werte sind 2026 am wichtigsten?

Die Rate-Werte: sv_maxrate 0, sv_minrate 128000, sv_maxupdaterate 128, sv_minupdaterate 64. Dazu sv_client_min_interp_ratio 1 und sv_client_max_interp_ratio 2. Diese Werte bestimmen direkt Hit-Registrierung und Peeker's Advantage.

Brauche ich SourceMod für einen CS2-Server?

Für reine Public-Server nicht zwingend. SourceMod (1.12+) und Metamod (2.0+) sind aber Voraussetzung für Match-Management (Get5), Practice-Mode und Admin-Tools. Jedes Plugin kostet Tick-Zeit – halte die Liste unter 10 Plugins.

Lohnt sich ein eigener Root-Server gegenüber Gameserver-Hosting?

Ab drei CS2-Instanzen ja. Ein Hetzner AX42 für 47 €/Monat ersetzt sechs Gameserver-Slots (~54 €) bei deutlich besserer Performance und voller Kernel-Kontrolle. Für einen einzelnen 10-Slot-Clan-Server ist Nitrado (8,99 €) oder 4Netplayers (11,99 €) günstiger und wartungsfreier.