Sieć Velocity SMP: lobby, survival, creative i minigames za jednym proxy

Kiedy serwer wyrasta z jednego świata, naturalnie pojawia się pomysł sieci: lobby z portalami, główny survival, kreatyw dla budowniczych i blok minigier. Velocity zszywa to wszystko w jeden punkt wejścia typu play.example.net:25565. Poniżej praktyczny przewodnik jak postawić taką sieć od zera, co wpisać w velocity.toml, jak zsynchronizować uprawnienia i czat, i jakie błędy na backendach otwierają drzwi do podszywania się pod UUID.

Po co w ogóle proxy i dlaczego akurat Velocity

Proxy potrzebne jest, gdy serwerów jest więcej niż jeden i gracze mają się między nimi przełączać bez łączenia z nowym IP. BungeeCord i Waterfall sobie z tym radzą, ale oba działają na starym modelu Netty i niosą lata legacy kodu. PaperMC napisał Velocity od zera na Java 21, z asynchroniczną obsługą pakietów i czystym systemem pluginów. W praktyce jedna instancja Velocity spokojnie obsługuje 1000+ równoczesnych połączeń przy 1 GB RAM i nie wpada w GC tak, jak Bungee przy tych samych liczbach.

Praktyczne zalety:

• modern forwarding: podpisane przekazywanie UUID i IP do backendów, zabezpieczone sekretem
• blokada bezpośrednich połączeń: backendy odrzucają wszystko, co nie pochodzi z proxy
• natywnie Java 21, bez sztuczek z preview flagami
• szybkie wsparcie nowych wersji Minecrafta bez czekania na maintainerów Bungee

Wybierając między Velocity a BungeeCord w 2026 odpowiedź jest oczywista. Bungee ma sens tylko w niszowych przypadkach, gdzie krytyczny plugin nie został jeszcze przeportowany do Velocity API.

Architektura sieci

Typowy układ sieci SMP wygląda tak:

                  ┌──────────────┐
   Gracze ───────▶│ Velocity     │ :25565 (publicznie)
                  │ proxy        │
                  └──────┬───────┘
                         │ modern forwarding
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
   ┌─────────┐    ┌──────────┐    ┌──────────┐
   │ lobby   │    │ survival │    │ creative │   ┌──────────┐
   │ :25566  │    │ :25567   │    │ :25568   │   │minigames │
   └─────────┘    └──────────┘    └──────────┘   │ :25569   │
                                                  └──────────┘

Wszystkie backendy słuchają tylko na lokalnym interfejsie albo siedzą za firewallem zamykającym świat zewnętrzny. Gracze widzą wyłącznie play.example.net:25565, wewnętrzna topologia to nie ich sprawa.

Pamięciowo: samo Velocity zajmuje 512 MB do 1 GB RAM, reszta to backendy. Lobby zwykle radzi sobie z 2 GB, survival i creative chcą od 4 GB w górę zależnie od online, blok minigier wpada w 2-4 GB.

Instalacja Velocity

Pobierz najnowszy build Velocity 3.x z paper.io. Osobny user, osobny katalog, wrzuć jar:

sudo useradd -m -s /bin/bash velocity
sudo -u velocity mkdir /home/velocity/proxy
cd /home/velocity/proxy
sudo -u velocity wget https://api.papermc.io/v2/projects/velocity/versions/3.4.0/builds/.../downloads/velocity-3.4.0.jar

Unit systemd do autostartu:

[Unit]
Description=Velocity Proxy
After=network.target

[Service]
Type=simple
User=velocity
WorkingDirectory=/home/velocity/proxy
ExecStart=/usr/bin/java -Xms1G -Xmx1G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -jar velocity-3.4.0.jar
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Pierwsze uruchomienie tworzy velocity.toml, forwarding.secret i katalog plugins/. Główny plik, który będziemy edytować, to velocity.toml.

Konfiguracja velocity.toml

Minimalna działająca konfiguracja dla naszej sieci:

config-version = "2.7"
bind = "0.0.0.0:25565"
motd = "<bold><green>Example Network</green></bold>\n<gray>SMP - Creative - Minigames</gray>"
show-max-players = 500
online-mode = true
force-key-authentication = true
prevent-client-proxy-connections = true
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"
announce-forge = false

[servers]
lobby = "127.0.0.1:25566"
survival = "127.0.0.1:25567"
creative = "127.0.0.1:25568"
minigames = "127.0.0.1:25569"
try = ["lobby", "survival"]

[forced-hosts]
"smp.example.net" = ["survival"]
"build.example.net" = ["creative"]
"play.example.net" = ["lobby"]

[advanced]
compression-threshold = 256
compression-level = -1
login-ratelimit = 3000
connection-timeout = 5000
read-timeout = 30000
haproxy-protocol = false
tcp-fast-open = false

Co tu istotne:

• online-mode = true na proxy: weryfikacja licencji Mojang dzieje się tutaj i tylko tutaj
• player-info-forwarding-mode = "modern": podpisane przekazywanie UUID/IP
• try = ["lobby", "survival"]: jeśli lobby padnie, gracze trafiają na survival zamiast wylatywać
• forced-hosts: przydatna sztuczka, gdy kilka subdomen wskazuje na port 25565

Plik forwarding.secret tworzy się automatycznie. Jego zawartość kopiujemy do każdego backendu.

Przygotowanie backendów: konfiguracja Paper

Każdy serwer Paper za proxy konfiguruje się tak samo ideowo. Weźmy survival jako przykład. Otwieramy paper-global.yml:

proxies:
  bungee-cord:
    online-mode: false
  proxy-protocol: false
  velocity:
    enabled: true
    online-mode: true
    secret: 'TU_WKLEJ_ZAWARTOŚĆ_FORWARDING_SECRET'

Następnie server.properties:

server-port=25567
online-mode=false
prevent-proxy-connections=false
server-ip=127.0.0.1
network-compression-threshold=-1

Kluczowe punkty:

1. online-mode=false w server.properties jest obowiązkowe. Inaczej Paper sam próbuje walidować sesję i psuje modern forwarding.
2. online-mode: true w paper-global.yml w sekcji velocity to miejsce, gdzie dzieje się rzeczywista weryfikacja UUID przekazanego przez Velocity.
3. server-ip=127.0.0.1 sprawia, że serwer słucha tylko na loopback. Nikt z zewnątrz nie podłączy się bezpośrednio, nawet jeśli odkryje port.

Powtarzamy to samo dla lobby (port 25566), creative (25568), minigames (25569). Każdy ze swoim forwarding.secret skopiowanym z proxy, każdy na unikalnym porcie.

Bezpieczeństwo: główna pułapka online-mode

Najczęstsza dziura w sieciach self-hosted to zostawienie online-mode=true na backendzie razem z modern forwarding. Logika idzie tak: jeśli backend jest w trybie online, sam waliduje sesję przez Mojang. Tylko że Velocity już to zrobiło. Paper zwraca więc "nie mogę zweryfikować", admin z desperacji otwiera port na świat albo ustawia prevent-proxy-connections=false bez zrozumienia konsekwencji.

Twarda zasada:

• Proxy: online-mode = true
• Backend server.properties: zawsze online-mode=false
• Backend paper-global.yml: velocity.online-mode: true plus prawidłowy sekret

Pozostawienie backendu w trybie online bez walidacji proxy pozwala dowolnemu klientowi z podrobionym UUID zalogować się pod cudzym nickiem, bo Mojang nigdy nie sprawdzał tej sesji u was. Klasyczny błąd, na którym oparta jest większość incydentów z kradzieżą kont z uprawnieniami operatora.

Dodatkowo firewall przed wszystkim. Jeśli wszystko jest na jednej maszynie, 127.0.0.1 załatwia większość. Jeśli backendy na innych VPS, iptables lub ufw puszcza tylko IP proxy:

sudo ufw default deny incoming
sudo ufw allow from <PROXY_IP> to any port 25567 proto tcp
sudo ufw allow ssh
sudo ufw enable

Synchronizacja między serwerami

Prawdziwa sieć to nie tylko routing połączeń. Gracze potrzebują wspólnych uprawnień, wspólnego czatu, czasem wspólnego salda. Bez synchronizacji każdy backend jest wyspą z własnymi rangami i logami.

Wspólne uprawnienia przez LuckPerms

LuckPerms instaluje się na każdy backend i na samo Velocity (osobny jar dla proxy). Storage przełączamy z file na MySQL/MariaDB:

storage-method: mysql
data:
  address: 127.0.0.1:3306
  database: luckperms
  username: lp_user
  password: 'strong-password'
messaging-service: sql

Gdy LuckPerms na wszystkich serwerach patrzy w jedną bazę i nasłuchuje na kanał messaging, każda zmiana grupy lub uprawnienia stosuje się natychmiast wszędzie. Daję graczowi [VIP] przez /lp user Steve parent set vip i jest VIP w lobby, survival i creative jednocześnie.

Wspólne saldo i ekonomia

Trzy opcje, każda z kruczkami:

• CMI lub EssentialsX z backendem MySQL: najprostsza droga dla większości sieci SMP. Saldo zapisuje do wspólnej bazy, /balance pokazuje wszędzie tę samą kwotę.
• Most Vault przez proxy: bardziej złożone, wymaga pluginów pomocniczych typu RedisEconomy. Pasuje do sieci z dużą liczbą online, gdzie MySQL siada.
• Izolowane ekonomie na każdym serwerze: legalny wybór, gdy creative jest świadomie odcięty od survival po stronie biznesowej.

W większości przypadków wystarczy EssentialsX z economy-storage: mysql w odpowiednim pluginie pomostowym.

Czat między serwerami

Żeby wiadomość z survivala dotarła do lobby, potrzebny jest plugin agregujący. Działające opcje:

• VentureChat z komponentem Velocity: bogata logika kanałów, global i local
• CarbonChat: nowoczesna alternatywa z dokładną kontrolą kanałów
• GlobalTabList: synchronizuje tylko listę graczy w Tabie, bez czatu

Dla naszej sieci instalujemy VentureChat na proxy i każdym backendzie, ustawiamy kanał global synchronizowany wszędzie i local widoczny tylko na własnym serwerze. Wynik: wspólny czat do rozmów, lokalny do tego, co dzieje się bezpośrednio na serwerze.

Przełączanie między serwerami dla gracza

Velocity domyślnie udostępnia komendę /server <name> dostępną z uprawnieniem velocity.command.server. Dla ładniejszego UX dodajemy portale i NPC.

W lobby zwykle stoi kilka NPC z Citizens lub FancyNpcs, każdy spięty z velocity send self <server> przez VelocityPortals lub PortalsPlus. Gracz podchodzi do NPC wyboru trybu, klika i ląduje na właściwym backendzie.

Alternatywa to fizyczne portale z obsydianu spięte z komendą. Multiverse-Portals w lobby umie wywołać komendy cross-server, jeśli dostanie plugin pomostowy.

Minimalna wersja bez portali: gracz wpisuje /server survival i tyle. Tanio i działa.

Whitelist i odcinanie publiczności

Dla sieci prywatnej whitelist musi siedzieć w dwóch miejscach:

1. Na Velocity przez plugin VelocityWhitelist lub NetworkManager. Pierwsza bariera.
2. Na każdym backendzie: /whitelist add <nick> w server.properties albo plugin sync mirroringujący whitelist przez MySQL.

Dublowanie brzmi jak nadmiar, ale chroni przed sytuacją, w której proxy zrestartowało się bez pluginu whitelist, a backendy są dostępne z innej maszyny z zaufanej sieci.

Wydajność i hosting

Podział sprzętu zależy od liczby graczy:

• do 50 graczy: jeden dedykowany serwer z 16 GB RAM. Velocity, lobby, survival, creative, minigames wszystkie na jednej maszynie, rozdzielone portami.
• 50-200 graczy: VPS pod proxy (4 GB), osobny VPS pod survival (8 GB), zbiorczy VPS pod lobby + creative + minigames (8 GB).
• 200+ graczy: każdy backend na własnej maszynie, proxy w osobnym datacenter z dobrą siecią, prywatna sieć między nimi od dostawcy.

Velocity samo w sobie nie obciąża CPU, dla niego liczy się sieć i niskie opóźnienia. Jeśli proxy i backendy są na różnych hostach, dodatkowe 2-3 ms na hop są dla graczy odczuwalnym lagiem. W miarę możliwości trzymaj je w jednej strefie dostępności.

Dla ochrony przed DDoS proxy może stać za filtrem ruchu typu MineGuard. Ataki uderzają w publiczne IP proxy, backendy zostają w spokoju w sieci prywatnej. Więcej tu: ochrona sieci Velocity przed DDoS.

FAQ

Velocity vs BungeeCord vs Waterfall, co wybrać?

W 2026 jednoznacznie Velocity. BungeeCord jest architektonicznie przestarzały, Waterfall (fork Bungee od PaperMC) był rozwiązaniem przejściowym i obecnie w trybie maintenance. Velocity jest aktywnie rozwijane, ma nowoczesne API i natywnie obsługuje nowe wersje Minecrafta bez opóźnień adaptacyjnych.

Czy Velocity i serwer mogą działać na jednej maszynie?

Tak, i często jest to najlepsza opcja dla małych sieci. Velocity słucha na 25565 publicznego IP, backendy na 127.0.0.1 z różnymi portami. Nikt z zewnątrz ich nie widzi, opóźnienie między proxy a backendem jest w mikrosekundach. Ważne tylko zapewnić dość RAM z zapasem na szczyt online.

Jak chronić backend przed bezpośrednim połączeniem?

Trzy warstwy. Pierwsza: backendy słuchają tylko na loopback (server-ip=127.0.0.1), jeśli są na tej samej maszynie co proxy. Druga: firewall puszcza do portów backendów tylko IP proxy. Trzecia: poprawnie skonfigurowane modern forwarding w paper-global.yml z unikalnym sekretem, który Paper sprawdza przy każdym połączeniu.

Jak zrobić wspólny czat między serwerami?

Zainstalować VentureChat lub CarbonChat na proxy i wszystkich backendach, ustawić wspólny kanał. Wiadomości z czatu na survival będą widoczne w lobby i na odwrót. Czat lokalny zostaje obok, żeby rozmowy w obrębie jednego serwera nie zlewały się z globalem.

Co zrobić, gdy gracz dostaje kicka "If you wish to use IP forwarding, please enable it in your BungeeCord config"?

Ten błąd zwraca backend, który nie rozumie, co wysyła proxy. Sprawdź paper-global.yml: powinno być velocity.enabled: true, prawidłowy sekret, a server.properties koniecznie z online-mode=false. Po zmianach restart backendu.

Czy potrzebuję osobnego VPS pod proxy?

Niekoniecznie. Dla sieci do 50 online normalne jest trzymać wszystko na jednej maszynie. Dla większych sieci osobny serwer pod proxy jest wygodny, bo łatwiej go bronić przed DDoS i hostować w regionie z dobrym stosem sieciowym, bez taszczenia ze sobą ciężkich serwerów gry.

Czy Velocity radzi sobie z modpackami Forge lub Fabric?

Tak, przez announce-forge i pluginy pomostowe. Serwery Forge za Velocity działają, ale wymagają nieco staranniejszej konfiguracji i zgodnych wersji klienta. Dla sieci mieszanych (vanilla + modded) prościej trzymać serwery modded w osobnej gałęzi sieci z przełączaniem przez /server.

Co dalej

Gdy sieć stoi, dodawaj rzeczy po kolei. Najpierw upewnij się, że lobby + survival są spięte i przełączanie działa. Potem podpinaj creative i minigames. LuckPerms, czat i ekonomię konfiguruj po podstawowym routingu, inaczej utopisz się w debugowaniu tego, co gdzie się odpięło.

Trzymaj backup velocity.toml, forwarding.secret i paper-global.yml ze wszystkich backendów w jednym miejscu, przy migracji na nowy sprzęt zaoszczędzi to godziny. I nie zapomnij o monitoringu: tps na każdym backendzie plus ping między proxy a serwerami powinny być widoczne na jednym dashboardzie.