BungeeCord verbindt meerdere Minecraft Java-servers onder één gezamenlijk adres. De proxy authenticeert de speler en stuurt hem door naar lobby, survival of andere backends. Hij host zelf geen wereld. Een minimaal netwerk heeft daarom minstens twee gescheiden processen of hostinginstanties nodig: één BungeeCord-proxy en één Minecraft-backend.

De belangrijkste beveiligingsregel: backends draaien achter BungeeCord in de offline-modus. Ze mogen daarom nooit vrij vanaf het internet bereikbaar zijn. ip_forward: true draagt identiteit over, maar is geen toegangscontrole. Rond de firewall-/privénetwerkbeveiliging af voordat je het netwerk als voltooid beschouwt.

Zo ziet een BungeeCord-netwerk eruit

Minecraft Java Client
        |
        | publiek proxy-adres
        v
 BungeeCord (online_mode=true, ip_forward=true)
        |
        | alleen vrijgegeven proxy-pad
        +---------------------+
        v                     v
 Lobby / Paper          Survival / Paper
 online-mode=false      online-mode=false
 bungeecord=true        bungeecord=true

De proxy verzorgt login, publiek adres, routing en proxycommando's. De backends slaan werelden, inventarissen en Bukkit-/Paper-plugingegevens op. BungeeCord synchroniseert deze gegevens niet automatisch. Netwerkbrede rangen, bans of inventarissen vereisen daarvoor geschikte plugins en meestal een gedeelde database.

Welke topologie past bij jou?

De BungeeCord-configuratie ziet er in alle varianten vergelijkbaar uit, maar het veilige netwerkpad niet. Bepaal de topologie voordat je adressen in config.yml invoert.

Proxy en backend op dezelfde node

Twee hostinginstanties op dezelfde node blijven gescheiden containers. De proxy kan de backend via het daarvoor bedoelde interne adres bereiken; een vreemde instantie op dezelfde bridge mag dat niet. Het vrijgeven van het volledige Docker-subnet zou daarom te breed zijn. De beveiliging moet gebonden blijven aan de concrete proxybron en na een containerherstart opnieuw worden herleid.

Proxy en backend op verschillende nodes

Hier loopt het pad via het nodenetwerk. Sta op de backend uitsluitend de bron van de bijbehorende proxy en de concrete TCP-poort toe. Open niet per ongeluk UDP, een poortbereik of het volledige node-IP voor andere klantinstanties. Test het positieve pad vanaf de proxy en het negatieve pad vanaf een onafhankelijke bron binnen hetzelfde tijdvenster.

Externe backend

Een backend buiten het hostingplatform heeft een route nodig die de BungeeCord-proxy kan bereiken. De beheerder van het externe systeem is verantwoordelijk voor de firewall daarvan. Een reverse-tunnel of VPN kan het transport tot stand brengen, maar is alleen veilig als de backend lokaal gebonden blijft en uitsluitend het geautoriseerde proxypad wordt doorgelaten. Producttitels mogen deze variant pas veilig noemen als het positieve en negatieve pad voor de concrete opzet zijn getest.

Meerdere proxy's

Meerdere proxy's voor hoge beschikbaarheid vormen een apart ontwerp. Elk toegestaan bronpad, de gedeelde plugin-/gegevensopslag en de omgang met sessies moeten expliciet worden gepland. Kopieer niet zomaar nog een IP naar een brede allowlist. Deze gids beschrijft bewust één toegewezen proxy per backendpad.

Vereisten en kostenmodel

Je hebt nodig:

  • een BungeeCord-instantie;
  • minstens één aparte Paper-/Spigot-server als backend;
  • per proces een unieke TCP-poort;
  • een bereikbaar pad van de proxy naar de backend;
  • een firewall, een privénetwerk of een vergelijkbaar geverifieerde toegangscontrole;
  • een geteste back-up vóór het ombouwen van een bestaande server.

Op game-serverhosting is BungeeCord een aparte serversoftware. Plan proxy en backends als gescheiden instanties. Heb je nog geen instanties, begin dan bij het bestellen van een Minecraft-server. De actuele BungeeCord-codebasis compileert tegen Java 17; het aangeboden Egg draait op Java 21. Vertrouw niet op oude, algemene uitspraken zoals „512 MB voor 500 spelers": plugins, verbindingssnelheid, compressie en aanvallen veranderen de behoefte aanzienlijk.

Stap 1: architectuur en poorten noteren

Geef elke instantie een naam en een rol. Een eenvoudig voorbeeld:

Rol publiek bereikbaar? Voorbeeldpoort
BungeeCord-proxy ja 25565/TCP
Lobby-backend nee eigen TCP-poort
Survival-backend nee eigen TCP-poort
Geyser op de proxy optioneel eigen UDP-poort

127.0.0.1 werkt alleen als proxy en backend dezelfde netwerk-namespace delen. Twee Pterodactyl-containers op dezelfde host zijn niet automatisch via loopback verbonden. Gebruik exact het backend-adres dat jouw proxy kan bereiken, en open daarom nooit uit voorzorg een heel container-subnet.

Stap 2: bestaande servers back-uppen

Voordat je iets wijzigt aan online-modus of forwarding, maak je een back-up van werelden, playerdata, plugindatabases en configuratiebestanden. Voer minstens één test-restore uit. Bij de overgang van offline- naar online-UUID's kunnen spelers lijken op nieuwe accounts, ook al bestaan hun oude bestanden nog. De gids voor veilig versiewisselen legt het back-up-, kopieer- en rollbackpad uit dat je ook voor deze migratie moet gebruiken.

Stap 3: proxy starten en config.yml bewerken

Start BungeeCord één keer en stop de proxy daarna netjes. Zo ontstaat een config.yml die bij de geïnstalleerde versie past. De volledige veldreferentie vind je in BungeeCord config.yml uitgelegd.

Een minimaal, verkort model ziet er zo uit:

online_mode: true
ip_forward: true
player_limit: -1

servers:
  lobby:
    address: <LOBBY-ADRES>:<LOBBY-PORT>
    motd: '&aLobby'
    restricted: false
  survival:
    address: <SURVIVAL-ADRES>:<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 beïnvloedt het weergegeven aantal sloten. De globale harde grens is player_limit; waarden van nul of lager betekenen daar onbeperkt. Backendnamen onder priorities moeten exact overeenkomen met de sleutels onder servers.

Stap 4: backends configureren voor forwarding

Op elke Paper-/Spigot-backend:

# server.properties
online-mode=false

# spigot.yml
settings:
  bungeecord: true

Bij een actuele Paper controleer je bovendien in config/paper-global.yml:

proxies:
  bungee-cord:
    online-mode: true

Deze Paper-waarde beschrijft de online-modus van de proxy en moet daarmee overeenkomen. Ze is niet in tegenspraak met online-mode=false in server.properties. De vier waarden en de UUID-/back-upgevolgen worden in detail uitgelegd in BungeeCord IP-forwarding veilig instellen.

Stap 5: backendtoegang beveiligen

Nu volgt de stap die in veel oude tutorials ontbreekt. Sta de backend-TCP-poort uitsluitend toe vanaf de bijbehorende proxy, of bind hem aan een echt gedeeld privénetwerk. Een simpel intern IP-adres, restricted: true of bungeecord: true is geen bewijs van beveiliging.

Op game-serverhosting wordt het toegestane proxypad voor ondersteunde BungeeCord-topologieën door de actieve backend-guard afgeleid uit de concrete proxy-instantie. Ontbreekt of stopt de bron, dan blijft het pad drop-only. Voor een extern gehoste backend moet je zelf de firewall zo configureren dat alleen het geverifieerde proxypad wordt toegelaten.

BungeeGuard kan op shared hosting extra tokenbeveiliging bieden. Gebruik minimaal versie 1.4.0; oudere getroffen installaties moeten upgraden en de token roteren. De token hoort nooit thuis in tickets, screenshots of logs. BungeeGuard vult de netwerkbeveiliging aan en maakt een bereikbaar aanvalsoppervlak niet automatisch onzichtbaar.

Stap 6: startvolgorde en echte tests

Start eerst de backends en daarna de proxy. Controleer meer dan alleen een open poort:

  1. Het proxyproces draait en luistert op de toegewezen allocatie.
  2. De proxy bereikt het lobby-adres via TCP.
  3. Minecraft-ping via het publieke proxy-adres werkt.
  4. Een echt testaccount komt in de lobby terecht en kan van server wisselen.
  5. IP-adres en online-UUID komen correct aan bij de backend.
  6. Een onafhankelijke directe toegang tot de backend-poort mislukt.

Pas punt 6 maakt van een werkend forwarding-pad een beveiligd resultaat. Lukt de instap niet, doorloop dan de diagnoseboom voor „Could not connect to a default or fallback server", zonder daarvoor de firewall zomaar helemaal open te zetten.

Routing, fallback en onderhoud plannen

priorities is niet alleen een lijst voor de eerste join. Het bepaalt ook welke doelen BungeeCord achtereenvolgens probeert als een server uitvalt. Zet op de eerste positie een kleine, betrouwbaar compatibele backend. Een survival-server met een zwaar modpack is zelden de beste technische fallback.

forced_hosts kan verschillende domeinen naar verschillende startdoelen leiden. Voorbeeld: creative.example.net start op creative, terwijl play.example.net in de lobby begint. Beide DNS-namen wijzen naar dezelfde proxy. Test elke hostnaam apart, want een werkende default zegt niets over een typfout in de forced-host-mapping.

restricted: true is zinvol voor onderhouds- of teamservers. De bijbehorende permissie bungeecord.server.<name> moet op proxyniveau worden geëvalueerd. Ze voorkomt dat een gewone speler via BungeeCord overstapt, maar beschermt niet tegen directe TCP-toegang tot de backend.

Voor onderhoud wordt deze werkwijze aanbevolen:

  1. Doelserver uit de publiek gebruikte prioriteit halen of via permissie blokkeren.
  2. Verbonden spelers gecontroleerd naar een gezonde backend verplaatsen.
  3. Backend back-uppen en onderhouden.
  4. Proxy-naar-backend-TCP en een echte testjoin controleren.
  5. Pas daarna routing weer vrijgeven.

Een herstart van de proxy verbreekt de verbinding van alle spelers die erop zijn aangesloten. De werelden blijven draaien op de backends, maar de herstart is toch een zichtbare onderbreking en hoort thuis in een onderhoudsvenster.

Beveiligingsreview vóór de vrijgave

Loop deze grens één keer door vanuit het perspectief van een aanvaller:

  • Is alleen de proxy gedocumenteerd als publiek Minecraft-adres?
  • Is elke backendpoort geblokkeerd vanaf een onafhankelijk werkstation?
  • Kan een andere instantie op dezelfde shared node/bridge de poort bereiken?
  • Wordt de actuele proxybron na stop/start opnieuw geëvalueerd?
  • Blijft een gestopte of niet eenduidig herleidbare proxy fail-closed?
  • Zijn tokens, volledige IP-adressen en key.pem verwijderd uit screenshots en supportlogs?
  • Hebben alleen weinig personen permissies zoals /ip, /send, /alert en /end?
  • Zijn alle geregistreerde backends te vertrouwen? Backends kunnen via plugin messaging invloed uitoefenen op het netwerk.

Kun je een vraag niet beantwoorden met een test of een concrete regel, dan is de status unverified, niet „waarschijnlijk veilig". Dit is vooral belangrijk bij shared hosting: een intern ogend adres bewijst nog geen scheiding tussen klanten.

Back-ups, updates en monitoring

BungeeCord heeft geen wereld, maar de status ervan is toch relevant voor herstel. Maak vóór updates een back-up van:

  • config.yml en modules.yml;
  • de proxy-plugins/-map inclusief configuraties;
  • lokale of externe plugindatabases, consistent;
  • de gebruikte BungeeCord-build- en Java-versie;
  • geredigeerde documentatie van backendnamen, poorten en beveiligingsregels.

Werelden, playerdata en Bukkit-/Paper-plugingegevens worden apart op de backends geback-upt. Een proxybackup vervangt geen wereldbackup. Controleer na een restore niet alleen of bestanden aanwezig zijn, maar ook of lobbyjoin, UUID, permissies en serverwissel weer kloppen.

Voor een update stop je de proxy netjes, vervang je alleen het JAR-bestand of gebruik je de bedoelde installer, en controleer je eerst het startlog. Daarna volgen Minecraft-ping, echte join, identiteit, fallback en het nog steeds geblokkeerde directe pad. Houd het laatst werkende JAR-bestand plus bijbehorende configuratie klaar als rollback.

Monitoring onderscheidt minstens deze signalen:

Signaal Wat het bewijst Wat het niet bewijst
Proces draait Java-proces bestaat Listener of join werkt
TCP-listener open Poort accepteert verbindingen Minecraft-protocol of lobby zijn gezond
Minecraft-ping Proxy antwoordt protocolconform Speler kan een backend betreden
Synthetische lobby-join Volledig positief pad werkt Backend is beschermd tegen directe toegang
Negatieve backendtest Onafhankelijke bron wordt geblokkeerd Alle toegestane proxybronnen werken

Houd daarnaast heap/GC, event-loop-blokkades, plugin-exceptions, backend-timeouts en ongewone verbindingssnelheden in de gaten. Een groen dashboardveld mag meerdere van deze toestanden niet samenvoegen tot een algemeen „online".

Veelvoorkomende opzetfouten vermijden

  • Proxypoort en backendpoort verwisseld: spelers komen direct op de offline-mode-backend terecht, of BungeeCord verbindt met zichzelf.
  • Publiek domein als backendadres: de proxy loopt vast in een DNS-/routinglus. Gebruik het concrete interne doeladres.
  • max_players gelezen als harde grens: de serverlijst toont de waarde, terwijl player_limit nog steeds onbeperkt kan zijn.
  • Slechts één TCP-test uitgevoerd: de listener is open, maar lobby, forwarding of protocol mislukken.
  • Firewall uitgeschakeld om te debuggen: de positieve join werkt, terwijl tegelijk een identiteitsbypass openstaat.
  • Bukkit-plugin op de proxy geïnstalleerd: platform of afhankelijkheden passen niet; lees de descriptor en de projectpagina.
  • /greload na ingrijpende wijzigingen: delen van de configuratie of plugins blijven in de oude staat. Gebruik een volledige herstart.
  • Back-up zonder restoretest: pas bij een storing blijkt dat database, werelden of pluginstatus niet consistent zijn geback-upt.

Domein en SRV naar de proxy richten

DNS wijst altijd naar de publieke proxy. Bij een afwijkende Java-poort kan een SRV-record _minecraft._tcp de poort in kaart brengen. Het SRV-target moet een hostnaam zijn, geen IP-adres. De precieze A-/CNAME-/SRV-stappen staan in de gids Eigen domein aan je gameserver koppelen.

Forced hosts veranderen daar niets aan: ze gebruiken de door de client opgevraagde hostnaam alleen als routinginformatie. Ook survival.example.net wijst eerst naar de proxy; pas BungeeCord leidt intern door naar survival.

Plugins en permissies correct verdelen

  • BungeeCord-plugins horen in de plugins/-map van de proxy.
  • Bukkit-/Paper-plugins horen op de betreffende backend.
  • Sommige netwerkplugins vereisen componenten op beide niveaus.
  • Proxypermissies zijn niet automatisch aanwezig in een puur backend-permissieplugin.
  • Na pluginwijzigingen is een volledige geplande herstart betrouwbaarder dan /greload.

Gebruik alleen plugins uit betrouwbare bronnen en controleer platform, versie, afhankelijkheden en beveiligingswaarschuwingen. De plugingids laat het panelpad voor Paper-/Spigot-plugins zien; proxyplugins moet je uitdrukkelijk als BungeeCord-compatibel herkennen.

Bedrock-crossplay met Geyser

In een BungeeCord-netwerk installeer je Geyser op de proxy, niet op elke backend. Java gebruikt TCP, de Bedrock-listener UDP. Floodgate op de proxy volstaat, mits backendplugins noch de API daarvan, noch de extra skinondersteuning nodig hebben. key.pem is een authenticatiegeheim.

De poort- en joincontrole blijft gescheiden voor TCP en UDP. Gebruik de Geyser-/Floodgate-crossplaygids nadat het pure Java-pad veilig werkt.

BungeeCord of Velocity?

BungeeCord wordt in 2026 nog steeds actief doorontwikkeld. Waterfall, de vroegere PaperMC-fork, is daarentegen end of life. PaperMC beveelt voor nieuwe netwerken Velocity aan en wijst er zelf op dat de eigen vergelijking gekleurd kan zijn ten gunste van het eigen product.

Voor een bestaand netwerk met belangrijke BungeeCord-plugins kan BungeeCord de risicoarmere keuze zijn. Voor een nieuw netwerk op actuele Paper-versies biedt Velocity Modern Forwarding met een geheim, MAC-beschermd formaat. Beslis niet op basis van algemene prestatiecijfers, maar op basis van versies, plugin-API, forwarding en migratie. Het artikel BungeeCord vs Velocity 2026 bevat de beslismatrix.

FAQ

Is BungeeCord een Minecraft-server?

Nee. BungeeCord is een proxy. Werelden, chunks, mobs en spelmodi draaien op gescheiden backends.

Hoeveel servers heb ik nodig?

Minstens twee processen of instanties: een proxy en een backend. Voor lobby plus spelmodus zijn drie instanties zinvol.

Moet de proxy in de online-modus draaien?

Voor een normaal geauthenticeerd netwerk wel: online_mode: true op de proxy. De backends gebruiken online-mode=false, omdat de proxy al heeft geauthenticeerd.

Is ip_forward veilig?

Het is nodig voor echte IP-adressen en online-UUID's, maar op zichzelf niet veilig. Legacy forwarding heeft geen proxyspecifiek signature secret. De backendpoort moet beschermd worden tegen niet-vertrouwde bronnen.

Start een herstart van de proxy mijn werelden opnieuw?

Nee. De backends blijven draaien, maar de spelers die via de proxy verbonden zijn, worden losgekoppeld.

Heb ik een lobby nodig?

Niet per se. Er is minstens één bereikbaar doel in priorities nodig; een eigen lobby maakt fallback en onderhoud meestal overzichtelijker.

Welke poorten heeft BungeeCord nodig?

De publieke Java-listener gebruikt TCP. Elke backend heeft een eigen TCP-poort nodig die alleen voor de proxy bereikbaar is. Query en Geyser/Bedrock gebruiken bij activering aparte UDP-poorten; open ze niet als de functie niet wordt gebruikt.

Kan ik Paper-plugins op BungeeCord installeren?

Nee, niet zonder meer. Paper-/Bukkit-plugins horen op backends. De proxy heeft plugins nodig die uitdrukkelijk voor BungeeCord zijn gebouwd. Netwerkplugins kunnen twee gescheiden componenten leveren.

Waarom ziet mijn backend alleen het proxy-IP?

Meestal is ip_forward op de proxy of settings.bungeecord op de backend uitgeschakeld. Controleer beide kanten en start volledig opnieuw op. Wijzig UUID-relevante waarden pas na een back-up.

Kan ik meerdere domeinen gebruiken?

Ja. Alle domeinen wijzen naar de proxy. forced_hosts kan de opgevraagde hostnaam vervolgens aan een startbackend koppelen.

Werkt crossplay automatisch op elke backend?

Geyser vertaalt Bedrock op de proxy. De backends moeten de door Geyser geëmuleerde Java-protocolversie accepteren; bij versieverschillen kan een bewust geteste ViaVersion-opzet nodig zijn. UDP-bereikbaarheid wordt apart van Java-TCP getest.

Afsluitende controle

Het netwerk is pas klaar als de echte join via de proxy lukt en een onafhankelijke directe join naar de offline-mode-backend geblokkeerd is. Documenteer adressen en regels geredigeerd, back-up configuratie en werelddata apart, en plan de volgende inhoudelijke review vóór de aangegeven termijn wanneer BungeeCord, Java, BungeeGuard, Paper, Velocity of Geyser een relevante release uitbrengt.

Bewaar voor latere supportgevallen bovendien het tijdstip en de tijdzone van de test, de proxy-/backendversies en de eerste concrete foutmelding. Maskeer daarbij speler-IP-adressen en verwijder secrets volledig. Zo kan een later onderscheid tussen proces-, netwerk-, protocol-, identiteits- en pluginfouten worden nagegaan, zonder gevoelige klantgegevens in een permanente kennisbank op te nemen.

Primaire bronnen