BungeeCord und Velocity einrichten: ein Netzwerk aus Minecraft-Servern

BungeeCord und Velocity einzurichten brauchst du, wenn du mehrere Minecraft-Server zu einem Netzwerk verbinden willst — Lobby, Survival, Minispiele — unter einer gemeinsamen IP, mit Wechseln zwischen den Welten ohne Neuverbindung. Für neue Projekte greift man heute zu Velocity statt zu BungeeCord: Es ist schneller und sicherer. In diesem Guide sehen wir uns beide Proxys und ihre Configs an und bauen Schritt für Schritt ein Netzwerk auf.

Wozu du überhaupt einen Proxy brauchst

Ein Minecraft-Server bedeutet eine Welt und eine Art von Gameplay. Sobald du eine Lobby mit Portalen in verschiedene Spielmodi, einen eigenen Survival-Server und ein paar Minispiele willst, fangen die Probleme an: Jeder hat seine eigene IP, der Spieler fliegt bei jedem Wechsel raus und verbindet sich neu, und Inventare und Sitzungen sind nicht verknüpft.

Ein Proxy löst das. Er wird zum einzigen Einstiegspunkt: Der Spieler verbindet sich mit einer Adresse, während der Proxy im Hintergrund die Verbindung hält und ihn per Befehl /server oder über Portale zwischen den Backend-Servern hin- und herschiebt. Für den Spieler sieht das wie ein sofortiger Teleport zwischen den Welten eines Netzwerks aus — ohne Neu-Login und ohne erneutes Eingeben der IP.

• Lobby — der Hub, in dem alle beim Beitritt landen.
• Survival / Anarchie — eine eigene schwere Welt mit eigener Wirtschaft.
• Minispiele — BedWars, SkyWars und Ähnliches, oft ein Server pro Modus.
• Ein Einstieg — eine IP, eine gemeinsame Bannliste und grundlegender Schutz auf Proxy-Ebene.

Wichtig zu verstehen: Ein Proxy bündelt nicht die Leistung der Server und macht keinen „einen großen Server“ daraus. Jedes Backend bleibt eine eigene JVM mit eigenen TPS. Der Proxy leitet nur die Spieler weiter. Wenn du also einfach einen großen Survival-Server für 40 Leute brauchst, brauchst du kein Netzwerk — ein Server reicht; welche Server-Software dafür passt, steht in unserer Analyse Paper vs. Purpur vs. Vanilla.

BungeeCord (Waterfall) oder Velocity

BungeeCord ist der historische Standard, über Jahre erprobt. Waterfall ist sein PaperMC-Fork mit Optimierungen, doch 2023 hat das Paper-Team Waterfall in den Wartungsmodus versetzt und den Fokus auf Velocity gelegt. Velocity wurde von Grund auf neu geschrieben: Es ist ressourcenschonender, hält in großen Netzwerken besser durch und bietet einen modernen Mechanismus zur Weitergabe von Spielerdaten.

Installation und Grundkonfiguration

Beide Proxys sind einfach eine normale JAR, die in ihrer eigenen JVM läuft. Lade den neuesten Build herunter (Velocity von der PaperMC-Website, BungeeCord von SpigotMC), leg ihn in einen eigenen Ordner und starte ihn einmal — die Config wird erzeugt.

velocity.toml

Die Hauptdatei von Velocity. Die wichtigsten Abschnitte:

bind = "0.0.0.0:25565"
motd = "&3My network"
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"

[servers]
lobby = "127.0.0.1:30066"
survival = "127.0.0.1:30067"
try = ["lobby"]

[forced-hosts]
"play.example.com" = ["lobby"]

Hier ist bind die Adresse und der Port, auf dem der Proxy lauscht (und den du nach außen öffnest). In [servers] trägst du die Backends mit ihren internen Adressen ein. try ist die Liste der Server, zu denen der Spieler beim Beitritt geschickt wird (die erste erreichbare Lobby). Mit forced-hosts kannst du eine Domain an einen bestimmten Server binden.

config.yml (BungeeCord)

BungeeCord folgt derselben Logik, aber in YAML, mit einem wichtigen Unterschied — ip_forward:

ip_forward: true
listeners:
- host: 0.0.0.0:25565
  priority:
  - lobby
servers:
  lobby:
    address: 127.0.0.1:30066
    restricted: false
  survival:
    address: 127.0.0.1:30067

Die Option ip_forward: true aktiviert die Weitergabe der echten IP und UUID des Spielers an das Backend — ohne sie erscheinen alle mit derselben Adresse, und die Authentifizierung bricht. Genau das bedeutet „Forwarding“ im Sinne von BungeeCord.

Anbindung der Backends — wo alle stolpern

Der häufigste Anfängerfehler. Die Backend-Server (Lobby, Survival) dürfen die Lizenz nicht selbst prüfen — das macht der Proxy. Setz deshalb auf jedem Backend in der server.properties:

online-mode=false

Lässt du online-mode=true, versucht das Backend, den Spieler erneut bei Microsoft zu authentifizieren, und wirft ihn mit dem Fehler Bad login raus. Aber online-mode nur abzuschalten reicht nicht — du musst Proxy und Backend per Forwarding „verkleben“.

Velocity + Paper (Modern Forwarding)

Das ist der richtige, sichere Weg. Auf dem Backend sollte Paper oder Purpur laufen. Öffne config/paper-global.yml und trag im Abschnitt proxies ein:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "paste_the_contents_of_forwarding.secret_here"

Der Wert von secret ist der Inhalt der Datei forwarding.secret, die Velocity in seinem Ordner erzeugt hat. Die Einstellung online-mode in paper-global.yml muss zum online-mode des Proxys passen (in velocity.toml): Prüft der Proxy Lizenzen, setz true; für Cracked/Offline-Modus false. Genau dieses Secret verhindert gefälschte Logins.

BungeeCord + Paper

Das Forwarding von BungeeCord ist einfacher und weniger sicher. Aktiviere auf dem Backend in config/paper-global.yml nach Bedarf proxies.bungee-cord.online-mode und setz in spigot.yml:

settings:
  bungeecord: true

Ein Secret gibt es hier nicht — das Backend vertraut allen Daten, die „wie von Bungee“ ankommen. Daraus ergibt sich die wichtigste Sicherheitsanforderung überhaupt.

Schritt für Schritt: ein Netzwerk mit Velocity aufbauen

Bauen wir ein minimales Netzwerk „Lobby + Survival“. Dieselben Schritte findest du auch im FAQ-Block unten.

1. Erstell den Proxy-Server. Setz einen eigenen Server für Velocity auf und lade den neuesten Build von PaperMC herunter. Starte ihn einmal — er erzeugt velocity.toml und forwarding.secret.
2. Konfiguriere velocity.toml. Setz bind = "0.0.0.0:25565", player-info-forwarding-mode = "modern" und trag in [servers] die Backends (Lobby, Survival) mit interner IP und Port ein, plus try = ["lobby"].
3. Bereite die Backends vor. Installier auf jedem Paper oder Purpur und setz in server.properties online-mode=false. Der Server muss auf einer internen Adresse lauschen, nicht im öffentlichen Internet.
4. Binde das Forwarding Secret ein. Aktiviere in der config/paper-global.yml jedes Backends proxies.velocity.enabled: true, füge den Inhalt von forwarding.secret in secret ein und setz online-mode passend zum Proxy.
5. Schotte die Backends per Firewall ab. Nach außen ist nur der Proxy-Port (25565) offen. Schließ die Backend-Ports, damit sich niemand direkt verbinden kann.
6. Starte und teste. Starte zuerst die Backends, dann den Proxy. Verbinde dich mit der Proxy-Adresse — du landest in der Lobby. Prüf mit /server survival den Wechsel ohne Neu-Login.

So funktioniert das bei einem Hoster

Auf einem VPS richtest du alles von Hand ein; beim Spiele-Hosting von Elysium ist das Schema einfacher — jedes Element des Netzwerks ist ein eigener Server im Pterodactyl-Panel, und Velocity gibt es direkt im Bestellformular. Du erstellst einen Server für Velocity und je einen Server pro Backend, trägst die Adressen der Backends in velocity.toml ein und schaltest Modern Forwarding mit Secret ein. Spieler treten nur über den Proxy bei, und das Secret verhindert, dass sich jemand direkt mit den Backends verbindet. Alle Server laufen in Frankfurt.

Entscheidend für ein Proxy-Netzwerk sind niedriger Ping zwischen den Knoten und ein starker Einzelkern: Minecraft lässt sich kaum parallelisieren, deshalb hängen die TPS eines Backends am Takt des Kerns. Auf einem Ryzen 9 mit Boost bis 5,6 GHz und NVMe Gen4 (Lesen ~7 GB/s) bremsen Wechsel und Chunk-Laden den Tick nicht. Ein Netzwerk aus 2–3 Backends läuft meist auf den Tarifen Nexus (8 GB) oder Apex (12 GB) — schätz aber vorher genau ab, wie viel RAM du pro Knoten einplanen musst.

Wenn du gerade erst anfängst und ein Netzwerk noch zu viel ist, starte zuerst einen einzelnen Server mit unserem vollständigen Guide zum Erstellen eines Minecraft-Servers und füge einen Proxy hinzu, sobald dein Projekt auf mehrere Modi wächst.