BungeeCord einrichten: Minecraft-Server sicher verbinden

BungeeCord verbindet mehrere Minecraft-Java-Server unter einer gemeinsamen Adresse. Der Proxy authentifiziert den Spieler und leitet ihn an Lobby, Survival oder andere Backends weiter. Er hostet selbst keine Welt. Ein minimales Netzwerk braucht deshalb mindestens zwei getrennte Prozesse oder Hosting-Instanzen: einen BungeeCord-Proxy und ein Minecraft-Backend.

Die wichtigste Sicherheitsregel: Backends laufen hinter BungeeCord im Offline-Mode. Sie dürfen deshalb niemals frei aus dem Internet erreichbar sein. ip_forward: true überträgt Identität, ist aber keine Zugangskontrolle. Schließe den Firewall-/Privatnetzschutz ab, bevor du das Netzwerk als fertig betrachtest.

So sieht ein BungeeCord-Netzwerk aus

Minecraft Java Client
        |
        | öffentliche Proxy-Adresse
        v
 BungeeCord (online_mode=true, ip_forward=true)
        |
        | nur freigegebener Proxy-Pfad
        +---------------------+
        v                     v
 Lobby / Paper          Survival / Paper
 online-mode=false      online-mode=false
 bungeecord=true        bungeecord=true

Der Proxy übernimmt Login, öffentliche Adresse, Routing und Proxy-Befehle. Die Backends speichern Welten, Inventare und Bukkit-/Paper-Plugin-Daten. BungeeCord synchronisiert diese Daten nicht automatisch. Netzwerkweite Ränge, Bans oder Inventare brauchen dafür geeignete Plugins und meist eine gemeinsame Datenbank.

Welche Topologie passt?

Die BungeeCord-Konfiguration sieht in allen Varianten ähnlich aus, der sichere Netzwerkpfad aber nicht. Entscheide die Topologie, bevor du Adressen in config.yml einträgst.

Proxy und Backend auf derselben Node

Zwei Hosting-Instanzen auf derselben Node sind weiterhin getrennte Container. Der Proxy kann das Backend über die dafür vorgesehene interne Adresse erreichen; eine fremde Instanz auf derselben Bridge darf es nicht. Eine Freigabe des gesamten Docker-Subnetzes wäre deshalb zu breit. Der Schutz muss an die konkrete Proxyquelle gebunden bleiben und sich nach einem Containerneustart neu auflösen.

Proxy und Backend auf unterschiedlichen Nodes

Hier läuft der Pfad über das Node-Netz. Erlaube am Backend exakt die Quelle des zugehörigen Proxys und den konkreten TCP-Port. Öffne nicht versehentlich UDP, einen Portbereich oder die komplette Node-IP für andere Kundeninstanzen. Prüfe den positiven Pfad vom Proxy und den negativen Pfad von einer unabhängigen Quelle im selben Zeitfenster.

Externes Backend

Ein Backend außerhalb der Hostingplattform benötigt eine Route, die der BungeeCord-Proxy erreichen kann. Der Betreiber des externen Systems verantwortet dessen Firewall. Ein Reverse-Tunnel oder VPN kann den Transport herstellen, ist aber nur dann sicher, wenn das Backend lokal gebunden bleibt und ausschließlich der autorisierte Proxypfad durchgereicht wird. Produkttexte dürfen diese Variante erst als sicher bezeichnen, wenn Positiv- und Negativpfad für das konkrete Setup geprüft wurden.

Mehrere Proxys

Mehrere Proxys für Hochverfügbarkeit sind ein eigenes Design. Jeder zulässige Quellpfad, die gemeinsame Plugin-/Datenhaltung und der Umgang mit Sessions müssen explizit geplant werden. Kopiere nicht einfach eine weitere IP in eine breite Allowlist. Dieser Guide beschreibt bewusst einen zugeordneten Proxy pro Backendpfad.

Voraussetzungen und Kostenmodell

Du brauchst:

• eine BungeeCord-Instanz;
• mindestens einen separaten Paper-/Spigot-Server als Backend;
• je Prozess einen eindeutigen TCP-Port;
• einen erreichbaren Pfad vom Proxy zum Backend;
• eine Firewall, ein privates Netz oder eine vergleichbar geprüfte Zugriffskontrolle;
• ein getestetes Backup vor dem Umbau eines bestehenden Servers.

Auf game-serverhosting ist BungeeCord eine eigene Server-Software. Plane Proxy und Backends als getrennte Instanzen. Wenn du noch keine Instanzen hast, beginne bei der Minecraft-Server-Bestellung. Die aktuelle BungeeCord-Codebasis kompiliert gegen Java 17; das angebotene Egg läuft mit Java 21. Verlasse dich nicht auf alte pauschale Aussagen wie „512 MB für 500 Spieler“: Plugins, Verbindungsrate, Kompression und Angriffe verändern den Bedarf erheblich.

Schritt 1: Architektur und Ports notieren

Gib jeder Instanz einen Namen und eine Rolle. Ein einfaches Beispiel:

127.0.0.1 funktioniert nur, wenn Proxy und Backend denselben Netzwerk-Namespace teilen. Zwei Pterodactyl-Container auf demselben Host sind nicht automatisch über Loopback verbunden. Nutze exakt die Backend-Adresse, die dein Proxy erreichen kann, und öffne deshalb niemals vorsorglich ein ganzes Container-Subnetz.

Schritt 2: Vorhandene Server sichern

Vor Änderungen an Online-Mode oder Forwarding sicherst du Welten, playerdata, Plugin-Datenbanken und Konfigurationsdateien. Führe mindestens einen Test-Restore durch. Beim Wechsel von Offline- auf Online-UUIDs können Spieler wie neue Konten erscheinen, obwohl ihre alten Dateien noch vorhanden sind. Der Guide zum sicheren Versionswechsel erklärt den Backup-, Kopie- und Rollbackpfad, den du auch für diese Migration verwenden solltest.

Schritt 3: Proxy starten und config.yml bearbeiten

Starte BungeeCord einmal und stoppe den Proxy danach sauber. So entsteht eine zur installierten Version passende config.yml. Die vollständige Feldreferenz findest du in BungeeCord config.yml erklärt.

Ein minimales, gekürztes Modell sieht so aus:

online_mode: true
ip_forward: true
player_limit: -1

servers:
  lobby:
    address: <LOBBY-ADRESSE>:<LOBBY-PORT>
    motd: '&aLobby'
    restricted: false
  survival:
    address: <SURVIVAL-ADRESSE>:<SURVIVAL-PORT>
    motd: '&aSurvival'
    restricted: false

listeners:
  - host: 0.0.0.0:<PROXY-PORT>
    priorities:
      - lobby
      - survival
    force_default_server: true
    max_players: 100

max_players beeinflusst die angezeigte Slotzahl. Die globale harte Grenze ist player_limit; Werte von null oder kleiner bedeuten dort unbegrenzt. Backendnamen unter priorities müssen exakt mit den Schlüsseln unter servers übereinstimmen.

Schritt 4: Backends für Forwarding konfigurieren

Auf jedem Paper-/Spigot-Backend:

# server.properties
online-mode=false

# spigot.yml
settings:
  bungeecord: true

Bei aktuellem Paper prüfst du zusätzlich in config/paper-global.yml:

proxies:
  bungee-cord:
    online-mode: true

Dieser Paper-Wert beschreibt den Online-Mode des Proxys und soll dazu passen. Er widerspricht nicht dem online-mode=false in server.properties. Die vier Werte und die UUID-/Backup-Folgen erklärt BungeeCord IP Forwarding sicher einrichten im Detail.

Schritt 5: Backendzugriff absichern

Jetzt kommt der Schritt, der in vielen alten Tutorials fehlt. Erlaube den Backend-TCP-Port ausschließlich vom zugehörigen Proxy oder binde ihn an ein wirklich gemeinsames privates Netz. Eine bloße interne IP, restricted: true oder bungeecord: true ist kein Sicherheitsnachweis.

Auf game-serverhosting wird der zulässige Proxy-Pfad für unterstützte BungeeCord-Topologien durch den aktiven Backend-Guard aus der konkreten Proxy-Instanz abgeleitet. Fehlt oder stoppt die Quelle, bleibt der Pfad Drop-only. Für ein extern betriebenes Backend musst du dessen Firewall selbst so konfigurieren, dass nur der verifizierte Proxy-Pfad zugelassen ist.

BungeeGuard kann auf Shared Hosting zusätzlichen Tokenschutz liefern. Nutze mindestens Version 1.4.0; ältere betroffene Installationen müssen upgraden und den Token rotieren. Der Token gehört nie in Tickets, Screenshots oder Logs. BungeeGuard ergänzt den Netzwerkschutz und macht eine erreichbare Angriffsfläche nicht automatisch unsichtbar.

Schritt 6: Startreihenfolge und echte Tests

Starte zuerst die Backends und danach den Proxy. Prüfe mehr als einen offenen Port:

1. Proxyprozess läuft und lauscht auf der zugewiesenen Allokation.
2. Der Proxy erreicht die Lobby-Adresse per TCP.
3. Minecraft-Ping über die öffentliche Proxy-Adresse funktioniert.
4. Ein echter Testaccount landet in der Lobby und kann den Server wechseln.
5. IP und Online-UUID kommen am Backend korrekt an.
6. Ein unabhängiger Direktzugriff auf den Backend-Port scheitert.

Erst Punkt 6 macht aus einem funktionierenden Forwarding-Pfad ein abgesichertes Ergebnis. Scheitert der Einstieg, arbeite den Diagnosebaum für „Could not connect to a default or fallback server“ ab, ohne dafür die Firewall pauschal zu öffnen.

Routing, Fallback und Wartung planen

priorities ist nicht nur eine Liste für den ersten Join. Sie bestimmt auch, welche Ziele BungeeCord nacheinander probiert, wenn ein Server ausfällt. Stelle an die erste Position ein kleines, zuverlässig kompatibles Backend. Ein Survival-Server mit schwerem Modpack ist selten der beste technische Fallback.

forced_hosts kann unterschiedliche Domains auf unterschiedliche Startziele legen. Beispiel: creative.example.net startet auf creative, während play.example.net in der Lobby beginnt. Beide DNS-Namen zeigen auf denselben Proxy. Teste jeden Hostnamen separat, weil ein funktionierender Default nichts über einen Tippfehler im Forced-Host-Mapping aussagt.

restricted: true ist sinnvoll für Wartungs- oder Teamserver. Die dazugehörige Permission bungeecord.server.<name> muss auf Proxyebene ausgewertet werden. Sie verhindert, dass ein normaler Spieler über BungeeCord wechselt, schützt aber nicht vor einem direkten TCP-Zugriff auf das Backend.

Für Wartung empfiehlt sich dieser Ablauf:

1. Zielserver aus der öffentlich genutzten Priorität nehmen oder per Permission sperren.
2. Verbundene Spieler kontrolliert auf ein gesundes Backend verschieben.
3. Backend sichern und warten.
4. Proxy-zu-Backend-TCP und einen echten Testjoin prüfen.
5. Erst dann Routing wieder freigeben.

Ein Proxy-Neustart trennt alle über ihn verbundenen Spieler. Die Welten laufen auf den Backends weiter, doch der Neustart ist trotzdem eine sichtbare Unterbrechung und gehört in ein Wartungsfenster.

Sicherheitsreview vor der Freigabe

Gehe diese Grenze einmal aus Angreifersicht durch:

• Ist nur der Proxy als öffentliche Minecraft-Adresse dokumentiert?
• Ist jeder Backendport von einer unabhängigen Workstation blockiert?
• Kann eine andere Instanz auf derselben Shared-Node/Bridge den Port erreichen?
• Wird die aktuelle Proxyquelle nach Stop/Start neu bewertet?
• Bleibt ein gestoppter oder nicht eindeutig auflösbarer Proxy fail-closed?
• Sind Tokens, vollständige IPs und key.pem aus Screenshots und Supportlogs entfernt?
• Hat nur ein kleiner Personenkreis Permissions wie /ip, /send, /alert und /end?
• Sind alle registrierten Backends vertrauenswürdig? Backends können über Plugin Messaging Einfluss auf den Verbund nehmen.

Wenn du eine Frage nicht mit einem Test oder einer konkreten Regel beantworten kannst, ist der Zustand unverified, nicht „wahrscheinlich sicher“. Das ist besonders wichtig auf Shared Hosting: Eine intern wirkende Adresse belegt noch keine Mandantentrennung.

Backups, Updates und Monitoring

BungeeCord besitzt keine Welt, aber sein Zustand ist trotzdem wiederherstellungsrelevant. Sichere vor Updates:

• config.yml und modules.yml;
• Proxy-plugins/ samt Konfigurationen;
• lokale oder externe Plugin-Datenbanken konsistent;
• verwendete BungeeCord-Build- und Java-Version;
• redigierte Dokumentation der Backendnamen, Ports und Schutzregeln.

Welten, playerdata und Bukkit-/Paper-Plugin-Daten werden separat auf den Backends gesichert. Ein Proxybackup ersetzt kein Weltbackup. Prüfe nach einem Restore nicht nur, ob Dateien vorhanden sind, sondern ob Lobbyjoin, UUID, Permissions und Serverwechsel wieder stimmen.

Für ein Update stoppst du den Proxy sauber, tauschst nur das JAR beziehungsweise nutzt den vorgesehenen Installer und prüfst zuerst das Startlog. Danach folgen Minecraft-Ping, echter Join, Identität, Fallback und der weiterhin blockierte Direktpfad. Halte das letzte funktionierende JAR plus passende Konfiguration als Rollback bereit.

Monitoring trennt mindestens diese Signale:

Beobachte zusätzlich Heap/GC, Event-Loop-Blockaden, Plugin-Exceptions, Backend-Timeouts und ungewöhnliche Verbindungsraten. Ein grünes Dashboardfeld darf mehrere dieser Zustände nicht zu einem pauschalen „online“ zusammenziehen.

Häufige Setup-Fehler vermeiden

• Proxyport und Backendport vertauscht: Spieler landen direkt auf dem Offline-Mode-Backend oder BungeeCord verbindet sich selbst.
• Öffentliche Domain als Backendadresse: Der Proxy läuft in eine DNS-/Routing-Schleife. Nutze die konkrete interne Zieladresse.
• max_players als harte Grenze gelesen: Die Serverliste zeigt den Wert, während player_limit weiterhin unbegrenzt sein kann.
• Nur einen TCP-Test gemacht: Der Listener ist offen, aber Lobby, Forwarding oder Protokoll scheitern.
• Firewall zum Debuggen deaktiviert: Der positive Join geht, während gleichzeitig ein Identitäts-Bypass offen bleibt.
• Bukkit-Plugin auf dem Proxy installiert: Plattform oder Abhängigkeiten passen nicht; lies den Descriptor und die Projektseite.
• /greload nach tiefen Änderungen: Teile der Konfiguration oder Plugins bleiben im alten Zustand. Nutze einen vollständigen Neustart.
• Backup ohne Restoretest: Erst im Fehlerfall zeigt sich, dass Datenbank, Welten oder Pluginzustand nicht konsistent gesichert wurden.

Domain und SRV auf den Proxy richten

DNS zeigt immer auf den öffentlichen Proxy. Bei einem abweichenden Java-Port kann ein SRV-Record _minecraft._tcp den Port abbilden. Der SRV-Target muss ein Hostname sein, keine IP. Die genauen A-/CNAME-/SRV-Schritte stehen im Guide Eigene Domain mit deinem Gameserver verbinden.

Forced Hosts ändern daran nichts: Sie nutzen den vom Client angefragten Hostnamen nur als Routinginformation. Auch survival.example.net zeigt zunächst auf den Proxy; erst BungeeCord leitet intern auf survival weiter.

Plugins und Permissions richtig verteilen

• BungeeCord-Plugins gehören in plugins/ des Proxys.
• Bukkit-/Paper-Plugins gehören auf das jeweilige Backend.
• Manche Netzwerkplugins benötigen Komponenten auf beiden Ebenen.
• Proxy-Permissions sind nicht automatisch in einem reinen Backend-Permission-Plugin vorhanden.
• Nach Pluginänderungen ist ein vollständiger geplanter Neustart zuverlässiger als /greload.

Nutze nur Plugins aus vertrauenswürdigen Quellen und prüfe Plattform, Version, Abhängigkeiten und Security-Hinweise. Der Plugin-Guide zeigt den Panelpfad für Paper-/Spigot-Plugins; Proxy-Plugins musst du ausdrücklich als BungeeCord-kompatibel erkennen.

Bedrock-Crossplay mit Geyser

In einem BungeeCord-Netz installierst du Geyser auf dem Proxy, nicht auf jedem Backend. Java verwendet TCP, der Bedrock-Listener UDP. Floodgate genügt am Proxy, sofern Backend-Plugins weder dessen API noch die zusätzliche Skin-Unterstützung brauchen. key.pem ist ein Authentifizierungsgeheimnis.

Die Port- und Joinprüfung bleibt für TCP und UDP getrennt. Nutze den Geyser-/Floodgate-Crossplay-Guide, nachdem der reine Java-Pfad sicher funktioniert.

BungeeCord oder Velocity?

BungeeCord ist 2026 weiterhin aktiv gebaut. Waterfall, der frühere PaperMC-Fork, ist dagegen End of Life. PaperMC empfiehlt für neue Netzwerke Velocity und weist selbst darauf hin, dass der eigene Vergleich zugunsten des eigenen Produkts gefärbt sein kann.

Für ein bestehendes Netzwerk mit wichtigen BungeeCord-Plugins kann BungeeCord die risikoärmere Wahl sein. Für ein neues Netzwerk auf aktuellen Paper-Versionen bietet Velocity Modern Forwarding mit einem geheimen, MAC-geschützten Format. Entscheide nicht anhand pauschaler Performancezahlen, sondern anhand von Versionen, Plugin-API, Forwarding und Migration. Der Artikel BungeeCord vs Velocity 2026 enthält die Entscheidungsmatrix.

FAQ

Ist BungeeCord ein Minecraft-Server?

Nein. BungeeCord ist ein Proxy. Welten, Chunks, Mobs und Spielmodi laufen auf getrennten Backends.

Wie viele Server brauche ich?

Mindestens zwei Prozesse oder Instanzen: Proxy und ein Backend. Für Lobby plus Spielmodus sind drei Instanzen sinnvoll.

Muss der Proxy im Online-Mode laufen?

Für ein normales authentifiziertes Netzwerk ja: online_mode: true am Proxy. Die Backends verwenden online-mode=false, weil der Proxy bereits authentifiziert hat.

Ist ip_forward sicher?

Es ist für echte IPs und Online-UUIDs nötig, aber allein nicht sicher. Legacy-Forwarding besitzt kein proxy-spezifisches Signatur-Secret. Der Backend-Port muss vor untrusted Quellen geschützt sein.

Startet ein Proxy-Neustart meine Welten neu?

Nein. Die Backends laufen weiter, aber die über den Proxy verbundenen Spieler werden getrennt.

Brauche ich eine Lobby?

Nicht zwingend. Mindestens ein erreichbares Ziel in priorities ist nötig; eine eigene Lobby macht Fallback und Wartung meist übersichtlicher.

Welche Ports braucht BungeeCord?

Der öffentliche Java-Listener verwendet TCP. Jedes Backend benötigt einen eigenen, nur für den Proxy erreichbaren TCP-Port. Query und Geyser/Bedrock verwenden bei Aktivierung getrennte UDP-Ports; öffne sie nicht, wenn die Funktion nicht genutzt wird.

Kann ich Paper-Plugins auf BungeeCord installieren?

Nein, nicht pauschal. Paper-/Bukkit-Plugins gehören auf Backends. Der Proxy braucht ausdrücklich für BungeeCord gebaute Plugins. Netzwerkplugins können zwei getrennte Komponenten liefern.

Warum sieht mein Backend nur die Proxy-IP?

Meist ist ip_forward am Proxy oder settings.bungeecord am Backend deaktiviert. Prüfe beide Seiten und starte vollständig neu. Ändere UUID-relevante Werte erst nach Backup.

Kann ich mehrere Domains verwenden?

Ja. Alle Domains zeigen auf den Proxy. forced_hosts kann den angefragten Hostnamen anschließend einem Startbackend zuordnen.

Funktioniert Crossplay automatisch auf jedem Backend?

Geyser übersetzt Bedrock am Proxy. Die Backends müssen die von Geyser emulierte Java-Protokollversion akzeptieren; bei Versionsabständen kann ein bewusst geprüftes ViaVersion-Setup nötig sein. UDP-Erreichbarkeit wird getrennt von Java-TCP getestet.

Abschlusscheck

Das Netzwerk ist erst fertig, wenn der echte Join über den Proxy gelingt und ein unabhängiger Direktjoin zum Offline-Mode-Backend blockiert ist. Dokumentiere Adressen und Regeln redigiert, sichere Konfiguration und Weltdaten getrennt und setze den nächsten fachlichen Review vor dem angegebenen Termin an, wenn BungeeCord, Java, BungeeGuard, Paper, Velocity oder Geyser einen relevanten Release veröffentlicht.

Bewahre für spätere Supportfälle außerdem Zeitpunkt und Zeitzone des Tests, Proxy-/Backendversionen und die erste konkrete Fehlermeldung auf. Maskiere dabei Spieler-IP-Adressen und entferne Secrets vollständig. So lässt sich ein späterer Unterschied zwischen Prozess-, Netzwerk-, Protokoll-, Identitäts- und Pluginfehler nachvollziehen, ohne sensible Kundendaten in eine dauerhafte Wissensbasis zu übernehmen.