Die config.yml definiert, wo BungeeCord lauscht, welche Backends es kennt und wohin neue Spieler geleitet werden. Erzeuge die Datei immer mit deiner installierten Version. Alte Blogbeispiele können Felder oder Defaults enthalten, die nicht mehr zum aktuellen Build passen.

Eine syntaktisch gültige Konfiguration ist noch kein sicheres Netzwerk. Sobald Backends online-mode=false nutzen, muss ihr TCP-Port vor direkten Verbindungen geschützt sein. Der vollständige Ablauf steht im BungeeCord-Setup-Pillar.

Sicheres Grundgerüst

online_mode: true
ip_forward: true
player_limit: -1
server_connect_timeout: 5000
remote_ping_timeout: 5000

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

listeners:
  - host: 0.0.0.0:<PROXY-PORT>
    motd: '&aMein Netzwerk'
    priorities:
      - lobby
      - survival
    force_default_server: true
    forced_hosts:
      survival.example.net: survival
    max_players: 100
    tab_list: GLOBAL_PING
    query_enabled: false
    proxy_protocol: false

Platzhalter müssen durch Paneladressen ersetzt werden. Eine öffentliche Backendadresse im Beispiel ist keine Freigabe, den Port öffentlich offen zu lassen.

Globale Felder

Feld Bedeutung Sichere Einordnung
online_mode Authentifizierung am Proxy für normale Premium-Netze true
ip_forward IP, UUID und Profil ans Backend erforderlich, aber keine Zugangskontrolle
player_limit globale harte Spielergrenze 0 oder kleiner bedeutet unbegrenzt
server_connect_timeout Zeit für Backend-Verbindung zu klein erzeugt Fehlalarme, zu groß lange Wartezeiten
remote_ping_timeout Timeout für Backend-Pings Ping ist nicht dasselbe wie ein echter Join
remote_ping_cache Cache für Backendstatus kann kurzfristig einen alten Status zeigen
connection_throttle Zeitfenster für neue Verbindungen kein vollständiger Bot-/DDoS-Schutz
forge_support zusätzliche Forge-Handshake-Unterstützung Modloader-Kompatibilität separat prüfen

servers: Backends benennen

Jeder Schlüssel unter servers ist ein interner Name. address muss aus Sicht des Proxyprozesses erreichbar sein. restricted: true verlangt die Permission bungeecord.server.<name>, verhindert aber keinen direkten Netzwerkzugriff auf den Backend-Port.

Vermeide dieselbe öffentliche Proxydomain als Backendadresse: Das kann eine Schleife erzeugen. Nutze eine konkrete interne, private oder anderweitig für den Proxy freigegebene Adresse.

listeners: öffentliche Eingänge

host muss zur zugewiesenen Proxy-Allokation passen. priorities ist die geordnete Liste für Start und Fallback. Ein Tippfehler wie Lobby statt lobby reicht, damit kein Standardziel gefunden wird.

force_default_server: true startet neue Verbindungen über die Prioritäten-/Forced-Host-Logik. Bei false kann BungeeCord versuchen, ein zuvor genutztes Ziel wiederherzustellen.

max_players ist nicht player_limit

listeners.*.max_players steuert die angezeigte Spielerzahl in der Serverliste. player_limit ist die globale harte Grenze. Setze beide bewusst; eine hübsche Anzeige ersetzt keine Kapazitätsmessung.

forced_hosts und DNS

forced_hosts ordnet einen Hostnamen einem internen Servernamen zu. DNS zeigt trotzdem auf BungeeCord. Für Domain und abweichenden Port nutze den Domain-/SRV-Guide.

Felder nicht verwechseln

  • proxy_protocol ist für einen vorgeschalteten HAProxy-/PROXY-Protocol-Sender, nicht für normales BungeeCord-Forwarding.
  • query_enabled öffnet bei Bedarf einen separaten UDP-Dienst; aktiviere ihn nicht vorsorglich.
  • ping_passthrough übernimmt MOTD und Status eines Ziels, macht einen Backend-Ausfall aber sichtbarer.
  • restricted ist eine BungeeCord-Permission, keine Firewall.
  • /greload lädt nicht jede Plugin- und Permissionänderung zuverlässig; plane einen Neustart.

Backendseite passend konfigurieren

Setze server.properties auf online-mode=false und settings.bungeecord: true in spigot.yml. Bei Paper muss proxies.bungee-cord.online-mode zum online_mode des Proxys passen. Lies vor einer Änderung den sicheren Forwarding-Guide und erstelle ein getestetes Backup über den im Versionswechsel-Guide beschriebenen Kopie-/Rollbackpfad.

Validierung

  1. Nutze nur Spaces, keine Tabs.
  2. Prüfe Einrückung und Strings mit Sonderzeichen.
  3. Vergleiche alle Namen in priorities und forced_hosts mit servers.
  4. Starte Backend und Proxy vollständig neu.
  5. Teste TCP, Minecraft-Ping und echten Lobby-Join getrennt.
  6. Teste von einer unabhängigen Quelle, dass der Backend-Port blockiert ist.

Wenn BungeeCord keine Lobby erreicht, hilft der Fallback-Fehlerleitfaden. Installiere erst nach diesem Basistest Proxy- und Backend-Plugins auf der richtigen Ebene.

Primärquellen