BungeeCord: Could not connect to a default or fallback server

„Could not connect to a default or fallback server“ heißt, dass BungeeCord keinen erlaubten Startserver erreicht. Prüfe zuerst priorities, aktiven Backendstatus und Adresse aus Proxy-Sicht. Erst danach folgen Forwarding und Protokoll; die Meldung allein ist kein Beleg für eine beschädigte Welt.

Öffne den Backend-Port zur Fehlersuche nicht pauschal für das Internet. Teste aus Sicht des Proxys und erlaube weiterhin nur dessen verifizierten Pfad. Das sichere Zielbild zeigt der BungeeCord-Setup-Pillar.

Diagnosebaum

Existiert jeder priorities-Name unter servers?
├─ nein -> Namen und Groß-/Kleinschreibung korrigieren
└─ ja
   Ist mindestens ein Ziel vollständig gestartet?
   ├─ nein -> Backend-Startfehler lösen
   └─ ja
      Erreicht der Proxy exakt diese Adresse und diesen Port?
      ├─ nein -> Adresse, Allokation, Route und Firewall prüfen
      └─ ja
         Stimmen Forwarding und Versionen?
         ├─ nein -> Konfiguration konsistent korrigieren
         └─ ja -> ersten konkreten Proxy-/Backend-Stacktrace prüfen

1. priorities gegen servers vergleichen

servers:
  lobby:
    address: <LOBBY-ADRESSE>:<PORT>
    restricted: false

listeners:
  - priorities:
      - lobby

lobby, Lobby und lobby sind nicht derselbe Schlüssel. Jeder Eintrag in priorities muss unter servers existieren. Mit mehreren Zielen probiert BungeeCord sie in Reihenfolge; ein kaputtes erstes Ziel darf den zweiten Fallback nicht ebenfalls verdecken.

2. Backend wirklich starten

Ein Containerstatus „running“ reicht nicht. Lies das Backendlog bis zur Fertigmeldung. Typische Startblocker sind:

• EULA nicht akzeptiert;
• falsches Java-Image;
• beschädigte oder inkompatible Plugin-JAR;
• Welt-/Mod-Fehler;
• Port bereits belegt;
• Server hört auf einer anderen Allokation.

Teste anschließend die konkrete servers.<name>.address. Ein Ping auf die Host-IP beweist nicht, dass der Minecraft-TCP-Port erreichbar ist.

3. Adresse aus Proxy-Sicht prüfen

127.0.0.1 zeigt im Proxycontainer auf den Proxycontainer selbst. Nutze es nur, wenn Backend und Proxy nachweislich denselben Netzwerk-Namespace teilen. Bei getrennten Instanzen brauchst du die vom Proxy erreichbare Backendadresse.

Fehlermuster:

Auf game-serverhosting schützt der aktive Backend-Guard die bewiesenen BungeeCord-Pfade. Wenn der Proxy gestoppt ist oder seine konkrete Quelle fehlt, bleibt der Backendpfad absichtlich Drop-only. Starte den richtigen Proxy und warte auf die Neubewertung, statt die Schutzregel zu entfernen.

4. Firewall zielgenau prüfen

Die Firewall muss zwei Aussagen gleichzeitig erfüllen:

1. der zugehörige Proxy erreicht den Backend-TCP-Port;
2. eine unabhängige Quelle erreicht ihn nicht.

Wenn beide scheitern, prüfe zuerst die konkrete Proxy-Zuordnung und Quellauflösung. Wenn beide funktionieren, ist das Backend ungeschützt. Eine Freigabe für ein komplettes Shared-Hosting- oder Docker-Subnetz ist keine saubere Reparatur.

5. Forwarding-Werte vergleichen

Für klassisches BungeeCord mit Paper/Spigot:

• Proxy online_mode: true;
• Proxy ip_forward: true;
• Backend server.properties mit online-mode=false;
• Backend spigot.yml mit settings.bungeecord: true;
• Paper proxies.bungee-cord.online-mode: true, wenn der Proxy online authentifiziert.

Eine Meldung wie If you wish to use IP forwarding... zeigt häufig eine inkonsistente Proxy-/Backendkonfiguration. Ändere diese Werte wegen möglicher UUID-Wechsel nur nach Backup und mit dem Forwarding-Sicherheitsguide.

6. Version und Plugins isolieren

Vergleiche Client-, Proxy- und Backend-Protokoll. Ein offener TCP-Port kann trotzdem einen Join ablehnen. Starte nach Möglichkeit mit Lobby ohne neu hinzugefügte Proxy-Plugins. Installiere BungeeCord-Plugins nur auf dem Proxy und Bukkit/Paper-Plugins nur auf Backends; der Plugin-Guide erklärt die Ebenen.

Entferne Plugins nicht blind aus einer Produktion. Sichere plugins/ und Konfiguration, ändere eine Variable in einer Kopie und rolle bei Misserfolg zurück.

7. Domain erst nach dem Direktpfad prüfen

Teste zuerst die öffentliche Proxy-IP plus Port. Funktioniert sie, aber die Domain nicht, untersuche A/AAAA und SRV getrennt. Der SRV-Targetname muss auf den Proxy zeigen. Nutze den Domain-/SRV-Guide.

Abschlussprüfung

Der Fehler ist erst gelöst, wenn TCP, Minecraft-Ping und echter Lobby-Join über den Proxy grün sind. Wiederhole danach den unabhängigen Negativtest zum Backend. Für einen Umbau oder Versionswechsel verwende vorher den Backup- und Rollbackpfad. Crossplay kommt erst danach; TCP und Geyser-UDP werden getrennt geprüft.

FAQ

Was bedeutet die Meldung genau?

Dass BungeeCord selbst läuft und den Spieler angenommen hat, ihn aber an kein erlaubtes Startziel übergeben konnte. Der Proxy ist damit nicht die Fehlerquelle — die Ursache liegt in priorities, im Backendstatus, in Adresse und Port, in der Firewall, im Forwarding oder in der Protokollversion.

Kann ich 127.0.0.1 als Backendadresse eintragen?

Nur wenn Proxy und Backend nachweislich denselben Netzwerk-Namespace teilen. Im Proxycontainer zeigt 127.0.0.1 auf den Proxycontainer selbst, nicht auf das Backend. Bei getrennten Instanzen brauchst du die Adresse, unter der der Proxy das Backend tatsächlich erreicht.

Connection refused oder Timeout — was ist der Unterschied?

Connection refused heißt, dass am Zielport nichts lauscht oder eine Regel aktiv ablehnt: meist ein nicht gestartetes Backend oder ein falscher Port. Ein Timeout deutet auf eine Route oder Firewall, die Pakete verwirft, auf ein hängendes Ziel oder auf eine falsche Adresse.

Soll ich den Backend-Port zur Fehlersuche kurz öffnen?

Nein. Ein offener Offline-Mode-Backend-Port erlaubt es Fremden, sich als beliebiger Spieler auszugeben. Teste stattdessen aus Sicht des Proxys. Bleibt der Backendpfad blockiert, obwohl der Proxy läuft, prüfe die konkrete Proxy-Zuordnung — und entferne nicht die Schutzregel.

Der TCP-Port ist erreichbar, der Join scheitert trotzdem — woran liegt das?

Ein offener Port beweist nur, dass etwas lauscht. Scheitert der Join danach, vergleiche Client-, Proxy- und Backend-Protokollversion und starte testweise eine Lobby ohne neu hinzugefügte Proxy-Plugins. Prüfe außerdem, ob BungeeCord-Plugins versehentlich auf einem Backend liegen.

Primärquellen

• BungeeCord Installation
• BungeeCord Configuration Guide
• BungeeCord Repository und Security Warning

Zwei Fallbackziele einzeln beurteilen

Prüfe jedes eingetragene Startziel separat: stimmt der Schlüssel, ist der Spielserver vollständig gestartet und kann der Proxy genau dessen TCP-Endpunkt erreichen? Ein zweites Ziel hilft nicht, wenn beide dieselbe falsche Adresse oder Firewallregel verwenden. Halte die erste Fehlermeldung pro Ziel fest, statt nur die zusammenfassende Fallbackmeldung zu kopieren. Funktioniert ein Ziel, setze es für den Test an erste Stelle und bestätige den Join. Nimm anschließend nur die fehlerhafte Route zurück. Die Offline-Mode-Backends bleiben gegen externe Direktverbindungen geschützt.