Сервер Palworld не отвечает — диагностика и решение

MAATRIX GAMES

Знакомая ситуация: заходите проверить сервер, а игроки в чате пишут «не могу подключиться», хотя вы точно помните, что вчера всё работало. Процесс на VPS вроде бы жив, systemd не ругается, а по факту сервер завис намертво и никого не пускает. Это не крах и не баг конкретно вашей настройки — Palworld известна тем, что умеет зависать без явного падения, и причины обычно сводятся к паре типовых сценариев. Разберём, как быстро понять, что именно происходит, и что с этим делать — от диагностики до временного, но рабочего лечения через рестарт по расписанию.

Сначала отличаем: сервер завис или всё-таки упал

Это два разных сценария с разной диагностикой, и путать их — значит тратить время не там. Быстрая проверка:

sudo systemctl status palworld

Если статус active (running) — процесс жив, просто не отвечает на подключения. Это и есть «зависание»: PalServer.sh формально работает, занимает память и CPU, но перестал корректно обрабатывать сетевые запросы. Если статус failed или inactive (dead) — это уже не зависание, а полноценный краш или ручная остановка, и здесь сразу стоит смотреть последние строки лога через journalctl -u palworld -n 100 на предмет явной ошибки или сигнала (SIGSEGV, SIGKILL от OOM Killer).

Отдельно встречается промежуточный случай: процесс жив, но игра не видит его в списке серверов Steam, хотя прямое подключение по IP:порту работает. Это почти всегда не зависание, а проблема с флагом -publiclobby или сетевой видимостью — лечится иначе, см. раздел про сеть и порты в статье про установку сервера Palworld. Дальше разбираем именно первый случай — процесс жив, но не отвечает.

Проверяем процесс, порт и логи

Первым делом убедитесь, что сервер реально слушает свой порт, а не просто существует в списке процессов:

ss -tulpn | grep -E '8211|8212'

Если UDP 8211 не в списке вообще — процесс не смог поднять сокет (частая причина: порт уже занят другим процессом или предыдущий PalServer не завершился корректно и держит порт). Если порт в списке, но подключения всё равно не проходят — сокет открыт, но обработчик внутри игры завис на каком-то тике.

Дальше смотрим на ресурсы прямо сейчас:

top -p $(pgrep -f PalServer)

Два характерных паттерна:

• Один поток CPU упирается в 100% постоянно, память не растёт — похоже на внутренний deadlock или бесконечный цикл в обработке какого-то события (кривой сейв, битая структура мира после жёсткого краша в прошлый раз).
• CPU почти простаивает, память забита под потолок VPS — это, вероятнее всего, история про нехватку RAM, разобранную в следующем разделе.

Проверьте также, не убил ли процесс OOM Killer ядра прямо сейчас или недавно:

dmesg -T | grep -i "out of memory"
sudo journalctl -k --since "2 hours ago" | grep -i "killed process"

Если строка есть — сервер уже падал по нехватке памяти, и то, что вы видите сейчас, возможно, не зависание, а systemd, который пытается поднять его заново по Restart=on-failure и не успевает — проверьте journalctl -u palworld -f на предмет цикла постоянных рестартов.

Игра на Unreal Engine, поэтому у неё есть стандартный лог движка — если настроен вывод в файл, ищите его в ~/palworld-server/Pal/Saved/Logs/ (обычно PalServer.log). Если вывод не перенаправляли, весь консольный лог по умолчанию уходит только в journalctl, и это основной источник диагностики для большинства администраторов.

REST API health-check — проверяем отклик без захода в игру

Если у сервера включён REST API (параметр RESTAPIEnabled=True в PalWorldSettings.ini, порт TCP 8212), это самый быстрый способ понять, отвечает ли процесс на уровне приложения, а не просто существует как PID. Плюс не нужно заходить в игру и ждать таймаут подключения на клиенте.

Проверка через curl с базовой авторизацией (логин admin, пароль — тот же AdminPassword, что и в конфиге):

curl -s -u admin:ВАШ_ADMIN_PASSWORD http://IP_СЕРВЕРА:8212/v1/api/info

Если в ответ приходит JSON с версией сервера и названием мира — API-слой жив и отвечает, даже если игровые подключения по UDP не проходят. Это сигнал в сторону сетевой проблемы (файрвол, NAT, не тот порт), а не самого процесса. Если curl уходит в таймаут или получает Connection refused — процесс завис глубже, и здесь без рестарта уже не обойтись.

Полезные точки API для регулярного мониторинга (все требуют той же базовой авторизации):

• GET /v1/api/players — список текущих игроков онлайн, полезно проверять перед плановым рестартом, чтобы не выбросить активную сессию.
• GET /v1/api/metrics — базовые метрики процесса, включая онлайн и время работы сервера.
• POST /v1/api/announce — отправить объявление всем игрокам в игре (пригодится перед плановым рестартом, см. ниже).
• POST /v1/api/shutdown — инициировать корректное завершение с сохранением мира, с параметрами waittime (задержка в секундах) и message (текст оповещения игрокам).

Не забудьте открыть порт в файрволе, если REST API нужен снаружи, а не только с самого VPS:

sudo ufw allow 8212/tcp

Утечка памяти при долгом аптайме

Это самая частая причина именно «тихого» зависания без явного краша. Palworld прожорлива к RAM с самого старта (подробно — в статье про установку сервера), но проблема не только в базовом потреблении, а в том, что память растёт в течение всей сессии сервера и практически не отдаётся обратно системе — чем дольше аптайм без рестарта, тем ближе сервер к потолку.

Механика примерно такая: каждая новая база, призванный пал, предмет на земле, событие в мире — дополнительные объекты, которые сервер держит в памяти. Часть освобождается при выходе игрока или разрушении постройки, но на практике реальное потребление за недели без рестарта заметно растёт даже при стабильном онлайне — это накопительный эффект, а не разовый пик.

Как отследить тренд, а не гадать по одному замеру:

free -h

Стоит смотреть не на разовое число, а на график за несколько дней — простой способ без внешнего мониторинга: закинуть команду в cron раз в час и писать в лог-файл.

*/60 * * * * echo "$(date '+\%F \%T') $(free -m | awk '/Mem:/{print $3\"MB used\"}')" >> /var/log/palworld-mem.log

Если по логу виден устойчивый рост без плато — это накопление, которое движок не подчищает сам. Когда свободной памяти становится совсем мало, происходит один из двух сценариев: либо ядро вызывает OOM Killer и процесс падает явно (видно в dmesg), либо сервер тормозит на аллокациях настолько, что перестаёт успевать обрабатывать сетевые пакеты — то самое зависание без падения, с которого начали.

Прямое решение — RAM с запасом сверх текущего потребления, а не впритык:

Но даже с большим тарифом рост никуда не девается — он просто отодвигается по времени. Рабочее временное решение при любом объёме RAM — плановый рестарт до того, как память подойдёт к потолку, разобрано ниже.

Перегрузка при большом количестве Pal на карте

Второй частый источник зависаний — не память, а вычислительная нагрузка от ИИ-поведения палов. Каждый пал на базе или бродящий по карте — отдельная сущность, которая постоянно что-то считает: маршрут, задачу на базе, боевое поведение рядом с игроком. Чем дольше живёт мир без вайпа и чем активнее сообщество строит базы, тем больше одновременно активных палов сервер обсчитывает каждый момент — и в пиковые часы, когда активны сразу несколько баз, нагрузка складывается.

В PalWorldSettings.ini есть параметры, напрямую влияющие на это:

PalSpawnNumRate=1.000000
BaseCampMaxNum=...
BaseCampWorkerMaxNum=...

PalSpawnNumRate регулирует плотность спавна диких палов в открытом мире — выше значение, больше сущностей и нагрузки на тик даже без единого игрока рядом. BaseCampMaxNum и BaseCampWorkerMaxNum ограничивают число баз на сервере и число работающих палов на одной базе — дефолтные значения рассчитаны разработчиками с запасом на крупные сборки, и если у вас небольшое сообщество на скромном тарифе, снижение их до реальной численности группы — недооценённый способ вернуть запас производительности.

Прямого консольного способа посмотреть точное число активных палов нет (в отличие от RCON-команд Rust), поэтому ориентируйтесь косвенно: если деградация совпадает по времени с пиковым онлайном и стройкой у нескольких групп сразу, а не растёт монотонно как при утечке памяти — дело скорее в нагрузке от палов. Общий подход к диагностике нагрузки на сервер — в статье про мониторинг TPS и лагов на игровом сервере.

Смягчить проблему без смены тарифа помогает договорённость с игроками о лимитах на базы и палов, плюс периодический вайп заброшенных построек.

Рестарт по расписанию — временное решение, а не лечение

Пока не разобрались с первопричиной, плановый рестарт — самый надёжный способ не дать серверу зависнуть в разгар вечернего онлайна. Идея простая: перезапускать процесс раньше, чем память или нагрузка от палов подберутся к критической точке — по логу из раздела про утечку памяти видно, сколько часов аптайма сервер обычно выдерживает без проблем.

Лучше не убивать процесс жёстко, а сначала оповестить игроков и корректно сохранить мир через REST API:

curl -s -X POST -u admin:ВАШ_ADMIN_PASSWORD \
  -d 'waittime=60&message=Плановый рестарт сервера через 60 секунд, прогресс сохранится' \
  http://127.0.0.1:8212/v1/api/announce

sleep 60

curl -s -X POST -u admin:ВАШ_ADMIN_PASSWORD \
  -d 'waittime=10' \
  http://127.0.0.1:8212/v1/api/shutdown

Важный нюанс: если в systemd-юните стоит Restart=on-failure, корректное завершение через API (код выхода 0) не запускает автоматический рестарт — systemd посчитает это штатной остановкой. Для автоподъёма после планового шатдауна нужен Restart=always в секции [Service], либо отдельная строка в cron, поднимающая сервис явно через пару минут после команды на shutdown:

0 */6 * * * curl -s -X POST -u admin:PASS -d 'waittime=30&message=Плановый рестарт' http://127.0.0.1:8212/v1/api/shutdown
5 */6 * * * systemctl start palworld

Более подробно про настройку рестарта по расписанию (включая нюансы cron-синтаксиса и работу с разными играми) — в статье про автоматический рестарт сервера по расписанию через cron.

Держите в голове, что это временная мера, снижающая частоту зависаний, а не устраняющая их причину — если утечка памяти или перегрузка палами растёт быстрее, чем вы успеваете рестартовать сервер, честнее пересмотреть тариф или лимиты, чем гоняться за симптомом бесконечно. Pocketpair продолжает выпускать патчи, и часть из них затрагивала стабильность и потребление ресурсов — проверяйте changelog при каждом обновлении через SteamCMD, вдруг проблема уже решена в новой версии.

Частые вопросы