Jak nastavit BungeeCord: jar, config.yml a backendové servery

Nastavení BungeeCordu má čtyři kroky: stáhni BungeeCord.jar z build serveru md_5, jednou ho spusť, aby vytvořil config.yml, nasměruj tento soubor na své backendové servery a na každém backendu změň tři nastavení tak, aby přijímal hráče přes proxy a nikoho jiného. První tři kroky zaberou deset minut. Čtvrtý je ten, kvůli kterému se do sítí vlamuje, protože backend BungeeCordu věří jakékoli identitě, kterou si připojení přisvojí, takže musí být z internetu nedostupný, nebo chráněný pluginem BungeeGuard.

Než začneš, jedna upřímná poznámka. Pro úplně novou síť je lepší proxy Velocity: je rychlejší, spravuje ho PaperMC a jeho moderní forwarding chrání backendy i bez firewallu. Rozdíl vysvětluje článek BungeeCord vs Velocity a návod na síť s Velocity je postup, pokud půjdeš touto cestou. BungeeCord je stále udržovaný, stále hodně používaný a je správnou volbou, když plugin, na kterém závisíš, existuje jen pro něj. Pokud je to tvůj případ, tady je postup, jak to udělat pořádně.

Co BungeeCord dělá a co ne#

BungeeCord je proxy, která mluví protokolem Minecraftu. Hráči se připojují k ní, ona je jednou ověří přes Mojang, pak otevře vlastní spojení na backendový server a přenáší pakety oběma směry. Příkaz /server survival způsobí, že proxy zahodí spojení s lobby a otevře nové na survival, zatímco spojení samotného hráče zůstává otevřené. V tom je celý trik: několik oddělených serverů Minecraftu, jedna adresa, žádné odpojení mezi nimi.

Neobsahuje žádný svět, netickuje entity a nespouští pluginy pro Bukkit. To má tři důsledky, na které lidé přicházejí po špatné zkušenosti:

• Pluginy se nepřenášejí. Pluginy pro Paper a Spigot patří na backendy. Do složky plugins na proxy patří jen pluginy pro BungeeCord - tedy ty vytvořené proti API BungeeCordu.
• Data hráčů jsou pro každý backend zvlášť. Inventáře, homy, zůstatky a ops.json jsou uložené na každém backendu samostatně. Proxy nesdílí nic z toho.
• Nepřekládá verze. Klient a backend, na který se dostane, musí mluvit stejným protokolem. BungeeCord u svých dveří přijímá širokou škálu verzí klientů, ale klient 1.21 stejně nemůže hrát na backendu 1.20, pokud někde v řetězci nestojí ViaVersion.

Také nezrychlí zalágovaný svět. Pokud jeden survival svět zápasí s výkonem, proxy přidá jen další skok a nic dalšího nezmění. Proxy je určená pro několik samostatných serverů pod jedním jménem.

Požadavky a dimenzování#

Proxy je lehká. Procesor spotřebovává na kompresi a šifrování a paměť téměř na nic jiného.

Spouštěj ji na aktuální Javě. Jar býval nenáročný, ale novější buildy sledují moderní Javu, a protože tvoje backendy s Paperem stejně potřebují Javu 21 pro aktuální verze Minecraftu, použij Javu 21 i pro proxy a měj jediný runtime, na který musíš myslet. Která Java patří ke které verzi hry, popisuje článek JVM flagy a verze Javy pro Minecraft.

Peníze jdou do backendů. Síť složená z proxy, lobby a dvou herních módů jsou čtyři procesy, každý s vlastním limitem paměti, a lobby by mělo být z backendů nejmenší, protože simuluje téměř nic.

Stažení oficiálního BungeeCord.jar#

BungeeCord má jediný oficiální zdroj: Jenkins build server md_5 na ci.md-5.net, na který odkazuje web SpigotMC. Soubor se jmenuje BungeeCord.jar a poslední úspěšný build je vždy na stálé cestě:

$ mkdir -p ~/network/proxy && cd ~/network/proxy$ wget -O BungeeCord.jar \    https://ci.md-5.net/job/BungeeCord/lastSuccessfulBuild/artifact/bootstrap/target/BungeeCord.jar

Neexistuje žádný instalátor ani krok s BuildTools - na rozdíl od samotného Spigotu se jar proxy distribuuje připravený ke spuštění. Vyhni se zrcadlům „BungeeCord download“ na náhodných hostingových webech. Některá jsou prostě zastaralá, některá šířila upravené jary. Pokud ti stránka nabízí jar BungeeCordu s číslem verze v názvu souboru, nepochází od md_5.

Waterfall, fork, který v starších návodech uvidíš ještě doporučovaný, se už nevyvíjí. Novou síť na něm nezačínej.

První start a soubory, které vytvoří#

Spusť proxy jednou s malým heapem:

$ java -Xms512M -Xmx512M -jar BungeeCord.jar

Vygeneruje své soubory, naváže se na výchozí port a čeká. Do konzole napiš end, aby se čistě zastavila. Nyní máš:

Dvě výchozí hodnoty ve vygenerovaném souboru zaskočí skoro každého. Listener se váže na port 25577, ne 25565, a ukázkový záznam serveru ukazuje na localhost:25565. Toto uspořádání počítá s tím, že svůj stávající server Minecraftu přesuneš z 25565 pryč a proxy postavíš před něj na jiný port - většina lidí chce pravý opak, takže změň obojí. Výchozí max_players na listeneru je 1, což ovlivňuje jen číslo zobrazené v seznamu serverů, ale funkční síť kvůli tomu vypadá rozbitě.

config.yml, klíč po klíči#

Tohle je kompletní fungující konfigurace proxy se třemi backendy na stejném stroji. Komentáře označují klíče, které musíš změnit.

online_mode: trueip_forward: truenetwork_compression_threshold: 256connection_throttle: 4000connection_throttle_limit: 3player_limit: -1timeout: 30000log_commands: falselog_pings: falseprevent_proxy_connections: falselisteners:- host: 0.0.0.0:25565  motd: '&bThe Longhouse Network'  max_players: 200  tab_list: GLOBAL_PING  tab_size: 60  force_default_server: true  priorities:  - lobby  forced_hosts:    survival.example.com: survival  ping_passthrough: false  query_enabled: false  query_port: 25565  proxy_protocol: false  bind_local_address: trueservers:  lobby:    address: 127.0.0.1:25566    motd: 'Lobby'    restricted: false  survival:    address: 127.0.0.1:25567    motd: 'Survival'    restricted: false  creative:    address: 127.0.0.1:25568    motd: 'Creative'    restricted: false

Blok listeners

listeners je seznam a téměř každá síť má právě jeden záznam.

• host je adresa a port, na který se proxy váže. 0.0.0.0:25565 znamená všechna rozhraní na standardním portu. Na panelovém hostingu se musí shodovat s alokací, kterou jsi dostal.
• motd a max_players jsou to, co ukazuje seznam serverů. Barevné kódy používají &.
• priorities je seřazený seznam serverů, na které se hráč při přihlášení zkouší připojit. Vyhrává první, který ho přijme. Každé jméno tady musí existovat v servers, napsané stejně, jinak hráči dostanou chybu o záložním serveru popsanou v části o řešení problémů.
• force_default_server: true posílá každého hráče při každém přihlášení na první prioritní server. S hodnotou false je modul reconnect v BungeeCordu pošle zpět na server, na kterém naposledy byli, což chceš u sítě zaměřené na survival, ale ne u sítě, která začíná lobby.
• forced_hosts mapuje hostname, který hráč napsal, na server, takže survival.example.com přeskočí lobby. Každý hostname potřebuje DNS záznam směřující na proxy.
• ping_passthrough: true ukazuje v seznamu MOTD a počet hráčů backendu místo těch z proxy. Nech false, pokud k tomu nemáš důvod.
• tab_list je GLOBAL_PING, GLOBAL nebo SERVER. SERVER nechává každý backend řídit vlastní tab list, což očekávají tab pluginy na backendech.
• proxy_protocol: true je jen pro případ, kdy před BungeeCordem stojí něco jako HAProxy nebo TCP load balancer a posílá hlavičky protokolu PROXY. Zapni to bez toho a každé připojení selže.

Globální klíče

• online_mode: true - proxy ověřuje hráče přes Mojang. Nech to zapnuté. Vypnutí vytvoří „cracknutou“ síť, kde se kdokoli může přihlásit jako kdokoli.
• ip_forward: true - předává backendům skutečnou IP, UUID a skin každého hráče. Ve výchozím stavu je vypnuto a bez něj přicházejí všichni hráči na backendy s adresou proxy a UUID z offline módu. Zapni to; párují se s nastavením na backendu v další části.
• network_compression_threshold: 256 - pakety větší než tento počet bajtů se komprimují. Výchozí hodnota je pro provoz k hráčům správná.
• connection_throttle a connection_throttle_limit - kolik přihlášení smí jedna IP udělat v daném okně, v milisekundách. Limit zvyš, pokud se o jednu adresu dělí mnoho hráčů, například škola nebo LAN párty.
• player_limit: -1 - pevný strop pro celou proxy, -1 znamená bez omezení. Liší se od max_players, což je jen zobrazené číslo.
• timeout: 30000 - milisekundy, po kterých se nereagující spojení zahodí.

Blok servers

Každý záznam je jméno, address a příznak restricted. Jméno používá /server <name> a priorities a také pluginy na backendech, když posílají hráče mezi servery, takže vol krátká jména malými písmeny a nikdy je nepřejmenovávej jen tak. restricted: true znamená, že hráč potřebuje k připojení oprávnění bungeecord.server.<name> - užitečné pro build server jen pro staff.

Query a vestavěná oprávnění

query_enabled zapíná protokol GameSpy4 query, který používají některé weby se seznamy serverů a stavoví boti, na UDP portu query_port. Většina sítí ho nechává vypnutý. Pokud ho zapneš, port je UDP a na hostingu s pevnými alokacemi to musí být port, který skutečně máš - proč query porty existují, vysvětluje článek porty herních serverů vysvětleně.

Vygenerovaný soubor obsahuje také blok groups s md_5 jako ukázkovým adminem a blok permissions, který skupině default dává /server a /glist. Tento drobný vestavěný systém funguje, ale o hodnostech nic neví. Odstraň záznam md_5, případně přidej své jméno do admin a počítej s tím, že ho nahradíš pluginem LuckPerms na proxy - návod na LuckPerms ukazuje, jak vymezit oprávnění proxy pomocí kontextu server.

Co změnit na každém backendu#

Každý backend je obyčejný server Spigot nebo Paper. Mění se tři soubory.

server-ip=127.0.0.1server-port=25566online-mode=false

settings:  bungeecord: true

settings:  connection-throttle: -1

Proč každé z nich:

• online-mode=false je povinné. Proxy už hráče ověřila; backend v online módu by to zkusil znovu a proxy odmítne se zprávou Server is online mode!.
• bungeecord: true v spigot.yml způsobí, že backend čte předanou IP a UUID, které posílá ip_forward. Bez toho hráči dostanou UUID z offline módu a o svá data přijdou ve chvíli, kdy to později opravíš.
• connection-throttle: -1 v bukkit.yml zastaví omezování přihlášení na backendu. Každé přihlášení přichází z adresy proxy, takže vlastní throttle backendu by jinak v rušných chvílích vyhazoval legitimní hráče s hláškou „Connection throttled“.

Na Paperu zkontroluj také config/paper-global.yml (nebo paper.yml před verzí 1.19): proxies.bungee-cord.online-mode má být true, což Paperu říká, že identity přicházející přes proxy byly ověřeny. Pluginy, které se zajímají o prémiové účty, to čtou.

Každý backend potřebuje vlastní port a každý backend musí běžet na stejné verzi Minecraftu jako klienti, kteří se k němu dostanou, nebo mít ViaVersion. Po těchto změnách backendy restartuj; spigot.yml se za běhu znovu nenačítá. Další nastavení, která stojí za to na lobby oříznout, například view-distance a spawn-protection, popisuje článek server.properties vysvětleně.

Firewall pro backendy#

Tady je důvod, proč na tom záleží. Backend s online-mode=false a bungeecord: true věří každému handshaku, který tvrdí, že nese předaná data. Kdokoli, kdo se dostane na jeho port, se může připojit s vyrobeným handshakem, že je tvůj operátor, a backend ho pustí dovnitř s UUID, oprávněními a inventářem toho hráče. Veřejné nástroje dělají přesně tohle a skenery otevřené backendy rychle najdou.

Díru lze zavřít třemi způsoby, seřazenými od nejsilnějšího.

1. Navázat na localhost. Když proxy a backendy sdílejí jeden stroj, server-ip=127.0.0.1 na každém backendu je učiní z venku nedostupnými. Je to nejjednodušší a nejlepší možnost a používá ji i ukázková konfigurace výše.
2. Firewall na portech. Když jsou backendy na jiných strojích, povol jejich porty jen z adresy proxy a všem ostatním zakaž. Dělá to příklad s ufw níže.
3. BungeeGuard. Když firewall nasadit nemůžeš - na většině sdílených panelových hostingů je každý server samostatný kontejner s vlastním veřejným portem - nainstaluj BungeeGuard na proxy i na každý backend. Plugin na proxy vygeneruje tajný token a přidá ho k předávaným datům; plugin na backendu drží tento token v seznamu allowed-tokens a odmítá spojení bez něj. Je to stejná myšlenka jako moderní forwarding ve Velocity, jen dodatečně přidělaná.

Pro možnost 2, na backendu, jehož proxy sídlí na 203.0.113.10, záleží na pořadí pravidel - ufw použije první shodu, takže povolení jde před zákaz:

$ sudo ufw allow from 203.0.113.10 to any port 25566 proto tcp$ sudo ufw deny 25566/tcp

Na RE:NODE je každý server, ať proxy nebo backend, samostatný kontejner s vlastní veřejnou alokací, takže možnosti 1 a 2 mezi servery nemáš k dispozici. Zde je správným řešením BungeeGuard na proxy i na každém backendu a test přímého připojení výše je způsob, jak si ověříš, že funguje. Širší seznam toho, co zabezpečit, najdeš v bezpečnostním checklistu pro server Minecraftu.

Spuštění, pluginy a příkazy#

Nejdřív spusť backendy, potom proxy. Pořadí není striktně nutné, ale proxy, která startuje bez jediného běžícího backendu, první hráče vyhodí se zprávou o záložním serveru.

$ java -Xms512M -Xmx512M -XX:+UseG1GC -jar BungeeCord.jar

Pluginy pro proxy patří do plugins/ jako jary a k jejich načtení je nutné proxy restartovat. BungeeCord má příkaz /greload, ale ten pluginy nenačítá znovu a nikdy nebyl spolehlivý pro mnoho víc než seznam serverů - většina adminů proxy raději restartuje, což všechny odpojí, takže změny seskup a restartuj v klidné hodině. Typické pluginy na proxy jsou LuckPerms (build pro BungeeCord), BungeeGuard, ViaVersion, pokud ho chceš na proxy, Geyser a Floodgate pro hráče z Bedrocku (Geyser a crossplay s Bedrockem) a plugin pro síťový chat nebo bany. U každého stahování zkontroluj, že na stránce stojí BungeeCord, ne Spigot - plugin pro Bukkit ve složce proxy se při startu nenačte a vypíše chybu.

Pluginy na backendech, které posílají hráče mezi servery - výběrová menu, cedulky v lobby, návrat do lobby z minihry - komunikují s proxy přes plugin messaging kanál BungeeCord. Na proxy nepotřebují nic instalovat, ale jména serverů v config.yml se musí shodovat s tím, co jsi nastavil v nich.

Jakmile proxy funguje, dej jí hostname pomocí záznamu A a SRV, aby hráči psali mc.example.com bez portu - přesný záznam najdeš v článku SRV záznamy pro Minecraft.

Řešení chyb, které se objeví poprvé#

„If you wish to use IP forwarding, please enable it in your BungeeCord config as well!“ Backend má v spigot.yml bungeecord: true, ale proxy nic nepředává. Nastav ip_forward: true v config.yml proxy a proxy restartuj. Tuhle hlášku uvidíš také, když se někdo připojí na backend přímo a obejde proxy - což ti, pokud to vůbec funguje, říká, že backend je dostupný z venku.

„Could not connect to a default or fallback server, please try again later“, obvykle následované Connection refused. Proxy zkusila všechny servery v priorities a žádný neodpověděl. Zkontroluj postupně: běží backend doopravdy; shoduje se address v servers se server-ip a server-port backendu; je jméno v priorities napsané přesně jako klíč v servers; a pokud je backend na jiném stroji, pouští tvůj firewall proxy dovnitř. Backend navázaný na 127.0.0.1 je pro proxy na jiném stroji nedostupný.

`Server is online mode!` Backend má pořád online-mode=true. Nastav false a restartuj.

Všichni se přihlašují jako noví hráči bez inventáře. UUID přicházejí v offline podobě, takže je ip_forward vypnuté na proxy, nebo bungeecord na backendu. Zastav to a oprav dřív, než bude hrát víc lidí; každé přihlášení vytváří data hráče, která budeš muset uklízet.

`Connection throttled! Please wait before reconnecting.` z backendu v rušných obdobích. Throttle v bukkit.yml na backendu je pořád zapnutý; nastav connection-throttle na -1.

`Address already in use` při startu. Port listeneru drží něco jiného, často backend, který zůstal na 25565, poté co jsi tam přesunul proxy. Přesuň backend nebo změň host.

`Outdated server!` nebo `Outdated client!` Verze klienta a backendu se liší. Drž všechny backendy na verzi klienta nebo přidej ViaVersion. V jakém pořadí síť aktualizovat, popisuje článek aktualizace verzí Minecraftu.

Hráči se mohou připojit, ale seznam serverů ukazuje 1 slot. To je výchozí max_players: 1 na listeneru. Je to jen kosmetika; změň ho na číslo, které chceš zobrazovat.

FAQ#

Kde bezpečně stáhnu BungeeCord.jar?

Z Jenkinsu md_5 na ci.md-5.net, z artefaktu lastSuccessfulBuild úlohy BungeeCord, na který odkazuje web SpigotMC. Distribuuje se jako hotový jar bez kroku s BuildTools. Zrcadla na jiných webech jsou zbytečná a někdy zastaralá nebo upravená.

Mám pro novou síť použít BungeeCord, nebo Velocity?

Velocity, pokud plugin, který potřebuješ, neexistuje jen pro BungeeCord. Moderní forwarding ve Velocity je podepsaný, takže backendy odmítají přímá připojení bez firewallu či BungeeGuardu, a zvládá víc hráčů na jedno jádro. BungeeCord funguje, ale k bezpečnému provozu potřebuje tuto přidanou ochranu.

Potřebují backendy stejné pluginy jako proxy?

Ne, jsou to oddělené světy. Pluginy pro Bukkit, Spigot a Paper patří na backendy; pluginy pro BungeeCord na proxy. Několik z nich, například LuckPerms, Floodgate a BungeeGuard, vydává oba buildy a běží na obou místech, každé s buildem určeným pro ně.

Proč BungeeCord používá výchozí port 25577?

Protože předpokládá, že už máš server Minecraftu na 25565 a proxy stavíš vedle něj. Většina sítí je prohodí: proxy převezme 25565, aby hráči nepotřebovali port, a backendy se přesunou na jiné porty.

Mohou backendy běžet na různých verzích Minecraftu?

Jen pokud se každý klient dokáže domluvit s backendem, na který se dostane. Proxy verze nepřekládá. Buď drž všechny backendy na jedné verzi, nebo nainstaluj ViaVersion, na proxy nebo na každý backend, ale ne na obojí.

Je offline mód na backendech nebezpečný?

Sám o sobě velmi. Bezpečný je jen tehdy, když se k backendům nelze dostat jinak než přes proxy: navázané na 127.0.0.1, zamčené firewallem na adresu proxy nebo chráněné BungeeGuardem. Otestuj to přímým připojením na backend; musí tě odmítnout.