Проблемы с сервером после обновления Steam

MAATRIX GAMES

Rust обновился сам — вручную запускали app_update по расписанию или сработал cron-скрипт — и через пять минут после рестарта либо сервер вообще не встаёт, либо встал, но чат завален "plugin failed to load", а половина команд из Oxide просто не отвечает. Знакомая ситуация: Facepunch катит патчи еженедельно по четвергам, и каждый такой четверг для админа — небольшая лотерея. Разберём по шагам, что обычно ломается, как отличить проблему самого Rust от проблемы Oxide/uMod и плагинов, и что делать, пока не вышло совместимое обновление.

Что вообще происходит после автообновления Rust

Rust обновляется через SteamCMD — если механика самого процесса app_update не знакома, сначала стоит прочитать про установку и обновление серверов через SteamCMD, здесь эта часть не разбирается заново. Важно другое: Steam обновляет клиенты игроков автоматически и почти сразу после релиза патча, а серверная сборка обновляется только тогда, когда вы сами (вручную или по cron) прогоните app_update у себя. Из этого растут два разных сценария проблем:

• Сервер не запускается после app_update — патч поменял что-то в самом бинарнике RustDedicated или в формате файлов, с которыми сервер работает при старте (карта, конфиги, сохранения).
• Сервер запускается, но Oxide/uMod и плагины перестают работать — Facepunch меняет внутренние структуры и API игры при каждом крупном патче, а Oxide патчит именно эти структуры своими хуками. Если хуки Oxide были собраны под старую версию protocol, после обновления игры они банально не совпадают с новым кодом — и фреймворк либо не грузится вообще, либо грузится с ошибками, либо часть плагинов падает при вызове конкретных хуков.

Это два независимых источника проблем, и лечатся они по-разному, поэтому первый шаг — понять, с чем вы имеете дело именно сейчас.

Шаг 1: сначала changelog, а не паника

Прежде чем что-либо чинить — откройте официальный changelog обновления. У Rust это либо пост в Steam News на странице игры, либо блог на rust.facepunch.com, у крупных ежемесячных апдейтов почти всегда есть отдельная запись с разделом "Server" или "Modding" — именно там разработчики честно пишут о breaking changes: переименованные конвары, изменённый формат сохранений, новые обязательные параметры запуска.

Часть проблем после патча — это не баг и не ваша вина, а заранее объявленное изменение. Например, если в патче написано "renamed convar server.xxx to server.yyy" — это не повод искать проблему в файрволе, а повод просто поправить конфиг под новое имя. Проверка changelog занимает пять минут и часто экономит час бессмысленной диагностики симптома, у которого уже есть официальное объяснение.

Отдельно стоит заглянуть в комьюнити-каналы — Rust Discord у Facepunch, сабреддит r/playrust, профильные Telegram-чаты русскоязычных админов. Если у вас что-то отвалилось сразу после патча — почти наверняка не только у вас, и кто-то уже написал об этом в первые полчаса после релиза, часто с решением или хотя бы подтверждением "баг известен, ждём хотфикс".

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

Если сервис не поднимается совсем, первым делом смотрим логи, а не гадаем:

journalctl -u rustserver -f --since "10 minutes ago"

(если сервис называется иначе — подставьте своё имя юнита; в статье про установку Rust-сервера используется имя rustserver, дальше для примеров держим его же).

Основные причины падения сразу после апдейта:

• Битый билд после неудачного app_update. Обрыв соединения на середине докачки — частая история, особенно у первых часов после релиза патча, когда CDN Steam перегружен обновляющимися одновременно тысячами серверов. Лечится передокачкой с флагом validate, который сверяет контрольные суммы файлов с манифестом:

./steamcmd.sh +force_install_dir /home/rustserver/rust +login anonymous +app_update 258550 validate +quit

• Не хватает места на диске. Крупные патчи иногда заметно увеличивают вес установки — проверьте df -h перед тем как копать дальше, SteamCMD при нехватке места падает с не самой очевидной ошибкой.
• OOM после патча. Если апдейт добавил новый контент (новые постройки на процедурных картах, новые предметы), потребление RAM при генерации или загрузке карты может немного вырасти — смотрите dmesg | grep -i oom, если сервер падает уже во время загрузки карты, а не сразу при старте бинарника.
• Изменился формат конфига или сохранения. Мажорные апдейты Rust иногда меняют структуру .map/.sav-файлов или конвары в стартовой строке. Если в логе есть строка про несовместимую версию сохранения — это тот самый случай, когда changelog из первого шага заранее предупреждает о таком.

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

Плагины отвалились: Oxide или сам плагин

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

Первая проверка — версия и протокол самого фреймворка прямо в консоли или через RCON:

oxide.version

Команда выводит версию Oxide и версию протокола Rust, под который она собрана. Если протокол в ответе заметно старше текущей версии игры — Oxide ещё не обновился под свежий патч, и в этом причина всех проблем разом, плагины здесь ни при чём. Дальше смотрим список загруженных плагинов и их статус:

oxide.plugins

Если в списке плагин помечен как загруженный без ошибок, но не срабатывает у игроков — дело не в совместимости API, а в правах или конфиге (это отдельная история, не связанная с патчем игры). А вот если плагин явно висит с ошибкой компиляции или runtime-исключением сразу после апдейта — идём смотреть oxide/logs/, там обычно есть конкретная строка вида "missing method" или "hook not found", это прямой признак того, что Facepunch поменял сигнатуру внутреннего API, на который опирался плагин или сам Oxide.

Частая путаница: плагин "перестал работать" не значит автоматически "плагин сломан разработчиком плагина". Если у самого Oxide/uMod протокол не совпадает с версией игры — будут падать вообще все плагины разом, и чинить нужно фреймворк, а не бежать искать обновления каждого плагина по отдельности.

Обновление Oxide/uMod под новую версию Rust

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

sudo systemctl stop rustserver
sudo su - rustserver
cd /home/rustserver/rust
wget -O oxide.zip "ССЫЛКА_СО_СТРАНИЦЫ_UMOD_ORG_ДЛЯ_RUST_LINUX"
unzip -o oxide.zip -d .
rm oxide.zip
sudo systemctl start rustserver

Ключевой нюанс именно после патча игры: скачивать нужно свежую сборку с umod.org, а не переиспользовать старый архив, который у вас, возможно, лежит локально с прошлой установки — старая сборка Oxide просто повторит ту же несовместимость. На странице загрузки Oxide для Rust на umod.org обычно указана дата последней сборки — если она вышла раньше даты релиза патча игры, обновлённой версии ещё нет, и переустановка ничего не даст, нужно просто подождать.

После переустановки снова проверяем oxide.version — протокол в ответе должен совпасть с текущей версией игры. Если совпал, но конкретные плагины всё ещё падают — уже смотрим их отдельно: страница плагина на umod.org обычно содержит changelog с пометкой "updated for Rust X.X.X", и если автор ещё не выпустил фикс под текущий патч — остаётся только ждать или временно выгрузить проблемный плагин командой oxide.unload ИмяПлагина, чтобы он не мешал остальным работать и не сыпал ошибками в лог.

Если критично: временный откат к предыдущей версии сервера

Когда простой недопустим — активное комьюнити, турнир, крупный вайп только что стартовал — а совместимого обновления Oxide или ключевого плагина ещё нет, временная мера — откатить саму серверную сборку на билд до патча, пока фреймворк не догонит.

Технически это делается через беты депо в SteamCMD, если разработчик их держит:

./steamcmd.sh +force_install_dir /home/rustserver/rust +login anonymous +app_update 258550 -beta previous_release validate +quit

Два честных нюанса. Во-первых, ветка с предыдущим стабильным билдом доступна не всегда — актуальный список веток депо смотрите на странице приложения в SteamDB, вкладка Depots, готового имени ветки без проверки давать нельзя, у Rust оно может отличаться от патча к патчу. Во-вторых, откат сервера не откатывает клиентов игроков: Steam уже обновил их автоматически, и часть игроков с новым клиентом просто не сможет подключиться из-за несовпадения протокола — это временная мера ради выигранного времени на обновление Oxide, а не полноценное решение, часть онлайна вы всё равно потеряете.

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

Как снизить риск на будущих патчах

Полностью застраховаться от несовместимости после патча нельзя — это внешний фактор, который не зависит от того, насколько аккуратно настроен ваш сервер. Но снизить ущерб от простоя вполне реально:

• Держите бэкап перед каждым плановым обновлением, а не только по расписанию раз в сутки — если апдейт что-то сломает необратимо, откат к рабочему состоянию должен занимать минуты. Как настроить регулярные автобэкапы — в статье про автобэкапы игрового сервера.
• Не обновляйтесь ровно в момент релиза патча, если есть гибкость по времени — подождите час-два: часто в первые часы вылезают критичные баги, которые Facepunch чинит хотфиксом в тот же день, и разумнее обновиться сразу на исправленную версию.
• Держите тестовый сервер (даже маленький) с той же связкой Oxide и ключевых плагинов — накатывайте обновление туда первым и смотрите по логам, что ломается, прежде чем трогать прод.
• Знайте расписание патчей заранее — у Rust это еженедельный четверг плюс форс-вайп в первый четверг месяца, это позволяет держать окно обновления в наименее активное для комьюнити время.
• Предупреждайте комьюнити заранее о плановом простое — короткое сообщение в Discord снимает половину недовольства даже при простое в 15-20 минут.

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