networklatencyoptimizationspigotpaperserver adminpingconnection

Minecraft Server Netzwerk optimieren: Latenz reduzieren und Verbindungsprobleme beheben

Veröffentlicht am 10. Juli 2026

# Minecraft Server Netzwerk optimieren: Latenz reduzieren und Verbindungsprobleme beheben

Hoher Ping und instabile Verbindungen gehören zu den frustrierendsten Problemen auf einem Minecraft-Server – und sie werden oft falsch diagnostiziert. Viele Server-Admins nehmen an, dass Lag immer ein TPS-Problem ist. Dabei können Netzwerkprobleme Rubber-Banding, Teleportationsfehler und Verbindungsabbrüche verursachen, selbst wenn der Server technisch perfekt läuft. Diese Anleitung erklärt jeden Layer des Minecraft-Netzwerkstacks und zeigt dir konkrete Einstellungen zur Lösung.

TPS-Lag vs. Netzwerk-Lag: Was ist der Unterschied?

Bevor du irgendwelche Configs anfasst, musst du wissen, womit du es zu tun hast:

TPS-Lag = der Server-Tick-Loop ist zu langsam (prüfe mit /tps)
Netzwerk-Lag = Pakete werden zwischen Server und Client verzögert, verworfen oder limitiert

Ein Server mit stabilen 20 TPS kann sich trotzdem laggy anfühlen, wenn der Netty-Thread-Pool überlastet ist. Spieler sehen sich dann zu vorherigen Positionen zurückspringen – ein klassisches Zeichen für Netzwerkprobleme.

Die wichtigsten Config-Dateien für Netzwerk-Optimierung

server.properties

Hier fängst du an:

network-compression-threshold=256
rate-limit=0

network-compression-threshold legt die minimale Paketgröße in Bytes fest, ab der Komprimierung angewendet wird. Der Standardwert 256 ist vernünftig. Auf Servern mit schnellen CPUs und langsamerer Netzwerkverbindung kann das Senken auf 128 die Bandbreite reduzieren – auf Kosten von mehr CPU-Last. Auf Servern mit viel CPU-Spielraum ist 128 eine gute Wahl, auf Hochbandbreiten-Servern eher 512.

rate-limit definiert, wie viele Pakete ein Spieler pro Sekunde senden darf, bevor er gekickt wird. Der Standardwert 0 bedeutet kein Limit. Bei Bot-Angriffen oder Paket-Flooding empfiehlt sich 500.

spigot.yml

settings: moved-wrongly-threshold: 0.0625

moved-too-quickly-multiplier: 10.0

moved-too-quickly-multiplier steuert die Bewegungsvalidierung. Wenn legitime Spieler mit hoher Latenz (150–200ms) Rubber-Banding erleben, kann das Erhöhen auf 12.0 helfen. Der Server toleriert dann größere Bewegungsunterschiede, bevor er die Position korrigiert.

paper-global.yml (Paper 1.19+)

Paper bietet dedizierte Netzwerkoptimierungen:

network: max-joins-per-tick: 3

kick-for-out-of-memory: true

max-joins-per-tick verhindert Verbindungsspitzen, wenn viele Spieler gleichzeitig joinen – zum Beispiel nach einem Neustart. Der Wert 3 staffelt Logins und entlastet die Netty-Pipeline. Auf großen Servern mit häufigen Massen-Joins empfiehlt sich 2.

paper-world.yml

entity-tracking-range: players: 48 animals: 48 monsters: 48 misc: 32

other: 64

Entity-Tracking-Range ist eine der wirkungsvollsten Netzwerkoptimierungen. Jede getrackte Entität erzeugt jede Tick Update-Pakete. Das Reduzieren der Spieler-Tracking-Range von 128 auf 48 Blöcke senkt die Downstream-Bandbreite pro Spieler erheblich – ohne das Gameplay nennenswert zu beeinträchtigen.

Für PvP-Server oder Minigame-Server empfehlen sich 64–96 Blöcke. Für Survival-Server sind 48 meist ausreichend.

Netty-Thread-Tuning (JVM-Flags)

Minecraft nutzt Netty für seinen Netzwerklayer. Du kannst die Thread-Anzahl explizit setzen:

-Dio.netty.eventLoopThreads=4

Für Server mit 4+ CPU-Kernen und 50+ gleichzeitigen Spielern verbessert der Wert 4 oder 6 die Konsistenz der Paketverarbeitung. Überschreite dabei nie die Anzahl deiner physischen Kerne.

Paper nutzt auf Linux automatisch epoll (nativer Transport), was deutlich effizienter als Java NIO ist. Stelle sicher, dass dein Server wirklich auf Linux läuft, um diesen Vorteil zu nutzen.

Proxy-Optimierung: BungeeCord und Velocity

Wer ein Server-Netzwerk betreibt, sollte [Velocity](https://papermc.io/software/velocity) statt BungeeCord verwenden. Velocity ist moderner, sicherer und deutlich performanter bei der Paketweiterleitung.

Wichtige Velocity-Einstellungen in velocity.toml:

compression-threshold = 256
compression-level = -1
login-ratelimit = 3000
connection-timeout = 5000
read-timeout = 30000

compression-level = -1 verwendet den Standard-Kompressionsalgorithmus, der eine gute Balance zwischen Geschwindigkeit und Größe bietet. Ein höherer login-ratelimit-Wert hilft, Verbindungsfluten abzufangen, ohne legitime Spieler zu kicken.

Netzwerkstatus in Echtzeit überwachen

Netzwerkprobleme sind notorisch schwer zu reproduzieren. Du brauchst kontinuierliche Einblicke in Paketraten, Ping-Verteilungen und Verbindungsfehler. Genau hier hilft [PulseNode](https://pulsenode.tech): Das Tool überwacht deine Server-Metriken dauerhaft und zeigt dir Latenz-Trends pro Spieler sowie Verbindungsereignisse im zeitlichen Verlauf – so kannst du Netzwerkspitzen mit bestimmten Uhrzeiten, Spielerzahlen oder Plugin-Aktivitäten korrelieren.

Auf dem Server selbst bietet Paper nützliche Diagnose-Befehle:

/ping <Spieler> — Latenz eines bestimmten Spielers prüfen

/mspt — durchschnittliche Server-Tick-Zeit

Für OS-seitiges Netzwerk-Monitoring unter Linux:

ss -s # Socket-Zusammenfassung netstat -an | grep :25565 # aktive Verbindungen auf dem Minecraft-Port

iptables -L -n -v # Firewall-Regeln prüfen

Firewall und Port-Konfiguration

Stelle sicher, dass deine Firewall den Minecraft-Traffic nicht drosselt. Mit UFW:

ufw allow 25565/tcp

ufw allow 25565/udp

Überprüfe auch, ob dein Hosting-Anbieter DDoS-Schutzmaßnahmen einsetzt, die legitimen Spieler-Traffic limitieren – ein häufiges Problem bei Budget-VPS-Anbietern.

Zusammenfassung: Netzwerk-Optimierungs-Checkliste

[ ] network-compression-threshold auf 128–256 setzen (abhängig von CPU/Bandbreite)
[ ] Entity-Tracking-Ranges in paper-world.yml reduzieren
[ ] max-joins-per-tick: 3 in paper-global.yml setzen
[ ] moved-too-quickly-multiplier erhöhen bei Rubber-Banding mit hoher Latenz
[ ] Velocity statt BungeeCord für Proxy-Setups verwenden
[ ] Netty-Event-Loop-Threads explizit für Hochlast-Server konfigurieren
[ ] Firewall-Regeln für TCP/UDP auf Port 25565 prüfen
[ ] Ping pro Spieler und Verbindungsereignisse kontinuierlich überwachen

Netzwerkoptimierung ist ein fortlaufender Prozess. Eine Einstellung, die bei 20 Spielern funktioniert, muss bei 100 Spielern möglicherweise angepasst werden. Kontinuierliches Monitoring ist der Unterschied zwischen Raten und Wissen.

---

Willst du aufhören zu raten, wann Netzwerkprobleme auftreten? [PulseNode](https://pulsenode.tech) bietet dir Echtzeit-Server-Monitoring mit historischen Daten – damit du Latenz-Muster erkennst, bevor deine Spieler es tun.