BungeeCords config.yml bestimmt Listener, Backendadressen und Startprioritäten. Prüfe Schlüssel, Einrückung und tatsächlich erreichbare Ziele aus Sicht des Proxys. Eine fehlerfreie YAML-Datei schützt Offline-Mode-Backends noch nicht vor Direktzugriff.

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.

FAQ

Warum soll ich die config.yml nicht aus einer Anleitung kopieren?

Weil Felder und Standardwerte sich zwischen den Builds ändern. Lass BungeeCord die Datei mit deiner installierten Version selbst erzeugen und übertrage daraus nur die Werte, die du wirklich anpassen willst. Ein Feld aus einem alten Beispiel kann in deinem Build fehlen oder eine andere Bedeutung haben.

Was ist der Unterschied zwischen max_players und player_limit?

listeners.*.max_players ist reine Anzeige: die Zahl, die Clients in der Serverliste sehen. player_limit ist die harte globale Grenze, ab der der Proxy Verbindungen ablehnt (0 oder kleiner bedeutet unbegrenzt). Setze beide bewusst — eine hohe Anzeige ersetzt keine Kapazitätsmessung.

Reicht restricted: true, um ein Backend zu schützen?

Nein. restricted ist eine BungeeCord-Berechtigung und verlangt bungeecord.server.<name> für den Wechsel über den Proxy. Es hindert niemanden daran, den Backend-Port direkt anzusprechen. Der Schutz dort ist Firewall oder Privatnetz, nicht die Proxykonfiguration.

Muss ich nach einer Änderung neu starten, oder reicht /greload?

Plane einen Neustart ein. /greload liest die Konfiguration erneut, überträgt aber nicht jede Plugin- und Berechtigungsänderung zuverlässig in den laufenden Zustand. Bei Änderungen an Listenern, Servern oder Forwarding ist der vollständige Neustart der einzige belastbare Weg.

Warum darf die Proxydomain nicht als Backendadresse stehen?

Weil der Proxy sich dann selbst als Ziel anspricht und eine Schleife entsteht. Unter servers.<name>.address gehört die Adresse, unter der der Proxyprozess das Backend erreicht — eine interne oder private Adresse, nicht der öffentliche Name, auf den das DNS deines Netzwerks zeigt.

Primärquellen

Eine Routingänderung ohne DNS-Fehlschluss prüfen

Vergleiche jede Listener-Priorität und jeden forced_hosts-Zielnamen mit einem vorhandenen Schlüssel unter servers. Prüfe anschließend die Backendadresse aus dem Proxy-Netzwerk; eine öffentliche Domain kann auf den Proxy selbst zurückzeigen. Teste den Join zuerst über die bekannte Proxyadresse und danach über die Domain. Funktioniert nur einer der Wege, untersuche DNS und Hostrouting getrennt. Sichere die vorige config.yml und nimm nur die betreffende Zieländerung zurück. Backend-Firewall und Forwarding bleiben während dieses Tests aktiv; eine kurzfristige Öffnung aller Ports ist keine YAML-Prüfung.

BungeeCord config.yml erklärt: sichere Einstellungen: Aktuelle Datei erzeugen → Serverziele eintragen → Listener zuordnen → Forwarding abstimmen → Validieren und neu starten
BungeeCord config.yml erklärt: sichere Einstellungen: Aktuelle Datei erzeugen → Serverziele eintragen → Listener zuordnen → Forwarding abstimmen → Validieren und neu starten