Minecraft-Server richtig einrichten: Software, RAM, Crossplay & Sicherheit

Bildquelle: Midjourney

Ein Minecraft-Server ist in wenigen Minuten gestartet – aber zwischen "läuft" und "läuft gut" liegt ein ganzes Stück Konfigurationsarbeit. Die meisten Ratschläge im Netz bleiben bei "miete dir einen Server" stehen. Hier geht es um das, was danach kommt: die Einstellungen, die wirklich über Lag, Stabilität und Sicherheit entscheiden.

Die Server-Software entscheidet über die halbe Performance

Der größte Hebel ist meist nicht die Hardware, sondern die Wahl der Server-Software. Der offizielle Vanilla-Server von Mojang ist technisch am nächsten am Original, aber auch mit Abstand am ineffizientesten – er nutzt nur einen Kern effektiv aus und bremst schon bei kleinen Gruppen. In der Praxis hat sich Paper (und seine Forks wie Purpur) als Standard durchgesetzt: ein Server-Kern, der zu Vanilla-Welten und -Spielern kompatibel bleibt, aber intern deutlich effizienter arbeitet und zusätzlich Plugins erlaubt. Wer keinen zwingenden Grund für echten Vanilla-Server hat (z. B. eine bestimmte Mod-Loader-Anforderung), sollte direkt mit Paper starten.

RAM richtig zuweisen, nicht raten

Ein weit verbreiteter Fehler: "viel RAM hilft viel". Laut der offiziellen PaperMC-Dokumentation zu den sogenannten Aikar-Flags – einem Satz von Java-Start-Parametern speziell zur Reduzierung von Lag-Spitzen – gilt genau das Gegenteil: Der Server sollte so konfiguriert sein, dass er seinen zugewiesenen Speicher (-Xmx) tatsächlich nutzt, nicht mit übertriebener Reserve laufen. Zwei konkrete Regeln:

• -Xms und -Xmx auf denselben Wert setzen (z. B. beide 6G), damit die Java-VM den Speicherbereich nicht laufend vergrößert und verkleinert – das verursacht spürbare Ruckler.
• Die Aikar-Flags selbst unverändert übernehmen (nur -Xms/-Xmx anpassen) – sie sind für Server jeder Größe ausgelegt und lassen sich direkt aus der offiziellen PaperMC-Doku kopieren.

Für eine kleine Freundesrunde reichen meist 4 bis 6 GB, für 15-20 Spieler mit Plugins eher 8 bis 10 GB. Deutlich mehr zuzuweisen bringt in der Regel keinen Vorteil, sondern kann durch längere Garbage-Collection-Pausen sogar neue Lags erzeugen.

Zwei Stellschrauben, die die meisten übersehen

Neben RAM und Server-Software gibt es zwei serverseitige Einstellungen mit großem Effekt auf die Performance:

• View-Distance und Simulation-Distance senken. Beide Werte stehen in der server.properties und bestimmen, wie viele Chunks um jeden Spieler geladen bzw. aktiv simuliert werden. Der Vanilla-Standard ist für die meisten Gruppen unnötig hoch angesetzt – eine Reduzierung auf 6-8 Chunks spart spürbar Serverlast, ohne dass es den Spielern beim normalen Spielen auffällt.
• Die Welt vorab generieren. Live-Chunk-Generierung während des Spiels ist teuer. Wer vor dem ersten "richtigen" Spielen einmal mit einem Vorgenerierungs-Tool (bei Paper etwa über den Chunky-Plugin-Befehl) einen Radius um den Spawn generiert, verhindert spätere Ruckler beim Erkunden neuer Gebiete.

Java- und Bedrock-Spieler zusammenbringen

Wer eine gemischte Gruppe hat – manche am PC mit der Java-Edition, andere auf Handy, Konsole oder Windows mit der Bedrock-Edition – braucht Crossplay. Laut der offiziellen GeyserMC-Dokumentation funktioniert das über zwei Plugins auf einem Paper- oder Spigot-Server: Geyser übersetzt das Bedrock-Protokoll in das Java-Protokoll, Floodgate erlaubt Bedrock-Spielern den Beitritt ohne teuren Java-Account. Technisch wichtig: Bedrock-Verbindungen laufen über UDP-Port 19132 (Standard), nicht über den üblichen Java-TCP-Port – dieser Port muss beim Hoster bzw. in der eigenen Firewall zusätzlich freigegeben werden, sonst können sich Bedrock-Spieler trotz korrekt installierter Plugins nicht verbinden.

Server absichern: Whitelist, Rollback, Backups

Sobald der Server für mehr als den engsten Freundeskreis offen ist, lohnen sich drei Maßnahmen:

• Whitelist aktivieren. Nur vorher freigegebene Spielernamen dürfen beitreten – der einfachste und wirksamste Schutz gegen zufällige Griefer, die Server-IPs automatisiert abscannen.
• Ein Logging-/Rollback-Plugin einsetzen (in der Praxis weit verbreitet: CoreProtect). Es protokolliert jeden Block-Wechsel und erlaubt es, Schäden durch einen Griefer oder ein fehlerhaftes Plugin gezielt rückgängig zu machen, statt ein komplettes Weltbackup einspielen zu müssen.
• Regelmäßige, externe Backups. Tägliche automatische Sicherungen sind Standard, sobald aktiv gespielt wird – und sie sollten nicht nur lokal auf demselben Server liegen, sondern zusätzlich extern gespeichert werden, damit ein Hardware-Ausfall beim Hoster nicht auch das Backup mitreißt.

Wer zusätzlich mit Grundstücks-Claims arbeiten will (Spieler markieren ihr Baugebiet, das dann automatisch vor fremdem Bauen/Abbauen geschützt ist), findet dafür Plugins wie GriefPrevention – sinnvoll vor allem auf Servern mit mehr Spielern, die sich nicht alle persönlich kennen.

Fazit

Die größten Performance- und Stabilitätsgewinne kommen selten vom teureren Hosting-Paket, sondern von der richtigen Konfiguration: Paper statt Vanilla, korrekt gesetzte RAM-Flags, eine sinnvolle View-Distance und ein einmal vorgenerierter Spawn-Bereich. Wer zusätzlich Whitelist, Rollback-Logging und externe Backups einrichtet, hat die häufigsten Probleme – Lag und Griefing – von Anfang an im Griff. Die vollständige, offizielle Referenz für die RAM-Flags gibt es bei PaperMC, die Crossplay-Einrichtung im Detail bei GeyserMC.