Could not connect to a default or fallback server bedeutet: BungeeCord läuft, konnte den Spieler aber an kein erlaubtes Startziel übergeben. Die Ursache liegt normalerweise in priorities, Backendstatus, Adresse/Port, Firewall, Forwarding oder Protokollkompatibilität.

Ö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:

Meldung Typische Bedeutung
Connection refused am Zielport lauscht nichts oder eine Regel lehnt aktiv ab
Timeout Route oder Firewall verwirft, Ziel hängt oder Adresse ist falsch
Unknown host DNS-/Hostnamefehler
Address already in use doppelter Listener/Portkonflikt

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.

Primärquellen