Velocity oder BungeeCord: Server-Netzwerk richtig aufbauen

Ein Proxy ist ein Zwischenserver, mit dem sich Spieler verbinden und der sie an einzelne Backend-Server für Lobby, Survival, Creative und Minigames weiterleitet, sodass sie zwischen Welten wechseln, ohne das Spiel zu verlassen. BungeeCord und Velocity erledigen beide genau diese Aufgabe: BungeeCord ist älter und breit unterstützt, Velocity ist moderner, schneller und dank Modern Forwarding, also der signierten Weitergabe der Spielerdaten, deutlich sicherer. Der Proxy selbst braucht kaum Arbeitsspeicher, 512 MB reichen meistens und kosten bei MC-Node 0,50 Euro pro Monat, aber jeder Backend-Server dahinter braucht seinen eigenen RAM.

Was macht ein Proxy eigentlich?

Ohne Proxy verbindet sich dein Client direkt mit einem Minecraft-Server. Mit Proxy verbindet er sich mit dem Proxy, und der öffnet dahinter seine eigene Verbindung zu einem Backend-Server. Wechselst du den Server, trennt der Proxy diese hintere Verbindung und baut eine neue zum nächsten auf. Deine eigene Verbindung bleibt bestehen, du siehst also nur kurz den Ladebildschirm und nicht wieder die Serverliste.

Der Proxy betreibt selbst keine Welt: keine Chunks, also keine geladenen Weltabschnitte, keine Mobs, kein Redstone. Er hält Verbindungen offen, schiebt Datenpakete weiter und verwaltet die Spielerliste. Deshalb reichen 512 MB für einen Proxy praktisch immer, während derselbe Arbeitsspeicher bei einem Survival-Server zu nichts führt. Angenehmer Nebeneffekt: Der Proxy ist die einzige Adresse, die deine Spieler kennen, und damit auch der Punkt, an dem du deinen DDoS-Schutz ansetzt.

Was ist der Unterschied zwischen BungeeCord und Velocity?

BungeeCord stammt aus der Spigot-Ecke und war jahrelang der Standard; so gut wie jede alte Anleitung dreht sich darum. Velocity kommt vom Team hinter Paper und macht zwei Dinge anders: wie Verbindungen abgewickelt werden und wie ein Backend prüft, dass ein Spieler wirklich über den Proxy hereinkommt. Waterfall, der BungeeCord-Ableger desselben Paper-Teams, wird nicht mehr weiterentwickelt und verweist selbst auf Velocity.

Plugins sind nicht austauschbar: Ein BungeeCord-Plugin läuft nicht auf Velocity, denn dahinter steckt eine andere Programmierschnittstelle. Von dem, was du auf einem Proxy haben willst, etwa LuckPerms und ViaVersion, gibt es aber eigene Velocity-Builds. Wenn du jetzt neu anfängst, ist Velocity die logische Wahl. Läufst du schon seit Jahren auf BungeeCord mit Plugins, zu denen es keine Velocity-Version gibt, kannst du problemlos dabei bleiben, solange die Absicherung sitzt.

Wie viel RAM brauchst du für ein Netzwerk?

Rechne pro Backend, nicht für das Netzwerk als Ganzes. Jedes Backend ist ein vollwertiger Minecraft-Server mit eigener Welt, eigenen Plugins und einem eigenen Java-Prozess. Vier Server heißt also vier Mal Arbeitsspeicher reservieren; der Proxy ist dabei das billigste Glied in der Kette.

Achte auf die Falle: 8,5 GB verteilt auf vier Server sind nicht dasselbe wie ein einzelner Server mit 8,5 GB. Jeder Java-Prozess bringt eigenen Verwaltungsaufwand und eigene geladene Chunks mit, du verlierst also allein dadurch Arbeitsspeicher, dass es vier Server sind. Bau erst dann ein Netzwerk, wenn du die getrennten Welten wirklich brauchst. Wie du einen einzelnen Server aufsetzt, steht in der Anleitung zum Erstellen eines Minecraft-Servers.

Wie richtest du einen Velocity-Proxy ein?

Erst der Proxy, dann die Backends, dann testen. In einem Panel wie Pterodactyl legst du den Proxy als eigenes Paket mit einem eigenen Port an.

1. Setz Velocity auf ein Paket mit 512 MB und starte es einmal, damit velocity.toml und forwarding.secret angelegt werden.
2. Trag in velocity.toml die Werte online-mode = true und player-info-forwarding-mode = "modern" ein.
3. Trag unter [servers] die internen Adressen und Ports deiner Backends ein, dazu eine try-Liste, die festlegt, wo Spieler ankommen, normalerweise in der Lobby.
4. Setz auf jedem Backend in server.properties, der zentralen Einstellungsdatei, den Wert online-mode=false; die Anmeldung prüft ab jetzt der Proxy.
5. Setz auf jedem Paper- oder Purpur-Backend in config/paper-global.yml unter proxies.velocity die Option enabled: true und trag den Inhalt von forwarding.secret in das Feld secret ein.
6. Starte alles neu, verbinde dich mit der Proxy-Adresse und springe mit /server zwischen deinen Backends hin und her.

Bei BungeeCord läuft es anders: Dort setzt du in config.yml die Option ip_forward: true und auf jedem Backend in spigot.yml die Option bungeecord: true. Diese Kombination hat keinerlei Prüfung eingebaut, genau dafür brauchst du BungeeGuard.

Warum kommt jeder einfach so auf deine Backend-Server?

In einem Netzwerk prüft nur der Proxy, ob jemand wirklich der ist, der er zu sein behauptet. Die Backends setzen online-mode deshalb auf false: Sie sehen nur noch Verkehr, den der Proxy bereits geprüft hat. Das ist völlig in Ordnung, bis ein Backend-Port auch aus dem Internet erreichbar ist.

Dann kann nämlich jeder diesen Port in seine Serverliste eintragen, sich einen beliebigen Benutzernamen aussuchen und hereinspazieren. Es gibt keine Prüfung mehr, also liegt auch der Name deines Serverbesitzers mit OP-Rechten offen. Eine Whitelist hilft nicht: Der Server glaubt dem Namen, den der Client angibt, ein Angreifer trägt also einfach einen Namen von der Whitelist ein. Das ist mit Abstand der häufigste Grund, warum kleine Netzwerke zum Ziel von Griefing werden.

So machst du die Lücke dicht

• Nutze Modern Forwarding. Velocity signiert die Spielerdaten mit dem Geheimnis aus forwarding.secret; ein Backend, das dieses Geheimnis kennt, weist alles ab, was nicht korrekt signiert ist.
• Bei BungeeCord: installiere BungeeGuard. Die alte Legacy-Weiterleitung der IP vertraut blind auf das, was hereinkommt. BungeeGuard ergänzt ein geteiltes Kennwort und stopft dieselbe Lücke.
• Begrenze den Netzwerkverkehr. Lass die Backends nur auf einer internen Adresse lauschen oder erlaube in der Firewall ausschließlich die IP des Proxys. Wenn du nicht weißt, wie das in deinem Panel geht, frag den Support.
• Teste es selbst. Tipp Adresse und Port eines Backends direkt in deinen Client. Kommst du rein, ist die Lücke noch offen; bekommst du eine Fehlermeldung zur Weiterleitung, passt es.

Wiederhole diesen letzten Test, sobald du ein Backend hinzufügst: Ein neuer Server startet mit Standardeinstellungen und damit ohne gesicherte Weiterleitung.

Was ändert sich an deinen Plugins?

Ein Netzwerk teilt gar nichts von allein. Jedes Backend hat einen eigenen Weltordner und eigene Spielerdaten, wer also auf Survival ein volles Inventar hat, steht auf Creative mit leeren Händen da, es sei denn, ein Plugin legt diese Daten in einer gemeinsamen Datenbank ab. Bei Rängen ist es einfacher: Mit LuckPerms lassen sich alle Server auf dieselbe MySQL-Datenbank zeigen, dann gilt ein Rang überall. Lass LuckPerms auch auf dem Proxy selbst laufen, denn Proxy-Befehle haben eigene Rechte.

Plugins, die an der Welt hängen, also WorldGuard, WorldEdit, CoreProtect und GriefPrevention, bleiben auf dem jeweiligen Backend. ViaVersion und ViaBackwards wandern dagegen auf den Proxy, damit abweichende Client-Versionen schon an der Eingangstür abgefangen werden; dasselbe gilt für Geyser mit Floodgate für Bedrock-Spieler. Den Chat vergessen die meisten: Spieler in der Lobby bekommen vom Survival-Chat standardmäßig nichts mit, und DiscordSRV läuft pro Server. Welche Plugins wohin gehören, steht in der Übersicht nützlicher Minecraft-Plugins.

Wann brauchst du gar keinen Proxy?

Öfter, als du denkst. Willst du nur eine Creative-Welt neben deiner Survival-Welt, geht das innerhalb eines einzigen Servers mit einem Plugin zur Weltenverwaltung. Das spart dir einen Proxy, ein zusätzliches Paket und noch eine Sache, die kaputtgehen kann. Bei einer kleinen, festen Spielergruppe steckst du das gesparte Geld besser in RAM für deinen Hauptserver.

Modpacks sind der zweite Fall. Proxies und Modloader vertragen sich nur mäßig, und schwere Packs sind teuer zu verdoppeln: All the Mods 10 verlangt mindestens 10 GB und 12 GB für eine kleine Gruppe, jedes zusätzliche Backend verdoppelt diese Anforderung also sofort. Ein einzelner, gut eingestellter Server ist dann die klügere Wahl; genau darum geht es im Artikel zur Serveroptimierung.

Denk auch daran, dass ein Proxy ein zentraler Punkt ist: Fällt er aus, ist dein ganzes Netzwerk nicht mehr erreichbar, selbst wenn die Backends weiterlaufen. Fang also nicht damit an, bevor ein einzelner Server rundläuft. Was die einzelnen Bausteine kosten, siehst du beim Minecraft-Hosting von MC-Node, inklusive des 512-MB-Proxys für 0,50 Euro.

Häufig gestellte Fragen

Kann ich meine BungeeCord-Plugins auf Velocity betreiben? Nein, Velocity hat eine eigene Programmierschnittstelle und lädt keine BungeeCord-Plugins. Von den bekannten Namen gibt es aber Velocity-Builds, darunter LuckPerms, ViaVersion und Geyser mit Floodgate. Geh deine Liste durch, bevor du wechselst: Gerade kleine, selbst gebaute Plugins haben oft keine Velocity-Version.

Wie viel RAM braucht der Proxy selbst? 512 MB reichen für die meisten Netzwerke, bei MC-Node 0,50 Euro pro Monat, weil ein Proxy keine Welt tickt und keine Chunks lädt. Wächst dein Netzwerk stark, stößt du eher an CPU und Netzwerk als an den Arbeitsspeicher. Dein RAM gehört auf die Backends.

Muss online-mode auf meinen Backend-Servern auf false stehen? Ja, denn der Proxy hat den Spieler bereits bei Mojang verifiziert, und eine zweite Prüfung auf dem Backend schlägt fehl. Setz online-mode beim Proxy auf true und bei den Backends auf false, und sorge dafür, dass diese Backends nur über den Proxy erreichbar sind, mit Modern Forwarding oder BungeeGuard. Ohne diesen letzten Schritt kommt jeder mit jedem beliebigen Namen herein.

Teilt ein Netzwerk Inventar und Ränge automatisch? Nein. Jedes Backend führt eigene Welt- und Spielerdaten, Inventare und Endertruhen sind also voneinander getrennt. Ränge teilst du, indem LuckPerms auf allen Servern und auf dem Proxy auf dieselbe MySQL-Datenbank zeigt; für das Inventar brauchst du ein eigenes Plugin mit gemeinsamem Speicher.

Kann ich ein Modpack wie All the Mods 10 hinter einen Proxy setzen? Technisch geht das manchmal, meistens lohnt es sich aber nicht. ATM10 läuft auf NeoForge mit Minecraft 1.21.1 und verlangt mindestens 10 GB und 12 GB für eine kleine Gruppe, jedes zusätzliche Backend schlägt also hart zu Buche. Ein einzelner guter Server ist dann die bessere Wahl.

Weiterlesen

• Geyser und Floodgate: Bedrock-Spieler auf deinem Java-Server
• Paper, Spigot, Purpur oder Vanilla: welche Serversoftware?
• Datapacks, Mods und Plugins: Wo liegt der Unterschied?