BungeeCord IP Forwarding sorgt dafür, dass ein Backend die echte Spieler-IP, Online-UUID und Profilinformationen erhält, obwohl die TCP-Verbindung vom Proxy kommt. Dafür müssen vier Werte zusammenpassen – und der Backend-Port muss gegen direkte Verbindungen geschützt sein.

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.

Primärquellen