BungeeCord IP Forwarding zorgt ervoor dat een backend de echte speler-IP, online-UUID en profielinformatie ontvangt, ondanks dat de TCP-verbinding van de proxy komt. Daarvoor moeten vier waarden op elkaar aansluiten – en de backend-poort moet beschermd zijn tegen directe verbindingen.
ip_forward: trueis geen firewall. Het klassieke BungeeCord-formaat heeft geen proxy-specifiek signatuurgeheim. Wie een onbeveiligd offline-mode-backend kan bereiken, kan forwarding-gegevens vervalsen en zich voordoen als een andere speler.
De vier waarden
| Locatie | Bestand/Veld | Normale waarde |
|---|---|---|
| BungeeCord | config.yml → online_mode |
true |
| BungeeCord | config.yml → ip_forward |
true |
| Backend | server.properties → online-mode |
false |
| Backend | spigot.yml → settings.bungeecord |
true |
Voor recente Paper-versies komt daar nog bij:
# config/paper-global.yml
proxies:
bungee-cord:
online-mode: true
Deze Paper-waarde komt overeen met de online-mode van de proxy. Hij blijft true, ondanks dat server.properties op het backend online-mode=false gebruikt.
Waarom je vóór de wijziging een backup moet maken
Zonder forwarding genereert het offline-mode-backend een UUID op basis van de spelernaam. Met correcte forwarding ontvangt het de UUID die uit de online-authenticatie komt. Deze waarden zijn niet identiek. Inventaris, enderchest, rangen of economy-gegevens kunnen daarna verdwenen lijken, ondanks dat ze onder de oude UUID zijn opgeslagen.
Vóór de wijziging:
- maak een backup van werelden,
playerdata, permission- en plugin-databases; - test een restore;
- documenteer de oude en de verwachte UUID voor een testspeler;
- controleer plugin-specifieke migratietools;
- wijzig nooit blindelings bestandsnamen zonder de referenties en het dataformaat te kennen.
De bestaande gids over het wisselen van versie beschrijft een geschikt backup-, kopieer- en rollbackpad.
Stap 1: Proxy instellen
Stop BungeeCord netjes en bewerk de huidige config.yml:
online_mode: true
ip_forward: true
Laat de publieke authenticatie op de proxy actief. Controleer daarnaast listeners, servers en priorities met de config.yml-veldreferentie.
Stap 2: Backend instellen
Stop elk backend volledig en wijzig:
# server.properties
online-mode=false
# spigot.yml
settings:
bungeecord: true
Bij Paper stel je bovendien de getoonde proxies.bungee-cord.online-mode-waarde in. Start eerst de backends opnieuw en daarna BungeeCord. Een gedeeltelijke reload is voor deze identiteitswijziging niet voldoende.
Stap 3: Backendpad afsluiten
Sta de backend-TCP-poort uitsluitend toe vanuit het geverifieerde proxypad. Afhankelijk van je eigen infrastructuur is dat loopback, een echt privénetwerk/VPN of een strikte firewallregel. In containeromgevingen is een interne IP alleen niet voldoende: een vreemde instantie op dezelfde bridge mag niet doorgaan als proxy.
Bij game-serverhosting koppelt de actieve guard ondersteunde BungeeCord-backends aan de concrete proxy-instantie en herleidt telkens opnieuw de actuele containerbron. Stop, ontbrekende of dubbelzinnige bronnen blijven drop-only. Same-node-, cross-node- en external-backend-paden zijn getest met een echte proxyjoin; onafhankelijke directe toegang bleef geblokkeerd. Dit is een uitspraak over deze bewezen paden, geen garantie voor willekeurige externe providernetwerken.
De volledige setupgids plaatst deze netwerkvarianten in perspectief.
BungeeGuard correct in perspectief plaatsen
BungeeGuard vult het legacy-formaat aan met een gedeelde token. Gebruik minstens versie 1.4.0. De beveiligingspagina van het project documenteert voor oudere BungeeCord-opstellingen een token-lek; na een upgrade moet een mogelijk getroffen token op proxy en backends geroteerd worden.
- genereer de token lokaal met voldoende entropie;
- kopieer hem nooit in tickets, logs, screenshots of Git;
- update proxy en alle backends gecoördineerd;
- verwijder de oude token pas na een succesvolle test;
- behandel de status bij een onbekende/oude versie als unverified.
BungeeGuard is vooral nuttig bij shared hosting, maar vervangt een beschikbare firewall-/privénetwerkoplossing niet als eerste beschermingslaag.
Verificatie: vier afzonderlijke signalen
- Proces: proxy en backend zijn volledig opgestart.
- TCP: de proxy bereikt de backendlistener.
- Lobby-join: een echte, geauthenticeerde speler komt via de proxy in het backend terecht.
- Identiteit: het backend ziet de verwachte online-UUID en client-IP, niet de offline-UUID of alleen de proxy-IP.
Daarna volgt de negatieve test: een onafhankelijke bron mag de backendpoort niet kunnen bereiken. Een open listener of een succesvolle ping alleen is geen bewijs van een join.
Typische fouten
| Symptoom | Oorzaak | Volgende stap |
|---|---|---|
| alle spelers hebben de proxy-IP | ip_forward of bungeecord staat uit |
controleer beide kanten, start volledig opnieuw op |
| speler heeft een nieuwe inventaris | UUID-modus is veranderd | backup bewaren, UUID's vergelijken, plugin-specifiek migreren |
If you wish to use IP forwarding... |
backend verwacht forwarding, proxy stuurt het niet | proxywaarde en exact gestarte config controleren |
| directe join onder andere naam mogelijk | backend is publiek bereikbaar | firewall/privénetwerk direct corrigeren |
| proxy bereikt het backend ook niet | freigave heeft verkeerde/verlopen bron | concrete proxytoewijzing opnieuw beoordelen, niet breed openen |
| geen join na BungeeGuard-update | token inconsistent | versies controleren, gecoördineerd roteren |
Bij een ontbrekend startdoel helpt de fallback-foutgids. Domeinen blijven naar de proxy wijzen; gebruik daarvoor de domein-/SRV-gids.
Plugins en crossplay
Permission-, ban- en economy-plugins zijn extra gevoelig voor UUID-wijzigingen. Maak een backup van hun data en controleer of een proxy- en backendcomponent nodig is. De plugingids legt de platformscheiding uit.
Geyser wordt in een proxynetwerk alleen op de proxy geïnstalleerd. Bedrock-UDP en Java-TCP blijven gescheiden paden; key.pem is geheim. Stel Geyser/Floodgate pas in wanneer het Java-forwarding- en negatieve pad groen zijn.
FAQ
Is ip_forward: true een bescherming?
Nee. Het zorgt er alleen voor dat IP, UUID en profiel naar het backend worden doorgegeven. Het klassieke formaat heeft geen proxy-specifiek signatuurgeheim: wie een onbeveiligd offline-mode-backend direct kan bereiken, kan deze gegevens vervalsen. De bescherming ligt bij de netwerkgrens, niet bij de instelling.
Waarom staat op het backend online-mode=false?
Omdat de authenticatie tegen Mojang al op de proxy plaatsvindt — anders zou het backend deze nog een tweede keer vereisen en elke speler afwijzen. Bij Paper blijft proxies.bungee-cord.online-mode toch true: deze waarde weerspiegelt de online-mode van de proxy, niet die van het backend.
Waarom hebben spelers na de omschakeling een lege inventaris?
Omdat de UUID is veranderd. Zonder forwarding genereert een offline-mode-backend de UUID op basis van de spelernaam, met forwarding komt de echte online-UUID aan. De oude data zijn niet verloren, ze staan onder de oude UUID — daarom moet je vóór de wijziging altijd een getest backup maken.
Heb ik BungeeGuard nodig?
Het vult het legacy-formaat aan met een gedeelde token en is vooral nuttig bij shared hosting, waar je zelf geen firewallregel kunt instellen. Gebruik minstens versie 1.4.0 en roteer de token na een upgrade. Een beschikbare firewall- of privénetwerkoplossing vervangt het niet.
Waar hoort Geyser in een proxynetwerk?
Uitsluitend op de proxy, niet ook nog op de backends. Bedrock draait via UDP, Java via TCP — beide paden worden apart getest, en key.pem is geheim. Stel crossplay pas in wanneer forwarding en de negatieve test op de Java-kant groen zijn.