Serwer Palworld się zawiesza: Naprawa wycieków pamięci i błędów startu (2026)

Jeśli twój serwer Palworld się zawiesza, przyczyną prawie zawsze jest jedna z pięciu rzeczy, a "potrzebuję lepszego internetu" nie jest na liście. Po obsłudze tysięcy instancji Palworld przez nasz panel Pterodactyl widzimy tych samych winowajców raz po raz: znany memory leak silnika, który zabija serwery co 30 minut do 4 godzin, błąd bindowania przy starcie, korupcję Level.sav po twardym killu, pal-entity-overflow w dużej bazie oraz version-drift po patchu.

Pale z Palworld obsługujące działka M2 na ufortyfikowanej bazie

Najpierw zidentyfikuj który to crash

Otwórz konsolę serwera (w Pterodactyl: zakładka Console) i wyszukaj w ostatnich 200 liniach jeden z tych wzorców:

LogMemory: Out of memory                    # memory leak / OOM kill
bind: Address already in use                # konflikt portów przy starcie
LogPalSav: Failed to load Level.sav         # korupcja save'a
LogPalNetworkConnection: ProtocolMismatch   # version drift po patchu
Fatal error: [File:...UE5...World.cpp]      # pal entity overflow

Linia mówi do której sekcji przeskoczyć.

Fix 1: Memory leak (zabójca co 30 minut i co 4 godziny)

Najczęstsza przyczyna. Binarka dedykowanego serwera Palworld przecieka pamięć liniowo wraz z liczbą graczy i pali. Serwer dla 4 graczy z 80 palami urośnie z 3 GB przy starcie do ponad 8 GB w 4 godziny. Serwer społecznościowy na 16 osób osiąga 12 GB w 30 minut. Gdy host zabije proces, twoi gracze widzą "server connection lost".

Objaw w logu: LogMemory: Out of memory - process killed. Nie ma czystego fixa konfiguracyjnego. Co możesz zrobić:

Przydziel wystarczająco RAM od początku. 8 GB dla 4-8 graczy, 12 GB dla 8-16, 16 GB dla 16-32.
Zaplanuj codzienny restart. Restart co 4-6 godzin czyści wyciekniętą pamięć. Na DoomHosting w zakładce Schedules: wybierz "Restart server" i cron typu 0 */6 * * *.
Ogranicz liczbę pali. W PalWorldSettings.ini zmniejsz BaseCampWorkerMaxNum=15 do 10, jeśli wasza grupa maxuje każdą bazę.
Unikaj odruchu "więcej workerów". WorkerThreadsForUE4=0 i wyższy NumberOfWorkerThreadsServer nie zmniejszają wycieku. Przyspieszają go.

Baza Palworld z wieloma pracującymi palami; liczba entity napędza wyciek

Fix 2: Serwer crashuje przy starcie (błąd bind)

Jeśli serwer umiera w pierwszych 10 sekundach i nigdy nie dociera do "World loaded", to prawie nigdy nie save. To konflikt portów lub błąd parsowania configa. Log pokazuje bind: Address already in use albo LogConfig: Failed to parse PalWorldSettings.ini at line 47.

Palworld domyślnie używa UDP 8211 i REST-API TCP 8212. Na self-hostowanej maszynie każdy inny proces na tym samym porcie blokuje nowy. Zatrzymaj konkurenta lub zmień port Palworld w startup-args (-port=8214 -publiclobby).

Dla błędu parsowania wina leży w PalWorldSettings.ini a wadliwa linia jest w logu. Najczęstsza pułapka: plik używa OptionSettings=(...) w jednej linii, a brakujący przecinek między dwoma opcjami psuje plik od następnej linii.

Na DoomHosting przydzielamy porty automatycznie i walidujemy config przed każdym startem. Self-hosting: ss -tulnp | grep 8211 pokaże który proces trzyma port.

Fix 3: Korupcja Level.sav

Jeśli serwer ładował się wczoraj, a dziś nie, save jest prawdopodobnie skorumpowany. Najczęściej po twardym killu: host wyciągający wtyczkę w środku save'a, OOM podczas zapisu autosave'a, albo brak prądu na self-host. Log: Failed to load Level.sav - end of file at position xxxx.

Palworld nie robi automatycznych backupów. Recovery:

Sprawdź plik .bak w folderze save i przemianuj na Level.sav.
Sprawdź folder Players/. Save'y graczy często przeżywają gdy Level.sav nie.
Szukaj Level.sav.tmp. Jeśli rename został przerwany, .tmp może wciąż trzymać poprawny save.

Na DoomHosting robimy codzienne snapshoty. Otwórz ticket, cofniemy się do wczorajszego snapshota w mniej niż pięć minut.

Fix nie-recovery: włącz prawdziwy backup-schedule na przyszłość. Zakładka Schedules, "Create backup" na cronie co 6 godzin.

Fix 4: Pal-entity-overflow (crash dużej bazy w late game)

Specyficzny crash late-game uderza w graczy z bardzo dużymi bazami. 15+ pali pracujących przy rafinerii, sphere lights wszędzie, mnóstwo decoration. Serwer chodzi dobrze dla nowych graczy, ale crashuje gdy ktoś teleportuje się do tej gęstej bazy. Log: Fatal error: [File:...UE5/Engine/Source/.../PrimitiveSceneProxy.cpp].

Fix: zmniejsz BaseCampWorkerMaxNum=15 do 10 w PalWorldSettings.ini. Potwierdź bIsMultiplay=True. Przenieś najgorszą bazę 200+ metrów od pozostałych.

Fix 5: Version drift po patchu (zwłaszcza wokół 1.0)

Palworld pusha update'y serwera przez SteamCMD, a świeżo zapatchowany klient może odmówić połączenia z serwerem na starej binarce. Log: Disconnect reason=ProtocolMismatch.

Fix: ponownie uruchom SteamCMD. Na DoomHosting to "Reinstall" w panelu (świat zostaje). Self-hosting: steamcmd +login anonymous +force_install_dir ./palworld_server +app_update 2394010 validate +quit.

Z launchem Palworld 1.0 10 lipca 2026 ten fix ugryzie wiele serwerów w pierwszym tygodniu. Zaktualizuj serwer w ciągu godziny od pojawienia się patcha dla klienta.

Gracze Palworld na ujeżdżonych palach przez multiplayerową osadę

Hostuj swój serwer Palworld na DoomHosting

Większość fixów powyżej to jedno kliknięcie na managed hoście. RAM skaluje się bez utraty świata. Zakładka Schedules obsługuje restart co 6 godzin, żeby memory leak nigdy nie sięgnął sufitu. Codzienne snapshoty przetrwają korupcję Level.sav. Update'y SteamCMD działają jednym kliknięciem w dzień patcha. Jeśli masz dość debugowania crashy w noc przed raidem grupy, hostuj serwer Palworld na DoomHosting: natychmiastowe uruchomienie na sprzęcie Ryzen 9, UDP 8211 otwarty z góry, pełny FTP, ochrona DDoS i wsparcie 24/7.