Velocity vs BungeeCord: Warum es Zeit zum Wechseln ist

BungeeCord erschien 2012 und war viele Jahre lang die einzige echte Wahl fuer Minecraft-Proxy-Server. Es hat seinen Job gemacht. Aber jetzt ist 2026, und die Dinge haben sich grundlegend geaendert.

Velocity, erstellt von Andrew Steinborn im Jahr 2018 und jetzt unter PaperMC, ist zum De-facto-Standard fuer neue Netzwerke geworden. Waterfall (Papers BungeeCord-Fork) ist offiziell tot. BungeeCord selbst wird von md_5 nur minimal gewartet.

In diesem Artikel werde ich jeden wichtigen Unterschied aufschluesseln, Zahlen zeigen und erklaeren, wie man migriert. Ohne Umschweife, direkt zur Sache.

Leistung: Die Zahlen sprechen fuer sich

Fangen wir mit dem an, was alle interessiert - Geschwindigkeit. PaperMC behauptet, Velocity sei in bestimmten Szenarien bis zu 8-mal schneller als BungeeCord. Klingt nach Marketing? Schauen wir uns an, woher diese Zahlen kommen.

Komprimierung: libdeflate vs zlib

BungeeCord verwendet die Standard-Java-zlib-Implementierung fuer Paketkomprimierung. Velocity nutzt libdeflate, eine native Bibliothek, die etwa doppelt so schnelle Komprimierung und Dekomprimierung bietet. Bei einem Netzwerk mit 500+ Spielern ist das ein spuerbarer Unterschied bei der CPU-Last.

Kein Entity ID Rewriting

Dies ist wohl der wichtigste architektonische Unterschied. BungeeCord faengt jedes Paket ab und schreibt Entity-IDs um, um Konflikte zwischen Servern zu vermeiden. Das ist eine teure Operation, die bei jedem Entity-bezogenen Paket stattfindet.

Velocity hat diesen Ansatz komplett aufgegeben. Anstatt IDs auf Proxy-Ebene umzuschreiben, verlaesst sich Velocity darauf, dass Backend-Server die Entity-IDs beim Spielerwechsel korrekt verwalten. Das Ergebnis ist deutlich weniger CPU-Overhead pro Verbindung.

TCP Fast Open

Velocity unterstuetzt TCP Fast Open (TFO) direkt ab Werk. Diese Technologie ermoeglicht das Senden von Daten bereits im ersten SYN-Paket einer TCP-Verbindung, wodurch die Verbindungsaufbauzeit um einen RTT reduziert wird. Fuer Spieler bedeutet das schnellere Verbindungen.

Asynchrone Ereignisverarbeitung

BungeeCord verarbeitet Ereignisse synchron. Wenn ein Plugin in einem Event-Handler haengt, steht die gesamte Pipeline still. Velocity verwendet ein asynchrones Modell, bei dem Ereignisse ohne Blockierung des Hauptthreads verarbeitet werden. Ein schlecht geschriebenes Plugin legt nicht den gesamten Proxy lahm.

Was bedeutet das in der Praxis

Bei einem kleinen Netzwerk mit 50 Spielern ist der Unterschied vielleicht nicht sichtbar. Aber bei 200+ Spielern, besonders mit Custom-Plugins, bringt der Wechsel zu Velocity spuerbare Verbesserungen. Weniger TPS-Drops beim Serverwechsel, schnellere Verbindungen, stabilerer Betrieb unter Last.

Sicherheit: Der wahre Grund zur Migration

Wenn Leistung ein netter Bonus ist, dann ist Sicherheit der Hauptgrund, warum du BungeeCord verlassen musst. Jetzt sofort.

IPForward: Ein Scheunentor

BungeeCord verwendet IPForward, um Spielerinformationen an Backend-Server weiterzuleiten. Wie funktioniert das? Der Proxy fuegt die IP-Adresse und UUID des Spielers als Klartext in das Handshake-Paket ein. Ein Backend-Server mit bungeecord: true vertraut diesen Daten blind.

Das Problem liegt auf der Hand: Wenn sich jemand direkt mit dem Backend-Server verbindet (am Proxy vorbei), kann er jede beliebige UUID in den Handshake einschleusen. Das bedeutet vollen Zugriff auf das Konto eines anderen Spielers, einschliesslich Inventar, Berechtigungen und Guthaben.

BungeeHack und UUID Spoofing

BungeeHack ist eine ganze Familie von Exploits, die genau diese Schwachstelle ausnutzen. Der Angreifer verbindet sich direkt mit dem Backend-Server und faelscht die UUID im Handshake-Paket. Ergebnis - er loggt sich als jemand anderes ein.

UUID Spoofing funktioniert genauso. Da BungeeCord UUIDs im Klartext ohne jede Verifizierung uebertraegt, ist die Faelschung trivial. Selbst eine Firewall hilft nicht immer, wenn der Angreifer Zugang zum internen Netzwerk hat.

Velocity Modern Forwarding: HMAC-SHA256

Velocity loest dieses Problem grundlegend. Modern Forwarding verwendet HMAC-SHA256, um die vom Proxy zum Backend uebertragenen Daten zu signieren. Proxy und Backend teilen einen geheimen Schluessel, und jeder Handshake wird damit signiert.

Wenn jemand versucht, sich direkt mit dem Backend zu verbinden oder Handshake-Daten zu manipulieren, stimmt die Signatur nicht ueberein und die Verbindung wird abgelehnt. Kein UUID Spoofing, kein BungeeHack. Kryptographischer Schutz statt "vertrauen und nicht pruefen."

BungeeGuard ist ein Pflaster

Ja, BungeeGuard und aehnliche Plugins existieren, die Token-Verifizierung ueber BungeeCord legen. Aber das ist ein Pflaster. Du flickst ein architektonisches Problem, anstatt eine Loesung zu verwenden, bei der Sicherheit von Grund auf eingebaut ist.

Waterfall ist tot, BungeeCord liegt auf der Intensivstation

Falls du immer noch denkst "naja, ich warte mal ab", hier sind die Fakten.

Waterfall: Offiziell EOL

Waterfall war PaperMCs Fork von BungeeCord, der Performance-Patches und Bugfixes hinzufuegte. 2024 hat PaperMC Waterfall offiziell fuer End of Life erklaert. Keine Updates mehr, keine Sicherheitspatches. Das Paper-Team empfiehlt ausdruecklich den Wechsel zu Velocity.

BungeeCord: Minimale Wartung

md_5 wartet BungeeCord weiterhin, aber es ist genau das - minimale Wartung. Grosse Updates gibt es schon lange nicht mehr. Unterstuetzung fuer neue Minecraft-Versionen wird hinzugefuegt, aber ohne ernsthafte Verbesserungen an Architektur oder Sicherheit.

Plugin-Oekosystem

Eines der Hauptargumente gegen die Migration ist "was ist mit den Plugins?" Schauen wir es uns an.

API-Inkompatibilitaet

Fakt ist: BungeeCord-Plugins funktionieren nicht auf Velocity. Sie haben unterschiedliche APIs. Wenn du Custom-BungeeCord-Plugins hast, muessen sie umgeschrieben werden. Das ist wahrscheinlich der schmerzhafteste Teil der Migration.

Aber es gibt Nuancen. Viele beliebte Plugins haben schon seit langem Versionen fuer beide Plattformen. LuckPerms, TAB, LimboAuth, MiniMOTD, Geyser - sie alle unterstuetzen Velocity.

Hangar: 311+ Plugins

Auf Hangar (PaperMCs Plugin-Plattform) gibt es ueber 311 Plugins fuer Velocity. Und die Zahl waechst. Neue Plugins erscheinen oft zuerst fuer Velocity und dann (wenn ueberhaupt) fuer BungeeCord. Der Trend ist eindeutig.

Grosse Netzwerke sind bereits umgestiegen

Minehut, eine der groessten Minecraft-Hosting-Plattformen, verwendet Velocity. Die meisten modernen Hoster empfehlen Velocity standardmaessig. Das ist keine experimentelle Technologie, das ist der Produktionsstandard.

Migrationsleitfaden

Also gut, du hast dich zur Migration entschieden. Hier ist eine Schritt-fuer-Schritt-Anleitung.

Schritt 1: Velocity installieren

Lade die neueste Version von PaperMC Downloads herunter. Erstelle ein separates Verzeichnis und starte:

java -Xms512M -Xmx512M -jar velocity.jar

Velocity generiert die Konfigurationsdateien. Stoppe den Server.

Schritt 2: velocity.toml konfigurieren

Oeffne velocity.toml und richte die Grundlagen ein:

bind = "0.0.0.0:25565"

[servers]
lobby = "127.0.0.1:30001"
survival = "127.0.0.1:30002"
minigames = "127.0.0.1:30003"

try = ["lobby"]

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

[advanced]
tcp-fast-open = true

Schritt 3: Modern Forwarding aktivieren

In velocity.toml setze:

player-info-forwarding-mode = "modern"

Velocity erstellt eine Datei forwarding.secret mit einem geheimen Schluessel. Kopiere den Inhalt.

Schritt 4: Backend-Server konfigurieren

Deaktiviere auf jedem Paper-Server zuerst BungeeCord-Forwarding in spigot.yml:

settings:
  bungeecord: false

Dann aktiviere Velocity in config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: false
    secret: "GEHEIMNIS_AUS_forwarding.secret"

Schritt 5: Plugins ersetzen

Liste alle BungeeCord-Plugins auf und finde Velocity-Alternativen:

BungeeCord Plugin	Velocity Alternative
BungeeTabListPlus	TAB (Velocity)
BungeeCord AuthMe	LimboAuth
ServerListPlus	MiniMOTD
BungeeGuard	Nicht noetig (Modern Forwarding)
Geyser-BungeeCord	Geyser-Velocity

Schritt 6: Firewall

Stelle sicher, dass Backend-Server-Ports von aussen geschlossen sind:

# Nur lokalen Zugriff auf Backend-Server erlauben
iptables -A INPUT -p tcp --dport 30001:30010 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 30001:30010 -j DROP

Wann BungeeCord noch OK ist

Fairerweise gibt es Szenarien, in denen BungeeCord eine vernuenftige Wahl bleibt.

Legacy-Netzwerke auf 1.8. Wenn dein Server auf 1.8 laeuft und du fest entschlossen bist, dort zu bleiben, ist das BungeeCord-Plugin-Oekosystem fuer diese Version umfangreicher. Velocity zielt auf moderne Versionen ab.

Tiefe Custom-Plugin-Integration. Wenn du dutzende Custom-BungeeCord-Plugins mit tausenden Zeilen Code hast, erfordert die Migration erhebliche Ressourcen. Aber selbst dann ist es besser, jetzt mit der Planung zu beginnen.

In allen anderen Faellen ist Velocity die klare Wahl.

Vergleichstabelle

Parameter	BungeeCord	Velocity
Leistung	Basis	Bis zu 8x schneller
Komprimierung	Java zlib	libdeflate (2x schneller)
Entity ID Rewriting	Ja (CPU-Overhead)	Nein
TCP Fast Open	Nein	Ja
Ereignisverarbeitung	Synchron	Asynchron
Forwarding	Klartext (IPForward)	HMAC-SHA256 (Modern)
BungeeHack-Schutz	Erfordert Extra-Plugins	Eingebaut
Projektstatus	Wartung	Aktive Entwicklung
Waterfall (Fork)	EOL	-
Plugins auf Hangar	Begrenzt	311+
Lizenz	Custom	GPLv3
Grosse Netzwerke	Legacy	Minehut etc.

Wie das mit DDoS-Schutz funktioniert

Wenn dein Server hinter einem DDoS-Schutz wie MineGuard steht, erfordert der Wechsel zu Velocity keine Aenderungen an den Filtereinstellungen. Das Proxy-Protokoll funktioniert gleich, TCP-Verbindungen werden identisch durchgeleitet. Velocity vereinfacht die Sache sogar etwas mit eingebauter PROXY-Protocol-Unterstuetzung.

Fazit

BungeeCord hat enorme Arbeit fuer die Minecraft-Community geleistet. Ohne es waeren Netzwerk-Server nicht das, was sie heute sind. Aber Technologie bleibt nicht stehen.

Velocity ist schneller, sicherer und wird aktiver entwickelt. Waterfall ist tot, und Paper sagt direkt: Nutzt Velocity. Alle grossen Hoster empfehlen Velocity. Das Plugin-Oekosystem waechst.

Der einzige echte Schmerz bei der Migration ist das Umschreiben von Custom-Plugins. Aber je laenger du wartest, desto mehr Code musst du umschreiben. Besser jetzt anfangen.

Wenn du 2026 ein neues Netzwerk startest und BungeeCord waehlst, machst du einen Fehler. Wenn du bereits auf BungeeCord bist, erstelle einen Migrationsplan. Deine Spieler werden es dir danken.