Синхронизация времени на игровом сервере

MAATRIX GAMES

Сервер тормозит с расписанием рестартов, бэкапы срабатывают не в то окно, а в логах при разборе инцидента метки времени вообще не сходятся с тем, что показывают мониторинг или Discord-бот — часто корень проблемы банальнее, чем кажется: системные часы на сервере просто расходятся с реальным временем. Разберёмся, как быстро это проверить и починить, и заодно — какой часовой пояс вообще имеет смысл ставить на игровом сервере.

Почему это вообще важно

Системное время — не декоративный параметр, оно завязано на кучу практических вещей, которые администратор игрового сервера трогает каждый день.

Во-первых, cron. Если вы настраивали автоматический рестарт по расписанию или регулярные бэкапы, вся логика построена на том, что системные часы идут правильно. Cron не умеет "подстраиваться" — он просто ждёт наступления заданной минуты по системному времени. Если часы уехали на 20 минут вперёд, вся сетка расписания молча съезжает вместе с ними, и вы будете долго гадать, почему рестарт происходит не в 5:00, а в 5:20 — пока не заглянете в timedatectl.

Во-вторых, логи и расследование инцидентов. Когда сервер лёг ночью и нужно понять, что случилось — вы сопоставляете логи и крэш-репорты сервера, системный журнал (journalctl), возможно, алерты от мониторинга и жалобы игроков в Discord с таймстампами их сообщений. Если хотя бы один из этих источников живёт в своём времени — сопоставление превращается в гадание "плюс-минус сколько-то минут", и это ровно тот момент, когда точность нужна больше всего.

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

Отдельно стоит сказать честно: на подавляющем большинстве VPS у нормального провайдера синхронизация времени включена по умолчанию с момента установки образа. Это не та вещь, которая ломается сама по себе на ровном месте. Но после ручной настройки сервера, смены образа ОС, восстановления из бэкапа снапшота или работы в контейнере/виртуалке с нестандартной конфигурацией — стоит явно проверить, а не полагаться на "наверное, всё ок".

Проверяем текущий статус синхронизации

На большинстве современных дистрибутивов (Ubuntu, Debian, почти все на systemd) для этого есть встроенная утилита timedatectl — отдельно ничего ставить не нужно:

timedatectl status

Вывод выглядит примерно так:

               Local time: Sun 2026-08-30 14:23:07 UTC
           Universal time: Sun 2026-08-30 14:23:07 UTC
                 RTC time: Sun 2026-08-30 14:23:07
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ключевые поля — два:

• System clock synchronized — если стоит yes, часы синхронизированы с внешним источником времени и всё в порядке. Значение no означает, что либо синхронизация выключена, либо служба NTP не может достучаться до серверов времени (чаще всего — блокировка исходящего UDP-порта 123 фаерволом или проблема с сетью).
• NTP service — показывает, включена ли сама служба автосинхронизации (active/inactive). Не путайте с полем synchronized: служба может быть активна, но ещё не успеть синхронизироваться (например, сразу после старта сервера), тогда synchronized временно покажет no, а через минуту-другую переключится на yes.

Если на сервере вместо timedatectl стоит более старый набор утилит (встречается на легаси-дистрибутивах или в минимальных контейнерных образах), проверить синхронизацию можно через ntpstat, если он установлен:

ntpstat

Или напрямую посмотреть на клиент chrony, если используется он (об этом — ниже):

chronyc tracking

Включаем автосинхронизацию, если она выключена

Если timedatectl status показал System clock synchronized: no или NTP service: inactive, включить автосинхронизацию можно одной командой:

sudo timedatectl set-ntp true

Через несколько секунд повторите timedatectl status — поле должно смениться на yes. Если этого не произошло, скорее всего дело не в настройке, а в том, что демон синхронизации не может дотянуться до серверов времени. Проверьте, какая служба фактически отвечает за синхронизацию на вашем дистрибутиве:

systemctl status systemd-timesyncd
# или, если используется chrony:
systemctl status chronyd

Ubuntu и Debian по умолчанию используют systemd-timesyncd — лёгкий встроенный клиент, которого для игрового сервера более чем достаточно. Если его нет и NTP всё равно не поднимается, можно установить chrony — более функциональный демон, часто стоящий по умолчанию на CentOS/RHEL-подобных системах:

sudo apt update && sudo apt install chrony
sudo systemctl enable --now chronyd

После установки проверьте список источников времени, с которыми синхронизируется chrony:

chronyc sources -v

В выводе строка со звёздочкой (*) в начале — текущий выбранный источник, к которому реально идёт синхронизация. Если все источники помечены как недоступные (? в начале строки) — почти наверняка проблема в сети или в фаерволе, который режет исходящий UDP-трафик на порт 123:

sudo ufw allow out 123/udp

Часовой пояс: UTC или локальный

Это отдельный вопрос от самой синхронизации — часы могут быть идеально синхронизированы, но выставлены при этом в неудобный часовой пояс. Посмотреть текущий пояс — то же timedatectl status, поле Time zone. Сменить его:

sudo timedatectl set-timezone Europe/Moscow

Список доступных названий поясов:

timedatectl list-timezones

Тут у практикующего админа обычно есть два лагеря, и оба по-своему правы — зависит от аудитории.

UTC как часовой пояс сервера — практичный выбор, если у вас международное или разноязычное сообщество игроков (например, RU-проект с частью аудитории из СНГ и Европы, или сервер, где половина игроков из разных часовых поясов). Плюсы:

• Все таймстампы в логах, cron, бэкапах и мониторинге — в одной системе, без путаницы при пересчёте.
• При миграции на другой хостинг или в другую локацию (UK/US/RU) поведение расписания не меняется — часы сервера остаются как есть, "плывёт" только локальное время администратора относительно них.
• Проще документировать и передавать доступ другому админу или модератору — не нужно объяснять "у нас тут время такого-то региона".

Минус — расписание рестартов и событий в UTC не совпадает с интуитивным "ночь по времени игроков", придётся держать в голове смещение или явно писать его в правилах сервера (как это сделано, например, в таблице окон рестарта в статье про cron).

Локальный часовой пояс под конкретную аудиторию — логичный выбор, если сообщество сфокусировано на одном регионе (например, чисто RU-сервер или сервер под конкретный американский часовой пояс). Плюс — расписание рестартов, ивентов и внутриигрового дня/ночи сразу читается "по-человечески": рестарт в 5 утра — это реально глубокая ночь для аудитории, а не абстрактное число. Минус — при смене состава игроков или расширении на другой регион придётся пересчитывать всё расписание заново.

Универсального правильного ответа нет — это решение про удобство администрирования и ожидания аудитории, а не техническое ограничение. Многие в итоге выбирают компромисс: держат сам сервер (ОС) на UTC ради предсказуемости в логах и бэкапах, а игрокам показывают время события в игровом чате или на сайте уже с пересчётом под их пояс — это чуть больше работы на старте, но снимает путаницу в долгосрочной перспективе.

Как расхождение времени проявляется на практике

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

• Плановый рестарт или бэкап срабатывает "не вовремя" относительно того, что вы видите в реальных часах на своём компьютере, хотя cron-строка выглядит правильной.
• В логах игрового сервера метки времени не совпадают с временем в системном журнале (journalctl) на те же события — расхождение на минуты, а не на разницу часовых поясов.
• SSL/TLS-сертификаты (например, для веб-панели управления сервером или сайта сообщества) вдруг помечаются браузером как невалидные с ошибкой про дату — проверка сертификата чувствительна к системному времени, и уехавшие часы на пару часов вперёд или назад легко ломают её.
• Античит- или авторизационные плагины иногда используют временные токены (TOTP-подобные механизмы) — если часы разошлись больше чем на допустимое окно, авторизация может отваливаться без внятной причины в логе плагина.

Если заметили что-то из этого — первым делом timedatectl status, а не копание в конфиге игры.

Проверка после смены хостинга или восстановления из снапшота

Отдельная ситуация, где стоит перепроверить время осознанно — это миграция на другой хостинг или разворачивание сервера из образа/снапшота. Виртуальная машина, поднятая из старого снапшота, иногда стартует с "замороженным" на момент снятия снимка временем и требует принудительного пинка синхронизации:

sudo timedatectl set-ntp false
sudo timedatectl set-ntp true

Такой цикл выключить-включить форсирует немедленный запрос к серверам времени вместо ожидания штатного интервала синхронизации. Полезно сразу после восстановления из бэкапа или клонирования диска — на всякий случай, даже если timedatectl status формально показывает yes.

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