SSD Nodes Learn Hosting plans →
Руководства Matt ConnorАвтор: Matt Connor · Обновлено 2026-08-07

Выбор VPS для торгового бота: технические требования

Узнайте, почему для торговых ботов важны не рекламные цифры аптайма, а настройка systemd, синхронизация времени через NTP и защита API ключей. Разбор реальных критериев выбора.

Требования к VPS для торгового бота

VPS для торговых ботов оценивается по четырем критериям: восстанавливается ли процесс после сбоя, точны ли системные часы, насколько сложно похитить API (application programming interface) ключи и получаете ли вы уведомление при остановке бота. Для розничного бота чистая вычислительная мощность стоит далеко не на первом месте, так как узким местом в цепочке исполнения ордера является брокер и расстояние до него, а не хост, на котором выполняется ваш Python-код.

Это инженерное руководство. Данный текст не является финансовой консультацией, стратегии здесь не обсуждаются.

Uptime — это дисциплина перезапуска, а не цифра в рекламном буклете

Каждый хост в мире заявляет о 99.9 процентах аптайма. Эта цифра описывает гипервизор, а не вашего бота. Бот может завершиться из-за необработанного исключения, websocket, который не восстанавливает соединение, или OOM (out of memory) killer, в то время как сервер продолжает работать. Поэтому полезный вопрос заключается в том, что происходит в течение десяти секунд после завершения вашего процесса.

Запускайте бота как systemd service и позвольте системе инициализации управлять перезапуском. Unit-файл делает это в шесть строк.

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 — это строка, которую часто упускают. По умолчанию systemd прекращает попытки после 5 перезапусков за 10 секунд и оставляет юнит в состоянии failed навсегда, что совершенно нежелательно в 03:00. Установка значения 0 отключает ограничение частоты, поэтому бот, попавший в цикл сбоев, будет продолжать попытки вместо того, чтобы замолчать. RestartSec=10 предотвращает ситуацию, когда этот цикл перегружает биржу запросами на переподключение.

Проверьте файл, прежде чем доверять ему, а затем запустите его:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable — это половина успеха, которая переживёт перезагрузку, а обновления ядра означают перезагрузки. Чтобы узнать, не умирал ли бот незаметно, запросите у systemd счётчик перезапусков:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

NRestarts=0 через неделю — признак здорового бота. NRestarts=812 означает, что вы торговали на процессе, который всю ночь занимался переподключением. Полная структура unit-файла, включая таймеры для запланированных задач, таких как ежедневный отчёт, описана в запуске программы как systemd service.

Установка часового пояса UTC и проверка синхронизации времени

API бирж подписывают запросы временной меткой и отклоняют любые данные, выходящие за пределы заданного окна, которое часто составляет 5 секунд или меньше. Смещение времени приводит к ошибкам, которые выглядят как проблемы с аутентификацией, поэтому пользователи могут часами менять ключи, прежде чем проверят настройки времени. В API типа Binance сообщение об ошибке звучит буквально: Timestamp for this request was 1000ms ahead of the server's time.

Установите на сервере часовой пояс UTC. Локальные часовые пояса вводят переход на летнее время, который может произойти прямо во время торговой сессии.

sudo timedatectl set-timezone UTC
timedatectl

В Ubuntu по умолчанию используется systemd-timesyncd — клиент SNTP (simple network time protocol). Он подходит для логов, но недостаточно точен для задач, требующих синхронизации с точностью до нескольких миллисекунд, так как он опрашивает один сервер и не корректирует ход часов непрерывно. Вместо него используйте chrony:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

Строка, которую нужно отслеживать в chronyc tracking, — это System time, например System time : 0.000031415 seconds fast of NTP time. Любое значение менее нескольких миллисекунд считается нормальным. Если отображается Leap status : Not synchronised, значит, chrony еще не связался с сервером; обычно это происходит из-за блокировки исходящего трафика по протоколу UDP на порту 123. Подождите минуту и проверьте снова, прежде чем менять правила межсетевого экрана.

Храните API-ключи отдельно от мест, которые вы копируете

Утечка ключа биржи опаснее утечки SSH-ключа, так как наличие прав на вывод средств позволяет мгновенно превратить его в деньги. Две привычки позволяют минимизировать большинство рисков.

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

Во-вторых, храните секретные данные вне директории с кодом. Всё, что находится внутри /opt/tradingbot, рано или поздно попадёт в git-репозиторий или архив резервных копий. Поместите ключ в файл, принадлежащий root, который читает только systemd:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

Файл содержит обычные строки KEY=value без кавычек и без export. Права доступа 640 с группой bot означают, что сервис может прочитать файл, а никто другой — нет. Проверьте это с помощью sudo -u bot cat /etc/tradingbot/api.env, а затем попробуйте сделать то же самое от имени другого пользователя: операция должна завершиться с ошибкой Permission denied.

Сам бот не должен работать от имени root или вашего обычного пользователя. Создайте системную учётную запись без доступа к оболочке (shell) и без домашней директории:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

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

Обнаружение сбоя до того, как его заметит брокер

systemctl status сообщает, что процесс запущен. Это не означает, что бот выполняет какие-либо действия. Процесс, застрявший в цикле повторных попыток подключения к неработающему websocket, проходит все проверки, которые может выполнить systemd.

Используйте heartbeat. В Uptime Kuma есть push-мониторы: они ожидают, что ваш бот будет обращаться по URL согласно расписанию, и отправляют оповещение, если запросы перестают поступать. Разместите вызов в конце основного цикла, после того этапа, который подтверждает работоспособность бота, например, после успешного чтения рыночных данных.

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Установите интервал мониторинга примерно в два раза больше времени выполнения цикла, чтобы обычные задержки не вызывали ложных срабатываний. Запускайте монитор на другом сервере, отличном от того, где работает бот, так как монитор, вышедший из строя вместе с наблюдаемым объектом, не сообщит ни о чём. Настройка описана в самостоятельном развертывании мониторинга состояния с помощью Uptime Kuma.

Добавьте также оповещение о заполнении диска. Бот, записывающий подробные логи, за несколько недель заполнит корневую файловую систему. Переполненный диск останавливает запись в базу данных, а не сетевые вызовы, поэтому симптомы могут быть неочевидными. journalctl --vacuum-time=14d и строка SystemMaxUse= в /etc/systemd/journald.conf позволяют ограничить размер журнала.

Честный взгляд: задержки зависят в основном не от вашего хоста

На этом этапе рынок VPS для трейдинга перестает быть техническим. Маркетинговые страницы обещают задержки менее миллисекунды и намекают, что именно хост отделяет вас от исполнения ордера. Для почти любого розничного торгового бота это не так.

Ваш ордер следует от бота до конечной точки биржи или брокера через публичный интернет. На этом пути доминируют физическое расстояние и пиринг между вашим провайдером и провайдером биржи. Сервер во Франкфурте, обменивающийся данными с узлом в Токио, будет иметь задержку около 250 миллисекунд в обе стороны, независимо от скорости процессора. Затем собственные системы брокера добавляют свою очередь, проверки рисков и лимиты по частоте запросов, которые для розничного счета обычно измеряются десятками или сотнями миллисекунд.

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

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

Запустите это с потенциального сервера перед тем, как принимать решение. Если connect составляет 0.180 секунды, вы находитесь не на том континенте, и это стоит исправить. Если connect составляет 0.004 секунды, а ttfb — 0.140 секунды, то оставшаяся задержка приходится на обработку брокером, и смена хоста на нее не повлияет.

Так когда же хост имеет значение? Когда вы размещаете оборудование в одном дата-центре с биржей (colocation) или имеете прямое соединение с площадкой и конкурируете за позицию в очереди — это другой бизнес с другим бюджетом. И когда узким местом является ваш собственный код: бот, который пересчитывает индикаторы по всей истории на каждом тике, может тратить 200 миллисекунд процессорного времени на цикл, что является реальной задержкой, которую вы можете устранить бесплатно. Профилируйте цикл перед тем, как искать более быстрый сервер.

Что действительно важно при выборе хоста, так это география, стабильная сеть и достаточный объем памяти, чтобы OOM killer никогда не вмешивался в работу. По состоянию на июль 2026 года Python-бот с одной стратегией и несколькими сотнями символов в памяти комфортно работает на 2 GB RAM и 2 vCPU. Добавьте памяти, если вы храните историю тиков в локальной базе данных.

Краткий контрольный список перед запуском

  1. systemctl is-enabled tradingbot выводит enabled, и сервис продолжает работу после sudo reboot.
  2. chronyc tracking показывает смещение системного времени менее чем на несколько миллисекунд.
  3. API-ключ имеет разрешение на торговлю, не имеет разрешения на вывод средств и ограничен списком разрешённых IP-адресов, если биржа предоставляет такую возможность.
  4. Завершение процесса командой sudo systemctl kill -s SIGKILL tradingbot приводит к его автоматическому перезапуску в течение RestartSec.
  5. Система мониторинга heartbeat отправляет уведомление в течение одного интервала, если вы намеренно останавливаете бота.
  6. Размер логов ограничен, а в корневой файловой системе есть свободное место в df -h.

Запустите всё в песочнице биржи или в режиме paper trading на одну неделю перед использованием реальных средств. Каждый из пунктов выше обязательно даст сбой хотя бы раз за эту неделю — в этом и заключается смысл тестового периода.

FAQ

Нужен ли торговому боту сервер с низкой задержкой или bare metal?

Только если вы конкурируете по скорости исполнения с другими автоматизированными участниками на той же площадке. Обычно это означает размещение оборудования в одном дата-центре (colocation), а не использование обычного VPS. Для розничного бота время прохождения сигнала (round trip) определяется географией и скоростью обработки запросов самим брокером. Выбирайте сервер, расположенный ближе к API-эндпоинту, и проводите замеры с помощью curl и mtr, прежде чем платить за более дорогое оборудование.

Сколько RAM и CPU нужно торговому боту?

Большинство ботов, работающих по одной стратегии, ограничены пропускной способностью сети и простаивают между событиями. По состоянию на июль 2026 года, 2 vCPU и 2 GB RAM достаточно для Python-бота, отслеживающего несколько сотен инструментов. Память становится критическим ресурсом, если вы храните историю тиков в оперативной памяти или используете локальную базу данных. Следите за free -h и системным журналом на предмет сообщений об OOM kill, вместо того чтобы гадать.

Почему API биржи отклоняет запросы с ошибкой временной метки?

Системные часы сервера рассинхронизировались и вышли за пределы окна подписи биржи, которое обычно составляет несколько секунд. Установите chrony, убедитесь, что chronyc tracking показывает небольшое смещение System time и статус синхронизации, а также установите на машине часовой пояс UTC, чтобы переход на летнее время не вызывал сдвигов. Смена API-ключа не решает проблему с часами.

Как предотвратить внезапную остановку бота ночью?

Запустите его через systemd с параметрами Restart=always и StartLimitIntervalSec=0, чтобы цикл перезапуска продолжал попытки вместо окончательной остановки. Добавьте механизм heartbeat, который бот отправляет в конце каждого успешного цикла. Перезапуск обеспечивает работу процесса, а heartbeat помогает обнаружить ситуацию, когда процесс запущен, но завис.

Можно ли запускать бота и систему мониторинга на одном VPS?

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