BungeeCord vs. Velocity: Moderne Proxy-Architektur und Netzwerk-Skalierung

Große Minecraft-Netzwerke operieren niemals als einzelne Server-Instanz. Stattdessen routet ein vorgeschalteter Proxy-Knoten tausende gleichzeitige Spielerverbindungen unterbrechungsfrei zwischen Lobbys, Spielmodi und Ausweichinstanzen hin und her. Über ein Jahrzehnt lang war BungeeCord der de-facto Standard. Für hochperformante Netzwerke gilt BungeeCord heute jedoch als technischer Flaschenhals.

Dieser Leitfaden analysiert die architektonischen Vorzüge von Velocity 3.3+, demonstriert die Konfiguration von Modern Forwarding mit kryptografischen Secrets und erläutert die Skalierung von Proxy-Clustern.

1. Architektonischer Vergleich: Warum Velocity überlegen ist

Velocity wurde von Grund auf neu konzipiert, um die Schwächen traditioneller BungeeCord-Forks (wie Waterfall) zu beseitigen:

Besonders bei Verbindungsspitzen (z. B. wenn 300 Spieler nach einem Streamer-Event gleichzeitig die Lobby betreten) verbraucht Velocity bis zu 60 % weniger CPU-Ressourcen und verhindert Verbindungs-Timeouts.

2. Einrichtung von Modern Forwarding in velocity.toml

Das traditionelle BungeeCord-Forwarding überträgt Spielerdaten (UUID, Skin-Daten, IP-Adresse) ungesichert im Handshake-Paket. Ist der Backend-Port eines Unterservers für das Internet sichtbar, kann ein Angreifer eine gefälschte UUID mitsenden und Operator-Rechte erlangen.

Velocity löst dies durch Modern Forwarding, bei dem ein kryptografisches Secret ausgetauscht wird:

# velocity.toml
bind = "0.0.0.0:25565"
motd = "<#55ffff>KiroCloud Network <gray>| <white>High Performance"
show-max-players = 1000
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"

[servers]
lobby = "127.0.0.1:25566"
citybuild = "127.0.0.1:25567"
survival = "127.0.0.1:25568"

[forced-hosts]
"lobby.kirocloud.de" = ["lobby"]

try = [
  "lobby"
]

Beim ersten Start erzeugt Velocity die Datei forwarding.secret mit einer kryptografisch sicheren Zufallszeichenfolge (z. B. 7x8y9z...).

3. Backend-Konfiguration auf Paper/Purpur

Auf jedem angeschlossenen Backend-Server wird das Gegenstück in config/paper-global.yml konfiguriert:

# config/paper-global.yml
proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "7x8y9z...Hier_Das_Gleiche_Secret_Eintragen..."

Zusätzlich muss in server.properties der online-mode auf false gesetzt werden, da die Mojang-Authentifizierung zentral auf dem Velocity-Proxy stattfindet. Versucht nun jemand, sich ohne das korrekte Secret direkt mit Port 25566 zu verbinden, weist Paper die Verbindung mit der Fehlermeldung Unable to verify player details unverzüglich ab.

4. Tuning der Netzwerk-Kompression und Puffergrößen

Die Kompression von Netzwerkpaketen ist ein Kompromiss zwischen ausgehender Bandbreite und CPU-Rechneraufwand:

# Ausschnitt velocity.toml
compression-threshold = 512
compression-level = -1
connection-timeout = 5000
read-timeout = 30000
haproxy-protocol = false
tcp-fast-open = true

• compression-threshold = 512: Pakete unter 512 Bytes werden unkomprimiert übertragen. Dadurch entfällt der Zlib-Overhead für Chatnachrichten, kleine Bewegungsvektoren und Inventarklicks.
• tcp-fast-open = true: Ermöglicht den Datenaustausch bereits während des einleitenden TCP-SYN-Pakets, was die Latenz beim Verbindungsaufbau um einen halben Roundtrip (RTT) senkt.

5. Horizontale Proxy-Skalierung mit Anycast und DNS-Load-Balancing

Sobald ein Netzwerk mehr als 1.500 gleichzeitige Spieler bedient, sollte der Proxy-Dienst nicht mehr auf einem einzelnen Prozess laufen.

Architektur für Hochverfügbarkeit

1. Zwei separate Velocity-Instanzen: Proxy-A (Rootserver 1) und Proxy-B (Rootserver 2).
2. Synchronisation via RedisVelocity: Über einen zentralen Redis-Server teilen sich beide Proxys die globalen Spielerlisten, privaten Nachrichten (/msg) und Server-Statistiken in Echtzeit.
3. DNS-Round-Robin oder Geo-Anycast: Beide Server-IPs werden unter play.kirocloud.de als A-Records eingetragen. Fällt Proxy-A aus, routet der DNS-Resolver neue Verbindungen automatisch zu Proxy-B.

6. HAProxy PROXY Protocol v2 für echte Client-IPs

Wenn Sie mehrere Velocity-Knoten hinter einem softwarebasierten Layer-4-Load-Balancer wie HAProxy betreiben, verliert der Proxy standardmäßig die reale Quell-IP des Spielers, da alle TCP-Sockets vom Load-Balancer stammen.

Die Lösung ist das HAProxy PROXY Protocol v2, das dem TCP-Datenstrom einen binären Header mit der Original-IP voranstellt:

# /etc/haproxy/haproxy.cfg
frontend minecraft_front
    bind 0.0.0.0:25565
    mode tcp
    option tcplog
    default_backend velocity_cluster

backend velocity_cluster
    mode tcp
    balance roundrobin
    server velocity1 10.8.0.10:25565 send-proxy-v2 check
    server velocity2 10.8.0.11:25565 send-proxy-v2 check

Aktivieren Sie in der velocity.toml beider Knoten:

haproxy-protocol = true

Damit verarbeitet Velocity den PROXY-v2-Header, erkennt IP-Bans zuverlässig und schützt das Netzwerk vor Verbindungsfluten, während die Last gleichmäßig auf beide physischen Nodes verteilt wird.