Velocity vs BungeeCord: czemu pora przejść

BungeeCord pojawił się w 2012 roku i przez wiele lat był jedynym realnym wyborem dla tych, komu potrzebne było proxy w Minecrafcie. Robił swoją robotę. Ale teraz jest 2026 rok i sytuacja zmieniła się zasadniczo.

Velocity, stworzony przez Andrew Steinborna w 2018 roku i który przeszedł pod skrzydła PaperMC, stał się de facto standardem dla nowych sieci. Waterfall (fork BungeeCord od Paper) jest oficjalnie porzucony. Sam BungeeCord jest na minimalnym utrzymaniu przez md_5.

W tym artykule rozbiorę wszystkie kluczowe różnice, pokażę liczby i wyjaśnię, jak zmigrować. Bez lania wody, konkretnie.

Wydajność: liczby mówią same za siebie

Zacznijmy od tego, co wszystkich interesuje - szybkości. PaperMC deklaruje, że Velocity jest do 8 razy szybszy niż BungeeCord w określonych scenariuszach. Brzmi jak marketing? Rozbierzmy, skąd biorą się te liczby.

Kompresja: libdeflate vs zlib

BungeeCord używa standardowego zaimplementowanego w Javie zlib do kompresji pakietów. Velocity używa libdeflate - natywnej biblioteki, która zapewnia około dwukrotne przyspieszenie kompresji i dekompresji. Na sieci z 500+ graczami to odczuwalna różnica w obciążeniu CPU.

Brak Entity ID Rewriting

To chyba najważniejsza różnica architektoniczna. BungeeCord przechwytuje każdy pakiet i przepisuje Entity ID, żeby uniknąć konfliktów między serwerami. To droga operacja, która dzieje się na każdy pakiet z entity.

Velocity porzucił to podejście całkowicie. Zamiast przepisywania ID na proxy, Velocity polega na tym, że serwery backendu same prawidłowo zarządzają Entity ID przy przełączaniu gracza. Rezultat - znacznie mniej CPU overhead na każde połączenie.

TCP Fast Open

Velocity wspiera TCP Fast Open (TFO) z pudełka. Ta technologia pozwala wysyłać dane już w pierwszym pakiecie SYN połączenia TCP, skracając czas nawiązania połączenia o jeden RTT. Dla graczy oznacza to szybsze łączenie się z serwerem.

Asynchroniczna obsługa zdarzeń

BungeeCord obsługuje zdarzenia synchronicznie. Jeśli jeden plugin zawiesi się w handlerze zdarzenia, cały pipeline stoi. Velocity używa modelu asynchronicznego, gdzie zdarzenia są obsługiwane bez blokowania głównego wątku. Jeden źle napisany plugin nie powali całego proxy.

Natywny transport

Velocity wspiera natywny transport Epoll na Linuksie zamiast standardowego Java NIO. To zmniejsza liczbę wywołań systemowych i redukuje latency na poziomie jądra OS. Na obciążonych serwerach z tysiącami połączeń różnica jest szczególnie zauważalna.

BungeeCord używa standardowego transportu Netty NIO na wszystkich platformach. Technicznie też może pracować z Epoll, ale Velocity robi to z pudełka, bez dodatkowych ustawień.

Co to oznacza w praktyce

Na małej sieci z 50 graczami różnica może być niezauważalna. Ale jeśli masz 200+ graczy, zwłaszcza z customowymi pluginami, przejście na Velocity da odczuwalny przyrost. Mniej spadków TPS przy przełączaniu między serwerami, szybsze łączenie, stabilniejsza praca pod obciążeniem.

Osobno warto zaznaczyć zużycie pamięci. Velocity jest ogólnie lżejszy od BungeeCord przy tej samej liczbie połączeń. Dzięki rezygnacji z Entity ID Rewriting i bardziej zoptymalizowanej pracy z buforami pakietów, na każde połączenie wydawane jest mniej RAM. Dla serwerów, gdzie każdy megabajt się liczy, to istotne.

Bezpieczeństwo: główny powód do migracji

Jeśli wydajność to miły bonus, to bezpieczeństwo jest głównym powodem, dla którego musisz odejść z BungeeCord. Już teraz.

IPForward: dziura wielkości drzwi

BungeeCord używa mechanizmu IPForward do przekazywania informacji o graczu do serwerów backendu. Jak to działa? Proxy dodaje adres IP i UUID gracza do pakietu handshake w postaci zwykłego tekstu. Serwer backendu z włączonym bungeecord: true ślepo ufa tym danym.

Problem jest oczywisty: jeśli ktoś połączy się z serwerem backendu bezpośrednio (omijając proxy), może podstawić dowolne UUID w handshake. To oznacza pełny dostęp do cudzego konta, wraz z ekwipunkiem, uprawnieniami, saldem.

BungeeHack i UUID Spoofing

BungeeHack to całe rodzina exploitów, wykorzystujących właśnie tę podatność. Atakujący łączy się bezpośrednio z serwerem backendu i podmienia UUID w pakiecie handshake. Rezultat - wchodzi pod cudzym kontem.

UUID Spoofing działa analogicznie. Ponieważ BungeeCord przekazuje UUID w plain text bez jakiejkolwiek weryfikacji, podrabianie jest trywialne. Nawet firewall nie zawsze ratuje, jeśli atakujący ma dostęp do wewnętrznej sieci.

Velocity Modern Forwarding: HMAC-SHA256

Velocity rozwiązuje ten problem zasadniczo. Modern Forwarding używa HMAC-SHA256 do podpisywania danych przekazywanych od proxy do serwera backendu. Proxy i serwer backendu dzielą sekretny klucz, a każdy handshake jest podpisywany tym kluczem.

Jeśli ktoś spróbuje połączyć się z serwerem backendu bezpośrednio lub podmienić dane w handshake, podpis się nie zgodzi i połączenie zostanie odrzucone. Żadnego UUID Spoofingu, żadnego BungeeHack. Ochrona kryptograficzna zamiast "ufaj i nie sprawdzaj".

Konkretny scenariusz ataku

Wyobraź sobie: masz sieć z BungeeCord i trzech serwerów Paper. Backendy nasłuchują na 25566, 25567, 25568. Zapomniałeś zamknąć firewallem port 25567 (serwer survival). Atakujący dowiaduje się IP twojego serwera, łączy się bezpośrednio na port 25567 z podstawionym UUID administratora. Dostaje pełny dostęp do uprawnień op, WorldEdit, pluginu bankowego.

Z Velocity Modern Forwarding ten scenariusz jest niemożliwy. Nawet jeśli port jest otwarty, serwer backendu odrzuci połączenie bez ważnego podpisu HMAC. To zasadniczo inny poziom ochrony.

BungeeGuard to proteza

Tak, istnieje BungeeGuard i podobne pluginy, które dodają weryfikację tokenową na wierzchu BungeeCord. Ale to proteza. Nakładasz plaster na problem architektoniczny, zamiast używać rozwiązania, gdzie bezpieczeństwo jest wbudowane w podstawę. Poza tym BungeeGuard trzeba konfigurować osobno na każdym serwerze backendu i nie zapominać o aktualizacji tokenów. W Velocity to po prostu działa.

Waterfall jest martwy, BungeeCord na aparacie tlenowym

Jeśli jeszcze myślisz "no, poczekam", oto fakty.

Waterfall: oficjalnie EOL

Waterfall to fork BungeeCord od zespołu PaperMC, który dodawał patche wydajności i poprawki błędów. W 2024 roku PaperMC oficjalnie ogłosiło Waterfall End of Life. Żadnych aktualizacji, żadnych patchy bezpieczeństwa. Zespół Paper wprost rekomenduje przejście na Velocity.

BungeeCord: minimalne utrzymanie

md_5 kontynuuje wsparcie BungeeCord, ale jest to właśnie minimalne utrzymanie. Dużych aktualizacji nie było od dawna. Wsparcie nowych wersji Minecrafta jest dodawane, ale bez poważnych ulepszeń w architekturze czy bezpieczeństwie. Projekt żyje z rozpędu.

Co to oznacza dla ciebie

Jeśli używasz Waterfall, już nie masz wyboru - projekt jest martwy. Jeśli jesteś na BungeeCord, pytanie nie brzmi "jeśli", tylko "kiedy" napotkasz problem, na który nie będzie patcha. Lepiej zmigrować na własnych warunkach, niż być zmuszonym.

Ekosystem pluginów

Jeden z głównych argumentów przeciwko migracji to "a pluginy?". Rozbierzmy.

Niekompatybilność API

To fakt: pluginy BungeeCord nie działają na Velocity. Mają różne API. Jeśli masz customowy plugin dla BungeeCord, trzeba będzie go przepisać. To chyba najbardziej bolesna część migracji.

Ale są niuanse. Wiele popularnych pluginów od dawna ma wersje dla obu platform. LuckPerms, TAB, LimboAuth, MiniMOTD, Geyser - wszystkie wspierają Velocity.

Hangar: 311+ pluginów

Na Hangar (platforma pluginów od PaperMC) dostępnych jest ponad 311 pluginów dla Velocity. I ta liczba rośnie. Nowe pluginy często wychodzą najpierw dla Velocity, a potem (jeśli w ogóle) dla BungeeCord. Trend jest oczywisty.

Duże sieci już przeszły

Minehut, jedna z największych platform hostingowych Minecrafta, używa Velocity. Większość współczesnych hostingów rekomenduje Velocity domyślnie. To nie eksperymentalna technologia, to standard produkcyjny.

Poradnik migracji

Dobrze, zdecydowałeś się zmigrować. Oto instrukcja krok po kroku.

Krok 1: Instalacja Velocity

Pobierz najnowszą wersję Velocity z PaperMC Downloads. Stwórz osobny katalog i uruchom:

java -Xms512M -Xmx512M -jar velocity.jar

Velocity wygeneruje pliki konfiguracyjne. Zatrzymaj serwer.

Krok 2: Konfiguracja velocity.toml

Otwórz velocity.toml i skonfiguruj główne parametry:

bind = "0.0.0.0:25565"

[servers]
lobby = "127.0.0.1:30001"
survival = "127.0.0.1:30002"
minigames = "127.0.0.1:30003"

try = ["lobby"]

[forced-hosts]
"lobby.example.com" = ["lobby"]
"survival.example.com" = ["survival"]

[advanced]
tcp-fast-open = true

Krok 3: Włączenie Modern Forwarding

W velocity.toml ustaw:

player-info-forwarding-mode = "modern"

Velocity stworzy plik forwarding.secret z sekretnym kluczem. Skopiuj zawartość tego pliku.

Krok 4: Konfiguracja serwerów backendu

Na każdym serwerze Paper najpierw wyłącz BungeeCord forwarding w spigot.yml:

settings:
  bungeecord: false

Następnie włącz Velocity w config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: false
    secret: "WKLEJ_SEKRET_Z_forwarding.secret"

Krok 5: Zamiana pluginów

Zrób listę wszystkich pluginów BungeeCord i znajdź ich analogi Velocity:

Plugin BungeeCord	Analog Velocity
BungeeTabListPlus	TAB (Velocity)
BungeeCord AuthMe	LimboAuth
ServerListPlus	MiniMOTD
BungeeGuard	Niepotrzebny (Modern Forwarding)
Geyser-BungeeCord	Geyser-Velocity

Krok 6: Firewall

Upewnij się, że porty serwerów backendu są zamknięte od zewnątrz. Mimo Modern Forwarding, bezpośredni dostęp do backendów musi być zamknięty:

# Zezwalamy tylko na lokalny dostęp do serwerów backendu
iptables -A INPUT -p tcp --dport 30001:30010 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 30001:30010 -j DROP

Krok 7: Testowanie

Uruchom wszystko i sprawdź:

• Łączenie przez proxy działa
• Przełączanie między serwerami działa
• UUID graczy jest poprawne (sprawdź przez /velocity dump)
• Pluginy działają

Częste błędy przy migracji

Skoro już mówimy o migracji, oto grabie, na które wchodzi się najczęściej.

Zapomnieli wyłączyć bungeecord: true. Po przejściu na Velocity trzeba wystawić bungeecord: false w spigot.yml. Jeśli zostawić true, serwer backendu będzie próbował czytać dane IPForward z handshake'a, a Velocity wysyła dane przez swój kanał Modern Forwarding. Rezultat - popsute adresy IP i UUID.

Skopiowali sekret ze spacjami. Przy kopiowaniu forwarding.secret ludzie czasami łapią spację albo przełamanie linii na końcu. Podpis się nie zgadza i wszystkie połączenia są odrzucane. Sprawdzajcie sekret dwa razy.

Nie zaktualizowali online-mode. W paper-global.yml sekcja velocity wymaga online-mode: false. To nie znaczy, że serwer stanie się piracki. Weryfikacja odbywa się na poziomie proxy, a backend ufa proxy przez HMAC. Ale jeśli zapomnieć tego parametru, nic nie zadziała.

Pluginy z hardcoded BungeeCord API. Niektóre pluginy używają BungeeCord Plugin Messaging Channel do komunikacji między serwerami. Na Velocity potrzebujesz Velocity API lub rozwiązań kross-platformowych typu PluginMessage API przez Velocity.

Kiedy BungeeCord wciąż jest ok

Gwoli sprawiedliwości, są scenariusze, gdzie BungeeCord na razie pozostaje rozsądnym wyborem.

Legacy sieci na 1.8. Jeśli twój serwer działa na 1.8 i z zasady nie aktualizujesz się, ekosystem BungeeCord dla tej wersji jest bogatszy. Velocity jest zorientowany na współczesne wersje.

Głęboka integracja customowych pluginów. Jeśli masz dziesiątki customowych pluginów BungeeCord z tysiącami linii kodu, migracja będzie wymagać znaczących zasobów. Ale nawet w tym przypadku lepiej zacząć planować przejście już teraz.

We wszystkich pozostałych przypadkach Velocity to jednoznaczny wybór.

Tabela porównawcza

Parametr	BungeeCord	Velocity
Wydajność	Bazowa	Do 8x szybciej
Kompresja	Java zlib	libdeflate (2x szybciej)
Entity ID Rewriting	Tak (CPU overhead)	Nie
TCP Fast Open	Nie	Tak
Obsługa zdarzeń	Synchroniczna	Asynchroniczna
Forwarding	Plain text (IPForward)	HMAC-SHA256 (Modern)
Ochrona BungeeHack	Wymaga dodatkowych pluginów	Wbudowana
Status projektu	Utrzymanie	Aktywny development
Waterfall (fork)	EOL	-
Pluginy na Hangar	Ograniczone	311+
Licencja	Customowa	GPLv3
Duże sieci	Przestarzałe	Minehut i inne

Jak to działa z ochroną DDoS

Jeśli twój serwer jest za ochroną DDoS typu MineGuard, przejście na Velocity nie wymaga zmian w ustawieniach filtracji. Proxy-protokół działa tak samo, połączenia TCP są proxowane tak samo. Velocity nawet trochę ułatwia życie dzięki wsparciu PROXY Protocol z pudełka.

Werdykt

BungeeCord wykonał ogromną pracę dla społeczności Minecrafta. Bez niego sieciowe serwery nie byłyby takie, jakie są teraz. Ale technologie nie stoją w miejscu.

Velocity jest szybszy, bezpieczniejszy, aktywniej rozwijany. Waterfall jest martwy, a Paper wprost mówi: używajcie Velocity. Wszystkie duże hostingi rekomendują Velocity. Ekosystem pluginów rośnie.

Jedyny prawdziwy ból przy migracji to przepisanie customowych pluginów. Ale im dłużej czekasz, tym więcej kodu trzeba będzie przepisać. Lepiej zacząć teraz.

Jeśli uruchamiasz nową sieć w 2026 roku i wybierasz BungeeCord - robisz błąd. Jeśli już jesteś na BungeeCord, ułóż plan migracji. Twoi gracze podziękują.