Полный разбор конфига Rust: server.cfg, RCON, карта

MAATRIX GAMES

Сервер уже стоит, порты пробиты, Oxide накатан — а дальше начинается настоящая работа: за что отвечает каждая строчка в конфиге, почему upkeep жрёт ресурсы быстрее, чем игроки успевают их носить, и как достучаться до консоли сервера, не сидя в SSH сутками. Этот разбор — не про первую установку (для неё есть отдельная пошаговая инструкция), а про то, что делать с уже работающим сервером, когда хочется управлять им осознанно, а не методом "скопировал с форума и надеюсь".

Как на самом деле устроен server.cfg

У Rust нет единого священного файла с полным списком всех параметров — то, что называют server.cfg, это просто текстовый файл с консольными командами (convar'ами), которые сервер выполняет построчно при старте через +exec server.cfg. Лежит он обычно в server/<identity>/cfg/server.cfg — там же, где сейвы и остальные конфиги конкретного инстанса (identity — это то самое имя из +server.identity).

Формат простой: одна команда на строку, без плюсов, без кавычек вокруг числовых значений:

server.hostname "Мой Rust сервер | PvP | x2"
server.description "Дружелюбный PvP, вайп по четвергам"
server.url "https://example.com"
server.headerimage "https://example.com/header.jpg"
server.tags "monthly,pvp"
server.maxplayers 100
server.saveinterval 300

Запускать сервер можно двумя способами: портянкой +flag value прямо в команде запуска, либо вынести всё в server.cfg и запустить с одним +exec server.cfg. Второй вариант удобнее почти всегда — конфиг можно версионировать в git, комментировать (строка с // в начале игнорируется) и не терять правки между рестартами systemd-юнита.

Важный нюанс: не все convar'ы можно положить в server.cfg и ждать, что они применятся на лету при рестарте сервиса через systemctl restart — часть параметров (например, server.worldsize) требует полной регенерации карты, а не просто перечитывания конфига. Если сомневаетесь, применится ли параметр без вайпа — правьте его через RCON на живом сервере и смотрите на реакцию, прежде чем прописывать в конфиг для следующего рестарта.

Полный список доступных на вашей текущей версии convar'ов сервер печатает по команде find в консоли — например, find decay покажет все переменные с "decay" в имени и их текущие значения. Это надёжнее, чем гуглить старые гайды: Facepunch время от времени добавляет, переименовывает или убирает convar'ы между крупными обновлениями, и find всегда покажет актуальный список именно для вашей версии билда.

Генерация карты: worldsize, seed и что ещё влияет на мир

Базовые server.worldsize и server.seed дают уникальную карту, но у процедурной генерации есть ещё несколько параметров, которые редко упоминают в базовых гайдах:

server.level "Procedural Map"
server.worldsize 3500
server.seed 12345
server.levelurl ""

• server.level — либо "Procedural Map" для генерации на лету, либо "Barren" (голая карта почти без ресурсов, редко используется вне тестовых серверов), либо путь/URL для кастомной карты.
• server.levelurl — прямая ссылка на файл кастомной карты (.map). Если заполнено — сервер игнорирует worldsize/seed и качает карту по этому адресу при старте. Подробный разбор процесса (включая проверку версии карты под текущий патч игры и типичные грабли с битым файлом) — в статье про кастомные карты Rust.
• server.seed — если оставить пустым или не задавать явно, при каждом рестарте с одинаковым server.level "Procedural Map" сервер может сгенерировать новую карту, что почти всегда нежелательно между не-вайповыми рестартами. Фиксируйте seed всегда, даже если вам "всё равно какая карта" — иначе каждый краш с последующим авторестартом рискует стереть карту игроков без предупреждения.

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

Отдельно стоит помнить: смена worldsize или seed на уже запущенном сервере не подхватится "тихо" при рестарте systemd-юнита — сервер честно перегенерирует карту заново, а старые сейвы построек к новой карте не подойдут (координаты не совпадут с новым рельефом). Это по сути и есть форс-вайп, даже если вы не планировали его специально.

RCON: порт, пароль и что это вообще такое

RCON (Remote Console) — протокол, который даёт доступ к серверной консоли Rust без прямого SSH-подключения к машине. Через RCON можно смотреть логи в реальном времени, кикать/банить игроков, менять convar'ы на лету и выполнять админ-команды — то же самое, что видно в консоли сервера при запуске в терминале, но удалённо.

Базовые параметры в конфиге:

rcon.port 28016
rcon.password "длинный-случайный-пароль-без-словарных-слов"
rcon.web 1

• rcon.port — TCP-порт, по умолчанию часто указывают server.port + 1, но это не жёсткое правило, можно взять любой свободный.
• rcon.password — критично важный пароль. RCON-порт, если он открыт наружу, сканируют боты постоянно и без перерыва — это фоновый шум интернета, а не признак прицельной атаки на конкретно ваш сервер. Слабый пароль здесь — прямой путь к тому, что кто-то чужой получит полный контроль над сервером, вплоть до удаления сейвов через консольные команды.
• rcon.web — включает поддержку WebSocket-подключения (веб-RCON) поверх того же порта, без него работает только "классический" RCON-протокол по TCP.

Держать RCON-порт открытым для всего интернета — плохая практика даже с надёжным паролем. Разумный минимум: файрвол с whitelisted-IP только для вашего рабочего адреса, либо доступ через VPN/SSH-туннель, а порт наружу вообще не светить. Проверить, что порт закрыт для посторонних — nmap -p 28016 ВАШ_IP с внешней машины, где не должно быть открытого TCP.

Веб-RCON: подключение и практическое использование

С включённым rcon.web 1 консоль сервера доступна через WebSocket по адресу вида ws://IP:RCON_PORT/PAROL (пароль передаётся прямо в пути подключения, поэтому имеет смысл ходить через VPN, а не через открытый интернет без шифрования). Для повседневной работы обычно используют готовые клиенты — десктопные приложения вроде RustAdmin под Windows или любой другой websocket-based RCON-клиент под вашу ОС, которые оборачивают этот протокол в удобный интерфейс со списком онлайн-игроков, историей команд и подсветкой логов.

Типичные команды, которые дергают через RCON в повседневной админке:

status
say "Вайп сегодня в 15:00 UTC, готовьтесь"
kick "SteamID_или_ник" "причина"
ban "SteamID" "причина"
unban "SteamID"
global.playerlist
server.save

server.save стоит гонять вручную перед любыми рискованными правками конфига или обновлением плагинов — отдельно от автосохранения по server.saveinterval, чтобы иметь свежую точку отката прямо перед изменением.

Важный практический момент: часть convar'ов применяется мгновенно при вводе через RCON (например, server.hostname или лимиты чата), а часть требует полного рестарта процесса, чтобы вступить в силу (например, server.worldsize). Если правка через RCON "не сработала" — не спешите считать это багом, сначала проверьте через find текущее значение переменной: возможно, команда прошла, но требует рестарта.

Decay и upkeep: как реально работает разрушение построек

Decay — это система, которая разрушает постройки со временем, если они не защищены Tool Cupboard (TC) с достаточным запасом ресурсов на upkeep. Механика в двух словах: постройки внутри радиуса действия TC с наполненным upkeep не разрушаются вообще, постройки без TC или с пустым upkeep начинают терять прочность тиками через фиксированные промежутки времени, причём скорость разрушения зависит от материала — деревянные (twig/wood) рушатся заметно быстрее, чем каменные, металлические и бронированные (armored) конструкции.

Тонко настраивается это через блок convar'ов с префиксом decay.* — точный список и текущие значения на вашей версии сервера безопаснее всего смотреть прямо в консоли командой find decay и find upkeep, поскольку Facepunch время от времени корректирует баланс между крупными обновлениями, и жёстко зафиксированные в старых гайдах цифры рискуют быть неактуальными на вашем билде. Из того, что стабильно существует как концепция уже много лет:

• периодичность тиков разрушения (как часто пересчитывается decay для незащищённых построек);
• множитель скорости decay для разных материалов построек;
• переключатель системы upkeep целиком (включена/выключена).

Практический смысл настройки decay/upkeep — это баланс под тип вашего сервера. На казуальном PvE-сервере с редким онлайном имеет смысл замедлять decay или вовсе слегка ослаблять требования upkeep, чтобы игроки не теряли базы за пару дней отпуска. На хардкорном PvP-вайповом сервере, наоборот, часто оставляют дефолтные или даже усиленные значения — decay брошенных баз освобождает место на карте под новых игроков и не даёт скопиться "кладбищу" из заброшенных построек к концу вайпа.

Прежде чем менять decay-баланс через голый конфиг, стоит прикинуть — не проще ли решить задачу плагином с более гибкими правилами (например, разные множители decay по зонам карты или временное отключение decay на ивент). Обзор категорий таких инструментов и как искать актуальные версии на umod.org — в статье про топ плагинов для Rust-сервера.

Безопасная практика правки конфига и бэкапы

Любая правка server.cfg на живом сервере с активным онлайном — риск: опечатка в числовом значении, случайно оставленная кавычка или запятая может уронить сервис при следующем рестарте, а часть параметров (как обсуждали выше) вообще не даёт отката без вайпа карты. Несколько практик, которые снимают большую часть боли:

1. Версионируйте server.cfg в git (или хотя бы копируйте с датой в имени файла перед каждой правкой) — откат к рабочей версии тогда занимает секунды, а не гадание, что именно сломалось.
2. Тестируйте новые convar'ы через RCON на живом сервере, прежде чем прописывать их в конфиг постоянно — так вы сразу видите реакцию сервера и логов, не дожидаясь следующего рестарта.
3. Держите отдельный бэкап-скрипт для папки server/<identity> целиком (сейвы, конфиги, blueprint-данные игроков), а не полагайтесь только на встроенный server.saveinterval — это защита от порчи файла, а не только от потери прогресса при краше.
4. Проверяйте синтаксис перед рестартом на проде — если есть тестовый инстанс или хотя бы возможность запустить сервер вручную в foreground (./RustDedicated -batchmode +exec server.cfg без демонизации через systemd), ошибки конфига будут видны сразу в консоли, а не только по факту падения сервиса.
5. Не меняйте несколько параметров одновременно перед сложным рестартом (особенно worldsize/seed вместе с decay-настройками) — если что-то пойдёт не так, сложнее понять, какая именно правка стала причиной.

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