BungeeCord-Forwarding überträgt Spieler-IP, Online-UUID und Profilinformationen an das Backend. Dafür müssen Proxy- und Backendwerte zusammenpassen und direkte Backendverbindungen gesperrt sein. Sichere vor einer Umstellung auch identitätsgebundene Daten wie Inventare, Gruppen und Economy.

ip_forward: true ist keine Firewall. Das klassische BungeeCord-Format besitzt kein proxy-spezifisches Signatur-Secret. Wer ein ungeschütztes Offline-Mode-Backend erreicht, kann Forwarding-Daten fälschen und sich als anderer Spieler ausgeben.

Die vier Werte

Ort Datei/Feld Normaler Wert
BungeeCord config.yml → online_mode true
BungeeCord config.yml → ip_forward true
Backend server.properties → online-mode false
Backend spigot.yml → settings.bungeecord true

Für aktuelles Paper kommt hinzu:

# config/paper-global.yml
proxies:
  bungee-cord:
    online-mode: true

Dieser Paper-Wert entspricht dem Online-Mode des Proxys. Er bleibt true, obwohl server.properties auf dem Backend online-mode=false verwendet.

Warum ein Backup vor die Änderung gehört

Ohne Forwarding erzeugt das Offline-Mode-Backend eine UUID aus dem Spielernamen. Mit korrektem Forwarding erhält es die von der Online-Authentifizierung stammende UUID. Diese Werte sind nicht identisch. Inventar, Enderchest, Ränge oder Economy-Daten können danach wie verschwunden aussehen, obwohl sie unter der alten UUID gespeichert sind.

Vor der Änderung:

  1. sichere Welten, playerdata, Permission- und Plugin-Datenbanken;
  2. teste einen Restore;
  3. dokumentiere alte und erwartete UUID für einen Testspieler;
  4. prüfe plugin-spezifische Migrationswerkzeuge;
  5. ändere niemals blind Dateinamen, ohne Referenzen und Datenformat zu kennen.

Der bestehende Guide zum Versionswechsel beschreibt einen geeigneten Backup-, Kopie- und Rollbackpfad.

Schritt 1: Proxy einstellen

Stoppe BungeeCord sauber und bearbeite die aktuelle config.yml:

online_mode: true
ip_forward: true

Lasse die öffentliche Authentifizierung am Proxy aktiv. Prüfe parallel Listener, servers und priorities mit der config.yml-Feldreferenz.

Schritt 2: Backend einstellen

Stoppe jedes Backend vollständig und ändere:

# server.properties
online-mode=false

# spigot.yml
settings:
  bungeecord: true

Bei Paper setzt du zusätzlich den gezeigten proxies.bungee-cord.online-mode-Wert. Starte erst die Backends und anschließend BungeeCord neu. Ein Teilreload reicht für diese Identitätsänderung nicht.

Schritt 3: Backendpfad schließen

Erlaube den Backend-TCP-Port ausschließlich aus dem verifizierten Proxy-Pfad. Je nach eigener Infrastruktur ist das Loopback, ein echtes Privatnetz/VPN oder eine enge Firewallregel. In Containerumgebungen reicht eine interne IP allein nicht: Eine fremde Instanz auf derselben Bridge darf nicht als Proxy durchgehen.

Auf game-serverhosting bindet der aktive Guard unterstützte BungeeCord-Backends an die konkrete Proxy-Instanz und löst deren aktuelle Containerquelle neu auf. Stop, fehlende oder mehrdeutige Quelle bleiben Drop-only. Same-Node-, Cross-Node- und External-Backend-Pfade wurden mit echtem Proxyjoin geprüft; unabhängiger Direktzugriff blieb blockiert. Das ist eine Aussage über diese bewiesenen Pfade, keine Garantie für beliebige externe Provider-Netze.

Der vollständige Setup-Guide ordnet diese Netzwerkvarianten ein.

BungeeGuard richtig einordnen

BungeeGuard ergänzt das Legacy-Format um einen gemeinsamen Token. Verwende mindestens 1.4.0. Die Projekt-Sicherheitsseite dokumentiert für ältere BungeeCord-Setups eine Token-Offenlegung; nach Upgrade muss ein möglicherweise betroffener Token auf Proxy und Backends rotiert werden.

  • Token lokal mit ausreichender Entropie erzeugen;
  • nie in Tickets, Logs, Screenshots oder Git kopieren;
  • Proxy und alle Backends koordiniert aktualisieren;
  • alten Token erst nach erfolgreichem Test entfernen;
  • bei unbekannter/alter Version den Zustand als unverified behandeln.

BungeeGuard ist besonders auf Shared Hosting nützlich, ersetzt aber eine verfügbare Firewall-/Privatnetzlösung nicht als erste Schutzschicht.

Verifikation: vier getrennte Signale

  1. Prozess: Proxy und Backend sind vollständig gestartet.
  2. TCP: Der Proxy erreicht den Backendlistener.
  3. Lobby-Join: Ein echter authentifizierter Spieler gelangt über den Proxy ins Backend.
  4. Identität: Backend sieht erwartete Online-UUID und Client-IP, nicht Offline-UUID oder nur Proxy-IP.

Danach folgt der Negativtest: Eine unabhängige Quelle darf den Backendport nicht erreichen. Ein offener Listener oder erfolgreicher Ping allein ist kein Joinbeweis.

Typische Fehler

Symptom Ursache Nächster Schritt
alle Spieler haben Proxy-IP ip_forward oder bungeecord aus beide Seiten prüfen, vollständig neu starten
Spieler hat neues Inventar UUID-Modus wechselte Backup behalten, UUIDs vergleichen, plugin-spezifisch migrieren
If you wish to use IP forwarding... Backend erwartet Forwarding, Proxy sendet es nicht Proxywert und exakte gestartete config prüfen
direkter Join unter fremdem Namen möglich Backend öffentlich erreichbar Firewall/Privatnetz sofort korrigieren
Proxy erreicht Backend ebenfalls nicht Freigabe hat falsche/stale Quelle konkrete Proxyzuordnung neu bewerten, nicht breit öffnen
nach BungeeGuard-Update kein Join Token inkonsistent redigiert Versionen prüfen, koordiniert rotieren

Bei fehlendem Startziel hilft der Fallback-Fehlerleitfaden. Domains zeigen weiterhin auf den Proxy; nutze dafür den Domain-/SRV-Guide.

Plugins und Crossplay

Permission-, Ban- und Economy-Plugins sind besonders UUID-sensibel. Sichere ihre Daten und prüfe, ob eine Proxy- und Backendkomponente erforderlich ist. Der Plugin-Guide erklärt die Plattformtrennung.

Geyser wird in einem Proxy-Netz nur auf dem Proxy installiert. Bedrock-UDP und Java-TCP bleiben getrennte Pfade; key.pem ist geheim. Richte Geyser/Floodgate erst ein, wenn der Java-Forwarding- und Negativpfad grün ist.

FAQ

Ist ip_forward: true ein Schutz?

Nein. Es sorgt nur dafür, dass IP, UUID und Profil ans Backend weitergereicht werden. Das klassische Format hat kein proxy-spezifisches Signatur-Secret: Wer ein ungeschütztes Offline-Mode-Backend direkt erreicht, kann diese Daten fälschen. Der Schutz ist die Netzwerkgrenze, nicht die Einstellung.

Warum steht auf dem Backend online-mode=false?

Weil die Authentifizierung gegen Mojang bereits am Proxy stattfindet — das Backend würde sie sonst ein zweites Mal verlangen und jeden Spieler abweisen. Bei Paper bleibt proxies.bungee-cord.online-mode trotzdem true: Dieser Wert spiegelt den Online-Mode des Proxys, nicht den des Backends.

Warum haben Spieler nach der Umstellung ein leeres Inventar?

Weil sich die UUID geändert hat. Ohne Forwarding erzeugt ein Offline-Mode-Backend die UUID aus dem Spielernamen, mit Forwarding kommt die echte Online-UUID an. Die alten Daten sind nicht verloren, sie liegen unter der alten UUID — deshalb gehört ein getestetes Backup vor die Änderung.

Brauche ich BungeeGuard?

Es ergänzt das Legacy-Format um einen gemeinsamen Token und ist vor allem auf Shared Hosting nützlich, wo du keine eigene Firewallregel setzen kannst. Nutze mindestens Version 1.4.0 und rotiere den Token nach einem Upgrade. Eine verfügbare Firewall- oder Privatnetzlösung ersetzt es nicht.

Wohin gehört Geyser in einem Proxy-Netzwerk?

Ausschließlich auf den Proxy, nicht zusätzlich auf die Backends. Bedrock läuft über UDP, Java über TCP — beide Pfade werden getrennt geprüft, und key.pem ist geheim. Richte Crossplay erst ein, wenn Forwarding und Negativtest auf der Java-Seite grün sind.

Primärquellen

Eine UUID-Abweichung sicher eingrenzen

Wähle vor der Umstellung einen bekannten Testspieler und notiere dessen bisherige UUID und Datenquelle. Prüfe nach dem Proxybeitritt Inventar, Enderchest und Rechte zusammen. Ist nur ein Bereich leer, kontrolliere dessen Plugin- oder Datenbankspeicherung; fehlen alle Bereiche, prüfe die Forwarding-Kette und Identität. Kopiere keine Dateien allein nach dem sichtbaren Spielernamen, weil unterschiedliche UUIDs denselben Namen betreffen können. Halte den Backend-Port geschlossen und nimm bei einem widersprüchlichen Ergebnis die zusammengehörige Konfigurationsänderung zurück. Erst eine dokumentierte Zuordnung erlaubt eine gezielte Datenmigration.

BungeeCord IP Forwarding sicher einrichten: Backup und UUID-Baseline → Proxy konfigurieren → Backends konfigurieren → Netzwerkzugriff schließen → Identität und Negativpfad testen
BungeeCord IP Forwarding sicher einrichten: Backup und UUID-Baseline → Proxy konfigurieren → Backends konfigurieren → Netzwerkzugriff schließen → Identität und Negativpfad testen