Velocity, BungeeCord i Waterfall — proxy dla sieci serwerów Minecraft

Czym właściwie jest proxy Minecraft?

Proxy to lekki serwer, który nie hostuje świata. Gracz łączy się z proxy, a proxy przepuszcza pakiety do właściwego serwera (lobby, survival, BedWars itd.). Dla gracza wygląda to jak jeden adres, jeden login, jeden tab list.

• Jedno wejście dla graczy — domena typu play.twojserwer.pl kieruje wszystkich do proxy,
• Płynne przełączanie — komendą /server lobby lub portalem bez rozłączania,
• Współdzielona ekonomia, czat, ranking — pluginy proxy spinają osobne instancje w jedną sieć,
• Wspólna lista banów — ban na proxy = ban na wszystkich podserwerach.

Proxy nie jest potrzebne, jeśli masz jeden serwer. Ma sens dopiero, gdy chcesz uruchomić wiele instancji albo planujesz sieć minigier.

BungeeCord — klasyk, którego epoka się kończy

BungeeCord powstał w 2012 r. i przez lata był standardem branżowym. Napisany w Javie, oparty o stary, blokujący model wątków (jeden wątek na połączenie). Wciąż działa, wciąż jest wspierany przez MD_5, ale rozwija się głównie kosmetycznie.

Plusy:

• ogromna baza pluginów (DCC, Premium-Vanish, RedisBungee),
• masa dokumentacji i tutoriali po polsku,
• działa „od zawsze" — wiele firm hostingowych ma gotowe szablony.

Minusy:

• słaba skalowalność powyżej ~500 jednoczesnych graczy,
• jeden wątek na połączenie = przy dużej liczbie graczy CPU puchnie,
• brak natywnego wsparcia dla nowoczesnych protokołów (ip-forwarding modern),
• API jest stare i pisanie pluginów potrafi być uciążliwe.

BungeeCord nadaje się dziś głównie do małych projektów lub do utrzymania starszych sieci, których nikt nie chce migrować.

Waterfall — fork BungeeCord od PaperMC

Waterfall to fork BungeeCord rozwijany przez ten sam zespół, który stoi za Paperem. Idea była prosta: zachować pełną kompatybilność z pluginami BungeeCord, ale poprawić wydajność, naprawić bugi i dodać kilka brakujących opcji.

• kompatybilny w 99% z pluginami BungeeCorda,
• lepsza wydajność (mniejsze opóźnienia, lepsze zarządzanie pakietami),
• dodatkowe ustawienia w waterfall.yml,
• szybsze patche pod nowe wersje protokołu.

Uwaga: w 2023 r. PaperMC ogłosił, że Waterfall przechodzi w tryb maintenance i nowe funkcje trafiają tylko do Velocity. Otrzymasz patche bezpieczeństwa i wsparcie dla nowych wersji Minecrafta, ale nic ponad to. Jeśli zaczynasz nowy projekt, Waterfall raczej nie jest dobrym wyborem.

Velocity — nowoczesna alternatywa

Velocity to proxy napisane od zera przez tych samych ludzi, którzy robią Papera. Powstało, żeby rozwiązać problemy, których nie da się rozwiązać forkując BungeeCord — głównie wydajnościowe.

Kluczowe różnice:

• Asynchroniczny model I/O oparty o Netty — jeden wątek obsługuje setki połączeń,
• Lepsze API — nowoczesny event system, dependency injection, łatwiejsze testy,
• Modern Forwarding — kryptograficznie podpisane informacje o graczu (Velocity ↔ Paper),
• Wbudowana ochrona przed nieautoryzowanymi połączeniami z podserwerami,
• Pluginy w Kotlinie mają natywne wsparcie.

Realny benchmark: w testach społeczności Velocity utrzymuje 2000+ graczy na proxy, przy CPU obciążonym poniżej 30%. BungeeCord na tej samej maszynie pada przy ~600. To gigantyczna różnica.

Minus: pluginy są niekompatybilne z BungeeCordowymi. Przy migracji często trzeba poszukać alternatyw albo zamienników (np. LuckPerms ma osobne moduły dla obu proxy).

Kiedy które proxy wybrać?

W 2026 r. odpowiedź jest dość prosta i niemal zawsze brzmi „Velocity". Wyjątki:

• Velocity — nowe projekty, sieci minigier, projekty rosnące, premium serwery, wszystko powyżej ~200 graczy online,
• Waterfall — starsze projekty z setką pluginów BungeeCord, których nie chce się przepisywać,
• BungeeCord — bardzo małe projekty hobbystyczne, gdzie ważna jest największa zgodność z poradnikami z YouTube'a.

Jeśli zaczynasz dziś od zera — bierz Velocity i nie patrz wstecz.

IP forwarding — niewidoczna, ale kluczowa rzecz

Bez konfiguracji ip-forwardingu wszystkie podserwery widzą połączenia jako pochodzące z IP proxy. Skutki: bany po IP nie działają, geolokalizacja zawodzi, antycheaty głupieją, statystyki graczy są pomieszane.

Trzy tryby:

• Legacy (BungeeCord) — proxy dorzuca dane gracza do handshake'a. Działa wszędzie, ale można podszywać się pod gracza, jeśli ktoś ominie proxy i połączy się bezpośrednio z podserwerem,
• Bungee Guard — wariant z tokenem; lepszy, ale wciąż nieidealny,
• Modern Forwarding (Velocity ↔ Paper) — kryptograficznie podpisane, niepodrabialne. Standard 2026 r.

Konfiguracja na Paperze (paper-global.yml):

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "ZNAK_SEKRETNY_Z_VELOCITY"

Na Velocity (velocity.toml):

player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"

Plik forwarding.secret musi być identyczny na proxy i na każdym podserwerze. Bez tego sekretu gracze dostaną komunikat o nieautoryzowanym połączeniu.

Firewall — najczęstszy błąd początkujących

Klasyczna pomyłka: właściciel stawia proxy + podserwery, otwiera porty wszystkim i dziwi się, że ktoś podszywa się pod admina.

Podserwery nigdy nie powinny być dostępne z internetu. Reguła ognia (UFW na Linuksie):

ufw allow 25565/tcp                # proxy publicznie
ufw allow from 10.0.0.0/8 to any port 25566:25570/tcp  # podserwery tylko z VPN/sieci wewnętrznej
ufw deny 25566:25570/tcp

Jeśli wszystko stoi na jednej maszynie — wystarczy bind: 127.0.0.1 w server.properties każdego podserwera.

Pluginy, bez których proxy nie ma sensu

• LuckPerms — synchronizacja uprawnień między proxy a podserwerami,
• LiteBans / AdvancedBan — wspólny system banów dla całej sieci,
• Velocity Hub / SimpleHub — automatyczne odsyłanie do lobby po wyjściu z minigry,
• ProtocolizeAPI — pakiety na poziomie proxy, GUI, podpowiedzi,
• signedvelocity — kompatybilność z podpisanym czatem 1.19+,
• ViaVersion + ViaBackwards — gracze z różnych wersji łączą się do tej samej sieci.

Wydajność i zasoby

Proxy nie ładuje świata, więc nie potrzebuje dużo RAM-u. Realne wartości:

• BungeeCord do 200 graczy: 1–2 GB RAM, 1–2 vCPU,
• Velocity do 1000 graczy: 2–4 GB RAM, 2 vCPU,
• Velocity do 5000+ graczy: 8 GB RAM, 4 vCPU (i tu BungeeCord się po prostu nie nadaje).

Wąskim gardłem przy dużej skali jest sieć (PPS — packets per second), nie CPU. Warto wybrać hosting z niskim opóźnieniem i nielimitowanym pasmem.

Migracja z BungeeCord na Velocity

Najczęstsze pułapki przy przesiadce:

• Plugin compat — sprawdź każdy plugin, czy ma wersję Velocity. Brakujące zwykle mają zamienniki,
• Konfiguracja — config.yml BungeeCorda nie konwertuje się 1:1 na velocity.toml,
• Modern Forwarding — wymaga aktualizacji Papera na podserwerach do wersji wspierającej,
• Bans — wyeksportuj bany z LiteBans przed migracją; format bazy danych pozostaje ten sam, więc problem dotyczy tylko plików płaskich,
• Permisje — LuckPerms ma osobne moduły dla BungeeCord i Velocity; zainstaluj odpowiedni, ale baza danych jest wspólna.

Realny czas migracji średniej sieci (3–5 podserwerów): 2–4 godziny pracy plus dzień obserwacji. Warto zrobić to w okienku low-traffic.

Podsumowanie

BungeeCord otworzył erę sieci serwerów Minecraft, ale jego czas powoli się kończy. Waterfall jest dobrym mostem dla starych projektów, ale nie ma już rozwijanej linii produktowej. Velocity to dziś domyślny wybór dla każdego nowego projektu — szybszy, bezpieczniejszy, lepiej zaprojektowany i z aktywnym rozwojem.

Niezależnie od wyboru — zadbaj o ip-forwarding w trybie modern, firewall blokujący bezpośredni dostęp do podserwerów i pluginy do wspólnych banów oraz uprawnień. To trzy fundamenty, na których stoi każda sensowna sieć serwerów Minecraft.