Satisfactory: сервер не запускается — диагностика

MAATRIX GAMES

Запускаете FactoryServer.sh, консоль моргает и закрывается, процесс висит в списке пару секунд и пропадает, или сервер вроде поднялся, но в списке серверов его никто не видит. Знакомая ситуация — Dedicated Server Satisfactory не самый капризный из выделенных серверов, но у него своя пачка типичных граблей: от недостающей 32-битной библиотеки на чистом Ubuntu до банального конфликта портов с другим процессом на той же машине. Разбираем по шагам, как найти реальную причину вместо гадания.

Первым делом — смотрим лог

Не гадайте, что сломалось, — читайте лог. Запускайте сервер с флагом -log, если ещё не запускали:

./FactoryServer.sh -unattended -log

Файл лога появится в FactoryGame/Saved/Logs/FactoryGame.log внутри папки установки. Если процесс падает мгновенно и лог даже не успевает создаться — дело почти наверняка в зависимостях (следующий раздел) или в правах на исполняемый файл:

chmod +x FactoryServer.sh

Если лог создаётся, но обрывается на середине — открывайте его и ищите последние строки перед обрывом, обычно там прямым текстом написано, чего не хватает: библиотеки, файла, порта. Общий подход к разбору логов и краш-репортов подробно разобран в статье про логи и краш-репорты — пригодится не только для Satisfactory.

Частые строчки в логе и что они значат:

Не хватает зависимостей на Linux

Самая частая причина падения «в тишину» на свежем Ubuntu/Debian — сервер собран как 32-битное приложение (несмотря на то что сама игра давно 64-битная, часть рантайма Unreal Engine всё ещё тянет 32-битные библиотеки совместимости), и без них процесс просто не стартует.

Ставим недостающее:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y lib32gcc-s1 lib32stdc++6 libcurl4

На старых дистрибутивах вместо lib32gcc-s1 может понадобиться lib32gcc1 — название пакета менялось между релизами Ubuntu, если один не находится в репозитории, ищите второй.

Ещё один частый случай — сервер держат в Docker-контейнере на минимальном образе (alpine, distroless), где вообще нет glibc-совместимости. Alpine на musl libc для Dedicated Server Satisfactory не подходит без танцев с бубном — берите образ на базе Debian/Ubuntu.

Проверить, каких библиотек не хватает конкретно вашему бинарнику, можно так:

ldd FactoryServer.sh

Правда, FactoryServer.sh — это обёртка-скрипт, реальный бинарник лежит в подпапке Engine/Binaries/Linux/, проверяйте ldd именно на нём, если хотите увидеть список зависимых библиотек напрямую.

Проверяем, не битая ли установка

Если зависимости на месте, а сервер всё равно вылетает без внятной причины в логе (или пишет что-то про повреждённые файлы, отсутствующий pak-файл, ошибку загрузки уровня) — велика вероятность, что установка через SteamCMD прервалась или скачала не всё.

Самое надёжное — переустановить с флагом validate, который сверяет контрольные суммы каждого файла и докачивает битые:

cd ~/steamcmd
./steamcmd.sh +force_install_dir /home/steam/satisfactory-server +login anonymous +app_update 1690800 validate +quit

App ID 1690800 — это именно Dedicated Server, отдельное приложение от клиентской игры, не перепутайте с id самой Satisfactory. Процесс скачает 3-4 ГБ, и если предыдущая установка была битой — validate дозагрузит недостающие куски или перекачает повреждённые целиком. Подробнее про сам процесс установки и обновления через SteamCMD — в отдельной статье про SteamCMD.

Если validate не помогает и сервер продолжает падать на том же месте — проверьте место на диске (df -h): SteamCMD молча обрывает закачку, если диск заполнился, а в логе установки это легко пропустить среди технического вывода. Ещё один вариант — снести папку установки полностью и поставить с нуля, это надёжнее долгих танцев с частичным ремонтом:

sudo systemctl stop satisfactory
rm -rf /home/steam/satisfactory-server
./steamcmd.sh +force_install_dir /home/steam/satisfactory-server +login anonymous +app_update 1690800 validate +quit

Конфликт портов: сервер запускается, но недоступен

Отдельная ситуация — процесс FactoryServer в htop живой, в логе нет ошибок, но сервер не отвечает или падает через несколько секунд после старта именно на этапе инициализации сети. Проверьте, не занят ли порт кем-то другим:

sudo ss -tulpn | grep -E '7777|15000'

Если видите чужой процесс на 7777/UDP или 15000/UDP (например, второй запущенный по ошибке инстанс Satisfactory, или другая игра, которую когда-то настроили на тот же порт) — либо остановите конфликтующий процесс, либо смените порты у Satisfactory явными флагами:

./FactoryServer.sh -unattended -log -Port=7778 -BeaconPort=15001

Если держите на одной машине несколько серверов Satisfactory (например, тестовый и боевой), у каждого обязательно должны быть разные пары -Port/-BeaconPort — иначе второй экземпляр либо не запустится, либо будет конфликтовать с первым непредсказуемо.

Отдельно бывает ситуация «сервер запустился, но никто не может подключиться» — это не про падение процесса, а про проброс портов. Если процесс жив и лог чистый, но игроки не видят сервер в списке — идите в статью про проброс портов, там разобрана диагностика именно этого случая отдельно, включая разницу между VPS и домашним роутером.

Сервер падает при загрузке конкретного сохранения

Бывает так, что сервер стабильно стартует с новым миром, но валится именно при загрузке конкретного .sav-файла. Это почти всегда один из трёх вариантов:

1. Файл сохранения повреждён. Проверьте размер файла — если он подозрительно маленький (килобайты вместо десятков мегабайт на разросшейся фабрике) или обрывается на очевидно неполном значении, это битый файл, восстанавливать его штатными средствами нельзя, нужна более ранняя резервная копия.
2. Несовпадение веток experimental/stable. Сохранение, сделанное на experimental-ветке, может не загрузиться на сервере с stable-версией и наоборот. Проверьте версию через +app_info_print 1690800 в SteamCMD и сверьте с тем, на какой ветке был сделан сейв.
3. В мире был установленный мод, а на сервере модов нет (или наоборот) — при загрузке сейва сервер ищет зависимости мода и падает, если их нет. Если переносите модифицированный мир, на сервере должны стоять те же моды через SML — процесс описан в статье про моды для Satisfactory.

Если не уверены, какой из трёх случаев ваш — попробуйте создать новый мир («New Game») с тем же билдом сервера. Если новый мир стартует нормально, а старый сейв — нет, проблема точно в файле сохранения или в модах, а не в самой установке сервера.

Веб-интерфейс Server Manager не открывается

Отдельная категория жалоб — не «сервер не запускается» в смысле игрового процесса, а «не открывается страница настройки» по адресу https://IP:7777. Процесс FactoryServer при этом обычно жив. Проверьте по порядку:

• Файрвол блокирует TCP 7777. Игровой порт 7777/UDP и веб-порт 7777/TCP — разные протоколы на одном номере, и открыть нужно оба отдельно:

sudo ufw allow 7777/udp
sudo ufw allow 7777/tcp
sudo ufw allow 15000/udp

• Сертификат браузер блокирует полностью, а не просто предупреждает. Server Manager использует самоподписанный сертификат, обычно браузер даёт кнопку «Продолжить» / «Перейти на сайт», но в некоторых корпоративных или сильно зарегулированных сетевых политиках такие переходы блокируются целиком — попробуйте другой браузер или сеть.
• Порт сменён явным флагом -ServerManagerPort= при запуске, а вы стучитесь на дефолтный 7777. Проверьте, с какими параметрами реально стартовал процесс — посмотрите вывод ps aux | grep FactoryServer.

Если разбираетесь с портами и файрволом на игровом сервере впервые — стоит понимать разницу между TCP и UDP и общий принцип, какие правила нужны, а какие лишние.

Нехватка памяти и OOM-килл

Ещё одна причина внезапной смерти процесса без явной ошибки в игровом логе — сервер съел всю доступную RAM, и его убил OOM killer на уровне операционной системы. В логе Satisfactory при этом может не быть вообще ничего полезного, процесс просто исчезает.

Проверить это можно через системный журнал:

dmesg -T | grep -i "killed process"
journalctl -k | grep -i "out of memory"

Если видите там FactoryServer — дело в памяти. На разросшихся фабриках (тысячи производственных зданий, десятки поездов, дроны) потребление RAM растёт заметно, и минимальных 6 ГБ, комфортных для старта, на позднем этапе может не хватать. Решения два: поднять лимит RAM у сервера (через тариф хостинга или физически) либо временно снизить нагрузку — например, урезать частоту тиков дронов/поездов, если такая настройка доступна в текущей версии игры. Постоянный мониторинг через htop рядом с процессом до и после падения обычно быстро подтверждает или опровергает эту версию.

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