Tracker.ru / Документация

TCP-мониторинг: проверка доступности портов (SSH, MySQL, Redis и др.)

4 мин чтения
Обновлено 12 мая 2026

TCP-мониторинг — это проверка доступности конкретного порта по TCP вместо отправки HTTP-запроса. Tracker.ru открывает TCP-соединение к указанной паре host:port и фиксирует факт успешного handshake. Если соединение не устанавливается — порт закрыт, сервис не слушает или сеть недоступна — URL переходит в down, отправляются уведомления.

В отличие от HTTP-мониторинга здесь нет ни статус-кода, ни тела ответа: мы получаем бинарный ответ «соединение прошло / не прошло». Это самый прямой способ убедиться, что фоновая база данных, очередь сообщений или SMTP-сервер действительно принимает входящие подключения.

Когда выбирать TCP вместо HTTP

TCP-мониторинг закрывает класс задач, для которых HTTP-проверка либо избыточна, либо в принципе не работает:

  • База данных не отдаёт HTTP. MySQL на 3306, PostgreSQL на 5432, Redis на 6379, MongoDB на 27017 — у них свои бинарные протоколы. HTTP-чек по этим портам всегда вернёт ошибку, TCP-чек скажет правду.
  • Очереди и брокеры. RabbitMQ (5672), NATS (4222) — те же соображения. Для health-чека нужно подтверждение, что брокер слушает порт.
  • gRPC и кастомные TCP-сервисы. Любой бинарный протокол поверх TCP проверяется именно так, без попытки распарсить HTTP-ответ.
  • Почтовые сервисы. SMTP (25, 587), IMAP (993), POP3 (995) — TCP-чек подтверждает, что почтовый сервер поднят и слушает соответствующий порт.
  • Доступность управляющих портов. SSH (22), FTP (21), DNS (53). Особенно полезно после миграций, обновлений firewall или замены инстансов в облаке.
  • Граничный сценарий: HTTPS и SSH рядом. Если один и тот же сервер обслуживает и веб (443), и SSH (22), TCP-чек по 22 — единственный способ заметить, что админский доступ потерян, пока сайт ещё отвечает.

Если речь идёт о публичном веб-сайте или REST API — оставайтесь на HTTP-мониторинге: он даёт больше информации (status, заголовки, опционально keyword в теле, скриншот).

Поддерживаемые порты

В UI и API поддерживаются 16 пресетов из Url::TCP_PRESETS — самые частые порты, для которых имеет смысл явное TCP-слежение. Любой из них можно выбрать одним кликом, либо ввести произвольный номер от 1 до 65535.

Порт Сервис
21 FTP
22 SSH
25 SMTP
53 DNS
80 HTTP
443 HTTPS
587 SMTP (TLS)
993 IMAP (SSL)
995 POP3 (SSL)
3306 MySQL
4222 NATS
5432 PostgreSQL
5672 RabbitMQ
6379 Redis
8080 HTTP Alt
27017 MongoDB

Порты 80, 443, 8080 присутствуют в списке намеренно: иногда нужен именно TCP-чек (например, проверить, что nginx слушает 443 после рестарта), без полноценного HTTP-запроса.

Как настроить

В личном кабинете нажмите «Добавить URL», переключите тип мониторинга на TCP. В форме появятся поля host и port — введите hostname без протокола (db.example.com) и порт. Период проверки и каналы уведомлений настраиваются так же, как для HTTP.

Через API:

curl -X POST https://tracker.ru/api/v1/urls \
  -H "Authorization: Bearer <api_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "db.example.com",
    "monitor_type": "tcp",
    "port": 3306,
    "period": 60,
    "notify_telegram": true
  }'

Поле port для TCP-мониторов обязательно (required|integer|min:1|max:65535); поле protocol — необязательно. Поля http_method и expected_keyword для TCP-типа игнорируются и должны передаваться null либо опускаться.

Тарифные лимиты работают так же, как для HTTP-мониторинга: TCP-чек считается обычным URL и тратит лимит max_urls тарифа. Минимальный период определяется тарифом.

Что проверяется

Чекер открывает TCP-соединение и ждёт завершения handshake. Возможны три исхода:

  • OK — handshake прошёл, соединение установлено. URL в статусе up.
  • tcp_refused — порт закрыт (получен RST или connection refused). Чаще всего означает, что сервис упал или не слушает порт.
  • timeout — handshake не уложился в таймаут (по умолчанию 60 секунд, регулируется через custom_timeout). Сетевая блокировка, проблема с маршрутизацией или сильно загруженный сервер.
  • host_not_found — DNS не разрешил hostname. Опечатка, удалённая DNS-запись или проблема с резолвером.

Каждый из этих кодов попадает в check_log.error_status и используется в формулировке уведомлений и в журнале URL.

Чем отличается от HTTP

TCP-мониторинг намеренно проще HTTP. Что не доступно для TCP-типа:

  • Нет HTTP-статуса. В уведомлении вместо «Status: 500» будет указана причина TCP-ошибки (tcp_refused, timeout, host_not_found).
  • Нет body. Соответственно, нет проверки ключевого слова — поле expected_keyword для TCP игнорируется.
  • Нет скриншотов. Скриншоты делает chromedp по HTTP-URL, у TCP-сервиса нет «страницы», которую можно отрисовать.
  • Нет SSL-валидации. TCP-handshake не вскрывает TLS-сертификат. SSL-проверки (срок действия, валидность цепочки) выполняются автоматически только для HTTP/HTTPS-чеков. Если нужно следить за сертификатом MySQL/Postgres, добавьте отдельный HTTPS-мониторинг публичного API того же сервера.

Зато TCP-чек:

  • Быстрее. Один SYN/SYN-ACK/ACK без отправки и парсинга HTTP.
  • Надёжнее для нестандартных протоколов. Не пытается интерпретировать ответ — нет ложных срабатываний из-за «не-HTTP» payload.
  • Дешевле для сервиса. Меньше нагрузка на проверяемый сервер, чем полноценный HTTP-запрос с заголовками.

Уведомления

TCP-мониторы используют те же каналы и шаблоны, что HTTP: Telegram, MAX, Email, Webhook. Формат алерта учитывает специфику TCP — в сообщении вместо HTTP-кода печатается код TCP-ошибки и текстовое описание:

Сайт недоступен! db.example.com:3306
Ошибка: TCP connection refused
Недоступен с 2026-05-01 19:15:09

Webhook-payload содержит поле error_status со значениями tcp_refused, timeout, host_not_found — это удобно для маршрутизации алертов в системах оркестрации (PagerDuty, Opsgenie). Окна обслуживания и уведомления о восстановлении работают идентично HTTP-мониторингу.

Связанные статьи