Velocity czy BungeeCord: jak zbudować sieć serwerów
Proxy to serwer pośredni, z którym łączą się gracze i który przekierowuje ich na osobne serwery backendowe dla lobby, survivalu, creative i minigier, dzięki czemu skaczą między światami bez wychodzenia z gry. BungeeCord i Velocity robią tę samą robotę: BungeeCord jest starszy i szeroko wspierany, Velocity nowocześniejszy, szybszy i bezpieczniejszy dzięki modern forwarding. Samo proxy potrzebuje niewiele pamięci, zwykle wystarczy 512 MB i w MC-Node kosztuje 2,16 zł miesięcznie, ale każdy serwer backendowy za nim ma własne zapotrzebowanie na RAM.
Co dokładnie robi proxy?
Bez proxy twój klient łączy się bezpośrednio z serwerem Minecraft. Z proxy łączy się z proxy, a ono otwiera za sobą własne połączenie z serwerem backendowym. Gdy zmieniasz serwer, proxy zrywa to tylne połączenie i otwiera nowe do kolejnego. Twoje połączenie cały czas trwa, więc widzisz tylko krótki ekran ładowania, a nie listę serwerów.
Samo proxy nie prowadzi świata: żadnych chunków, mobów ani redstone. Trzyma połączenia, przerzuca pakiety i zarządza listą graczy. Dlatego 512 MB dla proxy prawie zawsze wystarcza, podczas gdy ta sama pamięć na serwerze survival nie daje niczego. Dodatkowa korzyść: proxy to jedyny adres, który znają gracze, czyli też punkt, na którym ustawiasz ochronę przed atakami DDoS.
Czym różnią się BungeeCord i Velocity?
BungeeCord wywodzi się ze świata Spigota i przez lata był standardem; praktycznie każdy stary poradnik dotyczy właśnie jego. Velocity pochodzi od ekipy stojącej za Paper i inaczej podchodzi do dwóch rzeczy: do obsługi połączeń oraz do tego, jak backend sprawdza, że gracz naprawdę wchodzi przez proxy. Waterfall, fork BungeeCord od tej samej ekipy Paper, nie jest już rozwijany i sam odsyła do Velocity.
| Kryterium | BungeeCord | Velocity |
|---|---|---|
| Wiek | Starszy, mnóstwo poradników | Nowszy, aktywnie rozwijany |
| Wydajność przy wielu połączeniach | Działa, ale starsza baza kodu | Zauważalnie oszczędniejszy |
| Przekazywanie danych gracza | Legacy, bez weryfikacji | Modern, ze współdzielonym sekretem |
| Pluginy | Duży wybór, sporo starych buildów | Mniejszy wybór, znane nazwy obecne |
| Tryb bezpieczny na backendzie | Potrzebny dodatkowy plugin (BungeeGuard) | Wbudowany w Paper i Purpur |
Pluginy nie są wymienne: plugin do BungeeCord nie zadziała na Velocity, bo to inne API. Za to rzeczy, które chcesz mieć na proxy, jak LuckPerms i ViaVersion, mają buildy pod Velocity. Jeśli zaczynasz teraz, Velocity jest logicznym wyborem. Jeśli od lat chodzisz na BungeeCord z pluginami bez wersji na Velocity, spokojnie możesz przy nim zostać, o ile masz poukładane zabezpieczenia.
Ile RAM potrzebuje sieć serwerów?
Licz per backend, a nie dla sieci jako całości. Każdy backend to pełnoprawny serwer Minecraft z własnym światem, własnymi pluginami i własnym procesem Java. Cztery serwery to więc cztery razy zarezerwowana pamięć; proxy jest najtańszym ogniwem.
| Element | RAM | Miesięcznie (linia budżetowa) |
|---|---|---|
| Proxy Velocity albo BungeeCord | 512 MB | 2,16 zł |
| Lobby z małą mapą | 2 GB | 9,50 zł |
| Survival | 4 GB | 19,01 zł |
| Creative albo minigry | 2 GB | 9,50 zł |
| Razem | 8,5 GB | 40,17 zł |
Uwaga na pułapkę: 8,5 GB rozdzielone na cztery serwery to nie to samo co jeden serwer z 8,5 GB. Każdy proces Java ma własny narzut i własne wczytane chunki, więc na samym fakcie, że to cztery serwery, tracisz pamięć. Buduj sieć dopiero wtedy, gdy naprawdę potrzebujesz osobnych światów. Jak postawić pojedynczy serwer, opisujemy w poradniku o tworzeniu serwera Minecraft.
Jak postawić proxy Velocity?
Najpierw proxy, potem backendy, potem testy. W panelu takim jak Pterodactyl zakładasz proxy jako osobny pakiet z własnym portem.
- Postaw Velocity na pakiecie 512 MB i uruchom je raz, żeby powstały pliki
velocity.tomliforwarding.secret. - Ustaw w
velocity.tomlwartościonline-mode = trueorazplayer-info-forwarding-mode = "modern". - W sekcji
[servers]wpisz wewnętrzne adresy i porty swoich backendów oraz listętry, która decyduje, gdzie gracze lądują na wejściu — zwykle jest to lobby. - Na każdym backendzie ustaw w
server.propertieswartośćonline-mode=false; uwierzytelnianie robi teraz proxy. - Na każdym backendzie na Paper albo Purpur ustaw w
config/paper-global.ymlw sekcjiproxies.velocityopcjęenabled: truei wklej zawartośćforwarding.secretw polesecret. - Zrestartuj wszystko, połącz się z adresem proxy i skacz komendą
/servermiędzy backendami.
Przy BungeeCord wygląda to inaczej: tam ustawiasz w config.yml opcję ip_forward: true, a na każdym backendzie w spigot.yml opcję bungeecord: true. To połączenie nie ma wbudowanej żadnej weryfikacji i właśnie dlatego potrzebujesz do niego BungeeGuard.
Dlaczego każdy może ot tak wejść na twoje backendy?
W sieci serwerów tylko proxy sprawdza, czy ktoś naprawdę jest tym, za kogo się podaje. Backendy ustawiają dlatego online-mode na false: widzą już wyłącznie ruch, który proxy wcześniej sprawdziło. To jest w porządku, dopóki port backendu nie jest osiągalny również z internetu.
Wtedy bowiem każdy może wpisać ten port na swojej liście serwerów, wybrać dowolną nazwę użytkownika i wejść. Nie ma już żadnej weryfikacji, więc otwarta stoi też nazwa właściciela z uprawnieniami OP. Whitelista nie pomoże: serwer wierzy w nazwę, którą podaje klient, więc atakujący po prostu wpisze nazwę z whitelisty. To zdecydowanie najczęstszy powód, dla którego małe sieci padają ofiarą griefu.
Tak to zamykasz
- Korzystaj z modern forwarding. Velocity podpisuje dane gracza sekretem z pliku
forwarding.secret; backend, który zna ten sekret, odrzuca wszystko, co nie jest poprawnie podpisane. - Na BungeeCord zainstaluj BungeeGuard. Legacy IP forwarding w ciemno ufa temu, co przychodzi. BungeeGuard dokłada współdzielony token i łata tę samą dziurę.
- Ogranicz ruch sieciowy. Niech backendy nasłuchują tylko na adresie wewnętrznym albo przepuść na firewallu wyłącznie adres IP proxy. Jeśli nie wiesz, jak to zrobić w twoim panelu, zapytaj support.
- Przetestuj to sam. Wpisz w kliencie adres i port backendu bezpośrednio. Jeśli wejdziesz, dziura wciąż stoi otworem; jeśli dostaniesz błąd dotyczący forwardingu, jest dobrze.
Ten ostatni test powtórz za każdym razem, gdy dokładasz backend: nowy serwer startuje z ustawieniami domyślnymi, czyli bez forwardingu.
Co zmienia się w twoich pluginach?
Sieć nie współdzieli niczego automatycznie. Każdy backend ma własny folder świata i własne dane graczy, więc kto na survivalu ma pełny ekwipunek, na creative stoi z pustymi rękami, chyba że plugin zapisze te dane we wspólnej bazie. Z rangami jest prościej: LuckPerms pozwala wskazać na wszystkich serwerach tę samą bazę MySQL, dzięki czemu ranga obowiązuje wszędzie. Odpal LuckPerms również na samym proxy, bo komendy proxy mają własne uprawnienia.
Pluginy związane ze światem, takie jak WorldGuard, WorldEdit, CoreProtect i GriefPrevention, zostają na poszczególnych backendach. ViaVersion i ViaBackwards przenoszą się natomiast na proxy, żeby odmienne wersje klienta były wyłapywane już przy drzwiach wejściowych; to samo dotyczy Geyser z Floodgate dla graczy Bedrock. O czacie zapomina się najczęściej: gracze w lobby domyślnie nie widzą nic z czatu na survivalu, a DiscordSRV działa osobno na każdym serwerze. Które pluginy gdzie należą, znajdziesz w zestawieniu przydatnych pluginów do Minecraft.
Kiedy proxy w ogóle nie jest ci potrzebne?
Częściej, niż myślisz. Jeśli chcesz mieć tylko świat creative obok świata survival, załatwisz to w obrębie jednego serwera pluginem do zarządzania światami. Oszczędzasz proxy, dodatkowy pakiet i dodatkową rzecz, która może się zepsuć. Przy małej, stałej grupie graczy lepiej włożyć zaoszczędzone pieniądze w RAM dla serwera głównego.
Modpacki to drugi przypadek. Proxy i modloadery dogadują się średnio, a ciężkie packi drogo się podwaja: All the Mods 10 wymaga minimum 10 GB i 12 GB dla małej grupy, więc każdy dodatkowy backend od razu podwaja to zapotrzebowanie. Rozsądniejszy jest wtedy jeden dobrze dostrojony serwer; o tym właśnie jest artykuł o optymalizacji serwera.
Pamiętaj też, że proxy to punkt centralny: gdy padnie, cała twoja sieć jest nieosiągalna, choćby backendy dalej chodziły. Nie zabieraj się więc za to, zanim nie masz płynnie działającego pojedynczego serwera. Ile kosztują poszczególne elementy, sprawdzisz w ofercie hostingu Minecraft w MC-Node, łącznie z proxy 512 MB za 2,16 zł.
Najczęściej zadawane pytania
Czy mogę uruchomić swoje pluginy z BungeeCord na Velocity? Nie, Velocity ma własne API i nie ładuje pluginów BungeeCord. Znane nazwy mają jednak buildy pod Velocity, w tym LuckPerms, ViaVersion oraz Geyser z Floodgate. Przejrzyj swoją listę przed przesiadką: to właśnie małe, własnoręcznie napisane pluginy często nie mają wersji na Velocity.
Ile RAM potrzebuje samo proxy? Dla większości sieci wystarczy 512 MB, w MC-Node za 2,16 zł miesięcznie, bo proxy nie tickuje świata i nie wczytuje chunków. Jeśli twoja sieć mocno rośnie, wcześniej uderzysz w limity CPU i sieci niż pamięci. RAM powinien iść do backendów.
Czy online-mode musi być ustawione na false na backendach? Tak, bo proxy zweryfikowało już gracza u Mojanga, a druga kontrola na backendzie zakończy się błędem. Ustaw online-mode na true na proxy i na false na backendach oraz zadbaj, żeby te backendy były osiągalne wyłącznie przez proxy, z modern forwarding albo BungeeGuard. Bez tego ostatniego kroku każdy może wejść pod dowolną nazwą.
Czy sieć automatycznie współdzieli ekwipunek i rangi? Nie. Każdy backend prowadzi własne dane świata i graczy, więc ekwipunki i enderchesty są od siebie niezależne. Rangi współdzielisz, wskazując LuckPerms na wszystkich serwerach i na proxy tę samą bazę MySQL; do ekwipunku potrzebujesz osobnego pluginu ze wspólnym magazynem danych.
Czy mogę postawić modpack taki jak All the Mods 10 za proxy? Technicznie czasem się da, ale zwykle nie warto. ATM10 działa na NeoForge z Minecraft 1.21.1 i wymaga minimum 10 GB oraz 12 GB dla małej grupy, więc każdy dodatkowy backend mocno się odbija. Lepszym wyborem jest wtedy jeden porządny serwer.