Poradnik hostingu serwera FiveM: VPS, dedykowany czy zarządzany

Dlaczego wybór hostingu decyduje o sukcesie Twojego serwera

Wybrany dostawca hostingu ma bezpośredni i wymierny wpływ na każdy aspekt twojego serwera FiveM. Wrażenia graczy, wydajność skryptów, synchronizacja entity, jakość czatu głosowego i czasy odpowiedzi bazy danych zależą od sprzętu znajdującego się w centrum danych. Źle dobrany host prowadzi do rubber-bandingu, desynchronizacji podczas pościgów samochodowych, przerywania czatu głosowego w kluczowych momentach roleplayu oraz ekranów ładowania trwających tak długo, że gracze rozłączają się jeszcze przed zespawnowaniem. Różnica między serwerem działającym na odpowiednim sprzęcie a upchniętym na przepełnionym VPS jest natychmiast zauważalna dla każdego doświadczonego gracza FiveM. W tym poradniku szczegółowo omówimy, jakich parametrów potrzebujesz, porównamy VPS z serwerem dedykowanym i pomożemy ci dokonać właściwego wyboru dopasowanego do skali serwera i budżetu.

VPS vs serwer dedykowany: poznaj różnice

A VPS (Virtual Private Server) to zwirtualizowany wycinek większej maszyny fizycznej. Dzielisz bazowy sprzęt z innymi użytkownikami, ale twoje zasoby są izolowane przez hiperwizor. A serwer dedykowany daje ci całą maszynę fizyczną na wyłączność. W przypadku FiveM to rozróżnienie ma większe znaczenie niż przy typowym hostingu stron www, ponieważ FiveM jest niezwykle wrażliwy na wydajność pojedynczego wątku procesora oraz opóźnienia pamięci. Na serwerze VPS uciążliwi sąsiedzi (noisy neighbors) obciążający procesor mogą powodować mikroprzycięcia na twoim serwerze, nawet gdy przydzielone ci zasoby nie są w pełni wykorzystane. Serwery dedykowane całkowicie eliminują to ryzyko. Jednak wysokiej jakości VPS od dostawcy, który nie stosuje oversellingu, może działać porównywalnie w przypadku serwerów poniżej 64 graczy. Oto jak sprawdzić aktualną wydajność serwera, aby ustalić punkt odniesienia przed zmianą hostingu:

-- server.lua: Performance monitoring
local perfData = {}

CreateThread(function()
    while true do
        Wait(10000) -- Check every 10 seconds
        local cpuTime = GetProfiler():ToJSON() -- FiveM built-in profiler
        local playerCount = #GetPlayers()
        local resCount = GetNumResources()

        -- Track server frame time (should stay under 33ms for 30 tick)
        local svFrameTime = GetConvar('sv_frameTime', '33')

        print(('[PERF] Players: %d | Resources: %d | Target Frame: %sms')
            :format(playerCount, resCount, svFrameTime))

        -- Log to file for analysis
        SaveResourceFile(GetCurrentResourceName(), 'perf.log',
            os.date() .. ' | Players: ' .. playerCount ..
            ' | Resources: ' .. resCount .. '\n', -1)
    end
end)

Zalecane wymagania sprzętowe

Wydajność serwera FiveM w przeważającej mierze zależy od wydajność pojedynczego wątku CPU, a nie liczba rdzeni. Środowisko uruchomieniowe serwera jest w dużej mierze jednowątkowe, co oznacza, że 4-rdzeniowy procesor 5.0 GHz znacznie przewyższy 16-rdzeniowy procesor 2.5 GHz. Jeśli chodzi o RAM, punktem wyjścia jest 8 GB dla małego serwera (poniżej 32 graczy z umiarkowaną liczbą skryptów), ale 16 GB to praktyczne minimum dla poważnego serwera roleplay z 64+ graczami, systemem telefonu, MDT, customowymi pracami i pełną ekonomią. Dysk NVMe jest niezbędny dla serwerów mocno obciążających bazę danych, ponieważ zapytania oxmysql uderzają w dysk podczas złożonych joinów i dużych odczytów. Oto podsumowanie według wielkości serwera:

• Mały (1-32 graczy): 4 rdzenie o taktowaniu 4.0+ GHz, 8 GB RAM, 50 GB NVMe SSD, przepustowość 100 Mbps
• Średni (32-64 graczy): 4-6 rdzeni o taktowaniu 4.5+ GHz, 16 GB RAM, 100 GB NVMe SSD, przepustowość 250 Mbps
• Duży (64-128 graczy): 6-8 rdzeni przy 5.0+ GHz, 32 GB RAM, 200 GB NVMe SSD, przepustowość 500 Mb/s
• Enterprise (128+ graczy): Dedykowany i9/Ryzen 9 z taktowaniem 5.5+ GHz, 64 GB DDR5, 500 GB NVMe, 1 Gbps bez limitu

Ochrona przed DDoS: absolutny wymóg

Serwery FiveM są częstym celem ataków DDoS. Niezadowoleni zbanowani gracze, konkurencyjni właściciele serwerów i przypadkowi script kiddies w pewnym momencie zaatakują Twój serwer. Bez odpowiedniej ochrony przed DDoS pojedynczy atak może wyłączyć Twój serwer na wiele godzin, a nawet dni. Szukaj dostawców hostingu, którzy oferują stale aktywna ochrona przed atakami DDoS w warstwie 4 specjalnie zoptymalizowana pod kątem ruchu serwerów gier. Standardowa ochrona przed DDoS skoncentrowana na ruchu webowym często odfiltrowuje prawidłowe pakiety gry, ponieważ przypominają one ruch ataku. Najlepsi dostawcy oferują filtrowanie uwzględniające specyfikę gier, które rozpoznaje wzorce ruchu UDP FiveM. Niektórzy dostawcy obsługują również tunelowanie GRE lub niestandardowe reguły zapory sieciowej, które pozwalają dodać zakresy IP przekaźników Cfx.re do białej listy, blokując całą resztę. Oto jak skonfigurować server.cfg, aby ograniczyć dostęp i zmniejszyć powierzchnię ataku:

# server.cfg: Security hardening
sv_hostname "Your Server Name"
sv_maxclients 64
sv_endpointPrivacy true
sv_scriptHookAllowed 0

# Restrict RCON access
rcon_password "YOUR_STRONG_PASSWORD_HERE"

# Rate limiting
rate_limiter "strict"

# Only allow connections through Cfx.re
sv_forceIndirectListing true

# Firewall rules (Linux iptables example)
# Run these in your server startup script:
# iptables -A INPUT -p udp --dport 30120 -m state --state NEW -m recent --set
# iptables -A INPUT -p udp --dport 30120 -m state --state NEW -m recent \
#   --update --seconds 10 --hitcount 20 -j DROP

Lokalizacja serwera i opóźnienia mają znaczenie

Fizyczna lokalizacja Twojego serwera decyduje o opóźnieniach, jakich doświadczają Twoi gracze. W przypadku bazy graczy głównie z Europy, hosting we Frankfurcie, Amsterdamie lub Paryżu zapewnia najlepszy średni ping na całym kontynencie. W przypadku serwerów w Ameryce Północnej lokalizacje w Dallas, Chicago lub Nowym Jorku zapewniają dobre pokrycie. Jeśli Twoja społeczność obejmuje oba kontynenty, wybierz region, w którym znajduje się większość graczy, ponieważ nie ma dobrego sposobu na obsługę zarówno UE, jak i NA z pingiem poniżej 50 ms z jednej lokalizacji. Opóźnienie poniżej 50 ms zapewnia płynną reakcję, 50-100 ms jest zauważalne, ale grywalne, a wszystko powyżej 100 ms powoduje widoczną desynchronizację podczas dynamicznych scenariuszy, takich jak pościgi policyjne czy strzelaniny. Przed wyborem hostingu przetestuj opóźnienia z docelowych lokalizacji, wykonując prosty test ping lub korzystając z narzędzia looking glass dostawcy.

Hosting bazy danych: Ta sama maszyna czy zewnętrzna?

Większość serwerów FiveM uruchamia MySQL lub MariaDB na tej samej maszynie co sam serwer FiveM. Jest to w porządku w przypadku małych i średnich serwerów, ponieważ eliminuje opóźnienia sieciowe między serwerem gry a bazą danych. Jednak na dużych serwerach z ponad 100 graczami i złożonymi systemami ekonomii przeniesienie bazy danych na osobną, dedykowaną maszynę może poprawić wydajność zarówno serwera gry, jak i samej bazy. Serwer gry zyskuje więcej pamięci RAM i mocy procesora na wykonywanie skryptów, podczas gdy baza danych otrzymuje dedykowaną przepustowość wejścia/wyjścia. Jeśli wybierzesz tę drogę, upewnij się, że serwer bazy danych znajduje się w tym samym centrum danych co serwer gry, aby utrzymać opóźnienia zapytań poniżej 1ms. Oto przykładowy connection string oxmysql dla obu konfiguracji:

# server.cfg: Database configuration

# Local database (same machine)
set mysql_connection_string "mysql://fivem:password@localhost/fivem_db?waitForConnections=true&connectionLimit=10&connectTimeout=60000"

# Remote database (separate server, same datacenter)
set mysql_connection_string "mysql://fivem:[email protected]/fivem_db?waitForConnections=true&connectionLimit=20&connectTimeout=10000"

# Performance tuning for oxmysql
set mysql_slow_query_warning 200
set mysql_debug false

# MariaDB recommended settings (my.cnf)
# [mysqld]
# innodb_buffer_pool_size = 4G
# innodb_log_file_size = 256M
# innodb_flush_method = O_DIRECT
# max_connections = 100
# query_cache_type = 1
# query_cache_size = 128M

Konfiguracja serwera na czystym VPS

Gdy wybierzesz już dostawcę hostingu, konfiguracja serwera FiveM na nowym VPS z systemem Linux przebiega według powtarzalnego procesu. Zacznij od Ubuntu 22.04 lub Debiana 12, zaktualizuj system, utwórz użytkownika innego niż root dla procesu FiveM i skonfiguruj zaporę sieciową. Nigdy nie uruchamiaj serwera FiveM jako root, ponieważ luka w jakimkolwiek skrypcie mogłaby zagrozić całej maszynie. Użyj systemd do zarządzania procesem FiveM, aby automatycznie restartował się po awarii i uruchamiał przy starcie systemu. Taka konfiguracja zajmuje około 15 minut i zapewnia środowisko serwerowe gotowe do pracy na produkcji:

#!/bin/bash
# setup-fivem.sh - Fresh VPS setup script

# Update system
apt update && apt upgrade -y

# Create FiveM user
useradd -m -s /bin/bash fivem
mkdir -p /home/fivem/server /home/fivem/server-data

# Download FiveM server artifacts
cd /home/fivem/server
wget https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/LATEST_RECOMMENDED_URL -O fx.tar.xz
tar xf fx.tar.xz
rm fx.tar.xz

# Set permissions
chown -R fivem:fivem /home/fivem

# Configure firewall
ufw allow 30120/tcp
ufw allow 30120/udp
ufw allow 40120/tcp
ufw allow OpenSSH
ufw --force enable

# Create systemd service
cat > /etc/systemd/system/fivem.service << 'EOF'
[Unit]
Description=FiveM Server
After=network.target mariadb.service

[Service]
Type=simple
User=fivem
WorkingDirectory=/home/fivem/server-data
ExecStart=/home/fivem/server/run.sh +exec server.cfg
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable fivem
echo "Setup complete! Place your server-data files and run: systemctl start fivem"

Monitorowanie i utrzymanie serwera

Po wdrożeniu kluczowe jest stałe monitorowanie. Skonfiguruj podstawowe monitorowanie zasobów za pomocą narzędzi takich jak htop do monitorowania użycia CPU i RAM w czasie rzeczywistym, iotop dla operacji I/O dysku, a vnstat do śledzenia przepustowości. Skonfiguruj automatyczne kopie zapasowe katalogu server-data oraz bazy danych, najlepiej do zewnętrznej lokalizacji offsite. Dobra strategia tworzenia kopii zapasowych to codzienny pełny zrzut bazy danych i godzinowa przyrostowa kopia tabel z danymi graczy. Monitoruj tick rate swojego serwera FiveM za pomocą panelu webowego txAdmin, który większość dostawców hostingu instaluje domyślnie. Zdrowy serwer utrzymuje stały tick rate zbliżony do skonfigurowanej wartości (zwykle 30 lub 48 ticków na sekundę). Gdy tick rate spadnie poniżej 80% wartości docelowej, czas zoptymalizować skrypty lub ulepszyć sprzęt.