Webhook требует отдельной проверки

Telegram-бот может отлично работать несколько дней подряд, а потом внезапно исчезнуть. Пользователи пишут команды, но ответа нет. Администратор заходит на сервер, запускает скрипт вручную — бот снова оживает. На первый взгляд кажется, что проблема странная: код ведь не менялся, токен правильный, интернет есть.

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

More publications

The sportsbook grid: mapping the 2026 Mr Punter probability network

Преимущества покупки тура через турагентство: поддержка, экономия времени и рисков

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

Почему бот пропадает после перезагрузки

На локальном компьютере разработчик часто запускает бота простой командой:

python bot.py

На сервере многие делают то же самое. Подключились по SSH, перешли в папку проекта, активировали окружение, запустили файл. Бот отвечает. Кажется, всё готово.

Но такой запуск привязан к текущей сессии или конкретному процессу. Если сервер перезагрузится, процесс завершится. Система не знает, что его нужно снова поднять. Она не знает, из какой папки запускать бота, каким Python пользоваться, где лежит файл с переменными и от какого пользователя всё должно работать.

Поэтому после reboot бот молчит. Код не сломан. Просто никто его не запустил.

Ручной запуск подходит только для проверки

Ручной запуск нужен на этапе разработки и отладки. Он помогает быстро увидеть ошибку, проверить новую команду, протестировать подключение к Telegram API, убедиться, что токен работает.

Но для постоянной работы этого мало. Рабочий бот должен вести себя как обычная серверная служба:

запускаться после перезагрузки;
перезапускаться при падении;
писать логи;
работать от понятного пользователя;
использовать правильное окружение;
не зависеть от открытой SSH-сессии.

Иначе администратор каждый раз становится частью инфраструктуры. Пока он помнит и успевает зайти на сервер, бот работает. Как только забыл — бот исчезает.

Самый частый вариант — systemd

На Linux-серверах для автозапуска часто используют systemd. Это системный менеджер служб. Он умеет запускать процессы при старте сервера, следить за их статусом, перезапускать при сбое и показывать логи через журнал.

Для Telegram-бота на Python служебный файл может выглядеть так:

[Unit]
Description=Telegram Bot
After=network.target

[Service]
WorkingDirectory=/opt/telegram-bot
ExecStart=/opt/telegram-bot/venv/bin/python /opt/telegram-bot/bot.py
Restart=always
RestartSec=5
User=botuser

[Install]
WantedBy=multi-user.target

Здесь важны несколько строк.

WorkingDirectory указывает папку проекта. Без неё бот может не найти файлы, базу, настройки или относительные пути.

ExecStart задаёт точную команду запуска. Лучше указывать Python из виртуального окружения, а не надеяться на системный python.

Restart=always говорит системе перезапускать бота при падении.

User=botuser задаёт пользователя, от имени которого работает процесс. Это безопаснее, чем запускать всё от root без необходимости.

После настройки службу нужно включить

Создать файл службы недостаточно. Её нужно включить в автозапуск и запустить.

systemctl daemon-reload
systemctl enable telegram-bot
systemctl start telegram-bot

После этого стоит проверить статус:

systemctl status telegram-bot

Если всё нормально, служба будет активна. Но на этом проверка не заканчивается. Главный тест — перезагрузка сервера.

reboot

Через минуту нужно снова подключиться и проверить:

systemctl status telegram-bot

А потом написать боту в Telegram. Если он отвечает после reboot без ручного запуска, автозапуск настроен правильно.

Проблема с виртуальным окружением

Очень частая ошибка: вручную бот запускается, а через службу нет. Причина может быть в виртуальном окружении.

При ручном запуске разработчик делает так:

source venv/bin/activate
python bot.py

После активации окружения команда python использует нужные библиотеки. Но systemd ничего не знает о том, что вы активировали вручную. Поэтому в службе лучше указывать полный путь к Python внутри venv:

ExecStart=/opt/telegram-bot/venv/bin/python /opt/telegram-bot/bot.py

Так бот запускается с теми зависимостями, которые были установлены для проекта.

Переменные окружения и файл .env

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

Если бот использует файл .env, нужно убедиться, что код загружает его из правильного места. Например, если файл лежит в папке проекта, а служба запускается из другой директории, бот может не найти токен.

Именно поэтому в systemd-файле важна строка:

WorkingDirectory=/opt/telegram-bot

Также можно явно подключить файл окружения:

EnvironmentFile=/opt/telegram-bot/.env

Тогда служба будет получать переменные из указанного файла. При этом права на .env нужно ограничить, потому что там обычно лежит токен Telegram-бота и другие секреты.

Пути к файлам должны быть предсказуемыми

Бот может работать вручную, но падать при автозапуске из-за относительных путей. Например, в коде указано:

open("data/users.db")

При запуске из папки проекта всё хорошо. При запуске из другой директории файл уже не находится. То же касается логов, шаблонов, файлов базы, временных папок, изображений и конфигов.

Лучше либо правильно задавать WorkingDirectory, либо строить пути относительно файла проекта. Тогда бот не будет зависеть от того, откуда его запустили.

Логи нужны до первой проблемы

Когда бот не поднялся после перезагрузки, без логов начинается угадывание. Вроде бы служба есть, файл на месте, токен правильный. Но что именно пошло не так?

Для службы можно смотреть журнал:

journalctl -u telegram-bot -f

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

Полезно также писать собственные логи в файл. Например, запуск, остановку, ошибки обработки сообщений, ошибки внешних API. Главное — не забыть о ротации, чтобы лог-файлы не росли бесконечно.

Права доступа могут сломать автозапуск

Если вручную бот запускали от root, а службу настроили от пользователя botuser, могут появиться ошибки прав. Например, бот не может читать .env, писать в папку logs, открывать базу или создавать временные файлы.

Это не значит, что нужно снова запускать всё от root. Лучше правильно выдать права на папку проекта.

chown -R botuser:botuser /opt/telegram-bot

После этого нужно проверить, что служба запускается именно от нужного пользователя и имеет доступ ко всем рабочим файлам.

Отдельно стоит защитить файл с токенами:

chmod 600 /opt/telegram-bot/.env

Так его сможет читать владелец, но не все пользователи сервера.

База данных не должна теряться при обновлениях

Если бот хранит данные в SQLite, файл базы часто лежит рядом с кодом. Это удобно, пока проект маленький. Но при обновлениях появляется риск случайно удалить или перезаписать базу.

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

Например:

/var/lib/telegram-bot/bot.db

А в проекте явно указать путь к базе через переменную окружения:

DATABASE_PATH=/var/lib/telegram-bot/bot.db

Так код можно обновлять отдельно, а данные остаются в рабочем каталоге.

Не стоит полагаться на screen как на постоянное решение

Некоторые запускают бота через screen или tmux. Это лучше, чем держать обычную SSH-сессию открытой. Процесс продолжит работать после отключения от терминала.

Но после перезагрузки сервера такой процесс всё равно исчезнет. screen удобен для тестов, долгих ручных операций или временного запуска. Для постоянного Telegram-бота лучше использовать системную службу.

Если бот важен, он должен подниматься сам. Без напоминаний, без ручного входа по SSH, без поиска старой команды в истории терминала.

Webhook требует отдельной проверки

Если бот работает через polling, после перезагрузки достаточно поднять процесс. Он сам снова начнёт получать сообщения от Telegram.

С webhook схема сложнее. Помимо самого бота, нужно проверить веб-сервер, HTTPS-сертификат, домен, маршрут, порт и доступность endpoint. После перезагрузки может подняться не только бот, но и Nginx, SSL, backend-сервис.

Для новичков polling часто проще. Webhook имеет смысл, когда есть опыт или конкретная причина его использовать. Если бот небольшой, работает для внутренних задач или тестируется на старте, простота polling может быть преимуществом.

Что проверить после каждой перезагрузки

После reboot не стоит ограничиваться фразой «сервер включился». Нужно пройти короткую проверку:

Служба бота активна.
В логах нет критических ошибок.
Бот отвечает в Telegram.
Команды администратора работают.
База данных доступна.
Внешние API отвечают, если они используются.
Свободное место на диске не закончилось.
Файл .env читается службой.

Эта проверка занимает несколько минут, но помогает быстро поймать проблему. Особенно после обновлений системы или изменения кода.

Обновления сервера не должны быть сюрпризом

Сервер иногда нужно обновлять. После обновлений может потребоваться перезагрузка. Если бот не настроен как служба, он пропадёт. Если служба настроена плохо, он может не подняться.

Перед обновлениями полезно убедиться, что:

бот работает через автозапуск;
есть резервная копия базы и конфигов;
понятно, как смотреть логи;
есть команда для ручного перезапуска;
известен путь к проекту;
документированы переменные окружения.

Тогда перезагрузка сервера не выглядит как рискованное событие. Она становится обычной технической процедурой.

Мониторинг помогает узнать о проблеме раньше пользователей

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

Минимальные варианты:

периодически проверять статус службы;
настроить уведомление при падении процесса;
использовать команду /status для администратора;
следить за местом на диске;
проверять логи после обновлений;
использовать внешний мониторинг доступности, если бот работает через webhook.

Лучше узнать о проблеме самому, чем получить сообщение от клиента: «бот не отвечает уже полдня».

Готовая среда снижает количество ручных ошибок

Если Telegram-бот нужен для рабочего проекта, а опыта настройки VPS мало, можно упростить старт. Не обязательно вручную собирать каждый элемент: Python, окружение, службу, логи, базовые настройки сервера.

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

Даже в готовой среде нужно понимать базовые вещи: где хранится токен, как перезапустить бота, где смотреть логи, что произойдёт после reboot. Но старт становится спокойнее.

Короткий чек-лист, чтобы бот не потерялся

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

бот запущен не вручную, а как служба;
служба включена в автозапуск;
после перезагрузки бот отвечает;
используется Python из виртуального окружения;
переменные окружения доступны службе;
папка проекта указана правильно;
права на файлы настроены;
логи можно быстро посмотреть;
база и конфиги попадают в резервную копию;
есть короткая инструкция по перезапуску.

Если эти пункты закрыты, Telegram-бот уже не зависит от открытой консоли и памяти администратора. Сервер может перезагрузиться, но бот поднимется сам и продолжит работу.

Именно в этом разница между тестовым скриптом и рабочим сервисом. Код может быть тем же самым, но способ запуска меняет всё: бот либо живёт только пока его вручную держат запущенным, либо становится нормальной частью серверной инфраструктуры.