Velocity SMP-Netzwerk: Lobby, Survival, Creative und Minigames hinter einem Proxy

Wenn ein Server aus einer einzigen Welt herauswächst, kommt der Wunsch nach einem Netzwerk: eine Lobby mit Portalen, der Haupt-Survival, ein Creative-Server für Builder und ein Minigames-Block. Velocity vereint das alles unter einer Adresse wie play.example.net:25565. Hier eine handfeste Anleitung, wie man so ein Netzwerk von Grund auf aufbaut, was in velocity.toml gehört, wie man Permissions und Chat synchronisiert, und welche Backend-Fehler die Tür für UUID-Spoofing weit öffnen.

Warum überhaupt ein Proxy und warum gerade Velocity

Ein Proxy wird gebraucht, sobald mehr als ein Server existiert und Spieler ohne neue IP-Verbindung zwischen ihnen wechseln sollen. BungeeCord und Waterfall können das, beide laufen aber auf einem alten Netty-Modell und schleppen Jahre an Legacy-Code mit. PaperMC hat Velocity komplett neu auf Java 21 geschrieben, mit asynchroner Paketverarbeitung und einem sauberen Plugin-System. In der Praxis bewältigt eine einzelne Velocity-Instanz problemlos 1000+ gleichzeitige Verbindungen mit 1 GB RAM und stößt nicht an die GC-Grenzen, gegen die Bungee bei denselben Zahlen läuft.

Praktische Vorteile:

• modern forwarding: signierte UUID- und IP-Übertragung an Backends, durch ein Secret geschützt
• Direktverbindungen sperren: Backends weisen alles ab, was nicht vom Proxy kommt
• nativ Java 21, ohne Preview-Flag-Tricks
• zeitnaher Support neuer Minecraft-Versionen ohne Wartezeit auf Bungee-Maintainer

Wer 2026 zwischen Velocity und BungeeCord wählt, hat eine klare Antwort. Bungee bleibt nur in Nischenfällen sinnvoll, in denen ein kritisches Plugin noch nicht auf die Velocity-API portiert wurde.

Netzwerk-Architektur

Typische Aufteilung für ein SMP-Netzwerk:

                  ┌──────────────┐
   Spieler ──────▶│ Velocity     │ :25565 (öffentlich)
                  │ Proxy        │
                  └──────┬───────┘
                         │ modern forwarding
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
   ┌─────────┐    ┌──────────┐    ┌──────────┐
   │ lobby   │    │ survival │    │ creative │   ┌──────────┐
   │ :25566  │    │ :25567   │    │ :25568   │   │minigames │
   └─────────┘    └──────────┘    └──────────┘   │ :25569   │
                                                  └──────────┘

Alle Backends lauschen entweder nur am lokalen Interface oder hängen hinter einer Firewall, die die Außenwelt blockiert. Spieler sehen ausschließlich play.example.net:25565, die interne Topologie geht sie nichts an.

Beim Speicher: Velocity selbst belegt 512 MB bis 1 GB RAM, der Rest geht an die Backends. Lobby reicht meist mit 2 GB, Survival und Creative wollen ab 4 GB je nach Online-Zahlen, der Minigames-Block landet bei 2-4 GB.

Velocity installieren

Aktuelles Velocity-3.x-Build von paper.io holen. Eigenen User, eigenes Verzeichnis, jar dort ablegen:

sudo useradd -m -s /bin/bash velocity
sudo -u velocity mkdir /home/velocity/proxy
cd /home/velocity/proxy
sudo -u velocity wget https://api.papermc.io/v2/projects/velocity/versions/3.4.0/builds/.../downloads/velocity-3.4.0.jar

systemd-Unit für Autostart:

[Unit]
Description=Velocity Proxy
After=network.target

[Service]
Type=simple
User=velocity
WorkingDirectory=/home/velocity/proxy
ExecStart=/usr/bin/java -Xms1G -Xmx1G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -jar velocity-3.4.0.jar
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Beim ersten Start entstehen velocity.toml, forwarding.secret und das Verzeichnis plugins/. Die Hauptdatei für die folgenden Anpassungen ist velocity.toml.

velocity.toml konfigurieren

Eine minimale arbeitsfähige Konfiguration für unser Netzwerk:

config-version = "2.7"
bind = "0.0.0.0:25565"
motd = "<bold><green>Example Network</green></bold>\n<gray>SMP - Creative - Minigames</gray>"
show-max-players = 500
online-mode = true
force-key-authentication = true
prevent-client-proxy-connections = true
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"
announce-forge = false

[servers]
lobby = "127.0.0.1:25566"
survival = "127.0.0.1:25567"
creative = "127.0.0.1:25568"
minigames = "127.0.0.1:25569"
try = ["lobby", "survival"]

[forced-hosts]
"smp.example.net" = ["survival"]
"build.example.net" = ["creative"]
"play.example.net" = ["lobby"]

[advanced]
compression-threshold = 256
compression-level = -1
login-ratelimit = 3000
connection-timeout = 5000
read-timeout = 30000
haproxy-protocol = false
tcp-fast-open = false

Wichtige Punkte:

• online-mode = true am Proxy: die Mojang-Lizenzprüfung läuft genau hier
• player-info-forwarding-mode = "modern": signierte UUID/IP-Übertragung
• try = ["lobby", "survival"]: fällt die Lobby aus, landen Spieler im Survival statt rauszufliegen
• forced-hosts: nützlicher Trick, wenn mehrere Subdomains auf Port 25565 zeigen

Die Datei forwarding.secret wird automatisch erzeugt. Ihren Inhalt kopieren wir in jedes Backend.

Backends vorbereiten: Paper-Konfiguration

Jeder Paper-Server hinter dem Proxy wird konzeptionell gleich konfiguriert. Survival als Beispiel. paper-global.yml öffnen:

proxies:
  bungee-cord:
    online-mode: false
  proxy-protocol: false
  velocity:
    enabled: true
    online-mode: true
    secret: 'HIER_DEN_FORWARDING_SECRET_INHALT_EINFÜGEN'

Dann server.properties:

server-port=25567
online-mode=false
prevent-proxy-connections=false
server-ip=127.0.0.1
network-compression-threshold=-1

Schlüsselpunkte:

1. online-mode=false in server.properties ist Pflicht. Sonst versucht Paper, die Session selbst zu validieren und zerschießt damit modern forwarding.
2. online-mode: true in paper-global.yml unter velocity ist die Stelle, an der die echte UUID-Validierung passiert, gegen das, was Velocity geschickt hat.
3. server-ip=127.0.0.1 sorgt dafür, dass der Server nur am Loopback lauscht. Niemand von außen kann direkt verbinden, selbst wenn der Port bekannt wird.

Dasselbe für Lobby (Port 25566), Creative (25568), Minigames (25569). Jeder bekommt denselben forwarding.secret vom Proxy kopiert, jeder auf eigenem Port.

Sicherheit: die online-mode-Falle

Das häufigste Loch in selbst gehosteten Netzwerken ist online-mode=true am Backend in Kombination mit modern forwarding stehen zu lassen. Die Logik dahinter: ist das Backend im Online-Modus, validiert es Sessions selbst über Mojang. Velocity hat das aber bereits getan. Paper antwortet dann mit "kann nicht prüfen", der Admin macht aus Verzweiflung den Port nach außen auf oder setzt prevent-proxy-connections=false, ohne die Folgen zu verstehen.

Die harte Regel:

• Proxy: online-mode = true
• Backend server.properties: immer online-mode=false
• Backend paper-global.yml: velocity.online-mode: true plus korrekter Secret

Bleibt das Backend im Online-Modus ohne Proxy-Validierung, kann jeder Client mit gefälschter UUID unter fremdem Namen joinen, weil Mojang diese Session nie gegen euren Server geprüft hat. Klassischer Fehler hinter den meisten "Operator-Account geklaut"-Vorfällen.

Zusätzlich Firewall davor. Liegt alles auf einer Maschine, erledigt 127.0.0.1 schon das Meiste. Liegen Backends auf anderen VPS, lässt iptables oder ufw nur die Proxy-IP zu:

sudo ufw default deny incoming
sudo ufw allow from <PROXY_IP> to any port 25567 proto tcp
sudo ufw allow ssh
sudo ufw enable

Synchronisation zwischen Servern

Ein echtes Netzwerk besteht nicht nur aus Connection-Routing. Spieler brauchen geteilte Permissions, geteilten Chat, manchmal geteilten Kontostand. Ohne Sync ist jedes Backend eine Insel mit eigenen Rängen und Logs.

Geteilte Permissions per LuckPerms

LuckPerms wird auf jedes Backend und auf Velocity selbst installiert (separate jar für den Proxy). Storage wird von file auf MySQL/MariaDB umgestellt:

storage-method: mysql
data:
  address: 127.0.0.1:3306
  database: luckperms
  username: lp_user
  password: 'strong-password'
messaging-service: sql

Wenn LuckPerms auf allen Servern auf eine Datenbank zeigt und auf einen Messaging-Channel hört, gilt jede Gruppen- oder Rechteänderung sofort überall. Ein /lp user Steve parent set vip macht Steve zugleich in Lobby, Survival und Creative zum VIP.

Gemeinsamer Kontostand und Wirtschaft

Drei Optionen, jede mit Stolperfallen:

• CMI oder EssentialsX mit MySQL-Backend: einfachster Weg für die meisten SMP-Netzwerke. Balance schreibt in eine geteilte DB, /balance zeigt überall denselben Betrag.
• Vault-Brücke über den Proxy: komplexer, braucht Hilfs-Plugins wie RedisEconomy. Geeignet für Netzwerke mit hohen Online-Zahlen, bei denen MySQL ins Schwitzen kommt.
• Isolierte Wirtschaften je Server: legitim, wenn Creative bewusst von Survival abgegrenzt sein soll.

Meist reicht EssentialsX mit economy-storage: mysql im passenden Brücken-Plugin.

Chat über mehrere Server

Damit eine Survival-Nachricht in der Lobby ankommt, braucht es ein Aggregator-Plugin. Funktionierende Optionen:

• VentureChat mit Velocity-Komponente: reichhaltige Channel-Logik, global und lokal
• CarbonChat: moderne Alternative mit feiner Channel-Steuerung
• GlobalTabList: synchronisiert nur die Tab-Spielerliste, kein Chat

Für unser Netzwerk installieren wir VentureChat auf Proxy und allen Backends, richten einen global-Channel ein, der überall syncht, und einen local-Channel, der nur auf dem eigenen Server sichtbar ist. Resultat: gemeinsamer Chat fürs Quatschen, lokaler Chat für das, was direkt am Server passiert.

Server-Wechsel für Spieler

Velocity bringt von Haus aus /server <name> mit, verfügbar mit der Permission velocity.command.server. Für ein hübscheres UX kommen Portale und NPCs dazu.

In Lobbies stehen üblicherweise NPCs aus Citizens oder FancyNpcs, jeder mit velocity send self <server> über VelocityPortals oder PortalsPlus verknüpft. Spieler geht zum Modus-Auswahl-NPC, klickt, wird auf das passende Backend geschickt.

Alternative sind physische Obsidian-Portale, an einen Befehl gebunden. Multiverse-Portals in der Lobby kann Cross-Server-Befehle auslösen, wenn ein Brücken-Plugin dazukommt.

Minimalvariante ohne Portale: /server survival reicht. Billig und funktioniert.

Whitelist und privater Zugang

Bei einem privaten Netzwerk gehört die Whitelist an zwei Stellen:

1. Auf Velocity per VelocityWhitelist oder NetworkManager Plugin. Erste Barriere.
2. Auf jedem Backend: /whitelist add <name> in server.properties oder per Sync-Plugin, das die Whitelist über MySQL spiegelt.

Die Doppelung wirkt redundant, schützt aber den Fall, dass der Proxy ohne Whitelist-Plugin neu startet und Backends aus einem internen Netz erreichbar sind.

Performance und Hosting

Hardware-Aufteilung hängt von der Spieler-Anzahl ab:

• bis 50 Spieler: ein dedizierter Server mit 16 GB RAM. Velocity, Lobby, Survival, Creative, Minigames laufen alle auf einer Maschine, getrennt nach Ports.
• 50-200 Spieler: VPS für den Proxy (4 GB), eigener Survival-VPS (8 GB), kombinierter VPS für Lobby + Creative + Minigames (8 GB).
• 200+ Spieler: jedes Backend auf eigener Maschine, Proxy in eigenem Datacenter mit starkem Netz, Privatnetz zwischen ihnen vom Provider.

Velocity ist CPU-arm, was zählt sind Netz und niedrige Latenz. Liegen Proxy und Backends auf verschiedenen Hosts, sind 2-3 ms pro Hop für Spieler spürbarer Lag. Wenn möglich: gleiche Availability Zone.

Für DDoS-Schutz kann der Proxy hinter einen Traffic-Filter wie MineGuard. Angriffe treffen die öffentliche Proxy-IP, Backends bleiben im privaten Netz ruhig. Mehr dazu: Velocity-Netzwerk DDoS-Schutz Anleitung.

FAQ

Velocity vs BungeeCord vs Waterfall, was wählen?

2026 ist Velocity die klare Antwort. BungeeCord ist architektonisch veraltet, Waterfall (PaperMC-Fork von Bungee) war eine Übergangslösung und ist im Maintenance-Modus. Velocity wird aktiv weiterentwickelt, hat eine moderne API und unterstützt neue Minecraft-Versionen ohne Verzögerung.

Können Velocity und ein Server auf derselben Maschine laufen?

Ja, oft die beste Lösung für kleine Netzwerke. Velocity lauscht auf 25565 an der öffentlichen IP, Backends auf 127.0.0.1 mit verschiedenen Ports. Niemand von außen sieht sie, Latenz zwischen Proxy und Backend ist im Mikrosekunden-Bereich. Wichtig ist genug RAM mit Reserve für Spitzen-Online.

Wie schütze ich ein Backend vor Direktverbindungen?

Drei Schichten. Erstens: Backends lauschen nur auf Loopback (server-ip=127.0.0.1), wenn sie auf derselben Maschine wie der Proxy laufen. Zweitens: Firewall lässt nur die Proxy-IP zu den Backend-Ports. Drittens: korrekt konfiguriertes modern forwarding in paper-global.yml mit eindeutigem Secret, das Paper bei jeder Verbindung prüft.

Wie bekomme ich gemeinsamen Chat zwischen Servern?

VentureChat oder CarbonChat auf Proxy und alle Backends installieren, geteilten Channel einrichten. Survival-Nachrichten erscheinen in der Lobby und umgekehrt. Lokaler Chat bleibt daneben bestehen, damit serverinternes Geschehen nicht im Global-Chat ertrinkt.

Was tun, wenn ein Spieler mit "If you wish to use IP forwarding, please enable it in your BungeeCord config" gekickt wird?

Dieser Kick kommt vom Backend, das nicht versteht, was der Proxy schickt. paper-global.yml prüfen: velocity.enabled: true, korrekter Secret, und in server.properties muss online-mode=false stehen. Backend nach den Änderungen neu starten.

Brauche ich einen extra VPS für den Proxy?

Nicht zwingend. Für Netzwerke mit unter 50 Online ist ein einziger Rechner ausreichend. Für größere Netzwerke ist ein eigener Proxy-Server praktisch, weil er sich leichter gegen DDoS schützen und in einer Region mit gutem Netz hosten lässt, ohne schwere Game-Server mitzuschleppen.

Funktioniert Velocity mit Forge- oder Fabric-Modpacks?

Ja, über announce-forge und Brücken-Plugins. Forge-Server hinter Velocity laufen, brauchen aber etwas mehr Feinabstimmung und passende Client-Versionen. Für gemischte Netzwerke (vanilla + modded) ist es einfacher, modded Server in einem eigenen Zweig mit /server-Wechsel zu halten.

Wie es weitergeht

Wenn das Netzwerk steht, eines nach dem anderen ergänzen. Erst sicherstellen, dass Lobby + Survival verbunden sind und der Wechsel funktioniert. Dann Creative und Minigames anschließen. LuckPerms, Chat und Wirtschaft erst nach dem Basis-Routing, sonst ertrinkt man im Debugging dessen, was wo kaputtging.

Backups von velocity.toml, forwarding.secret und paper-global.yml aller Backends an einem Ort halten, das spart bei Hardware-Migrationen Stunden. Und Monitoring nicht vergessen: tps pro Backend plus Ping zwischen Proxy und Servern auf einem Dashboard sichtbar.