03 / Сеть

Как искать сетевой сбой

Последовательная проверка DNS, TCP и TLS помогает найти проблему без случайных изменений конфигурации.

Практическая заметка6 минут чтения

Сначала определите точку отказа

Фраза «сайт не открывается» описывает симптом, но не причину. Имя может не разрешаться в IP, TCP-порт может быть закрыт, сертификат — неверным, а приложение — отвечать ошибкой. Проверяйте слои по порядку.

1. DNS

dig +short A example.com
dig +short AAAA example.com

Сравните возвращённые адреса с ожидаемыми. Если IPv6-запись опубликована, но сервер недоступен по IPv6, часть клиентов будет получать ошибки.

2. Слушающий сокет

sudo ss -lntp | grep ':443'

Важно увидеть не только номер порта, но и адрес привязки. 127.0.0.1:443 доступен только локально, тогда как 0.0.0.0:443 слушает все IPv4-интерфейсы.

3. Доступность HTTPS

curl -Iv --connect-timeout 5 \
  https://example.com/

Здесь видно, состоялось ли TLS-соединение, какой сертификат предъявил сервер и какой HTTP-ответ он вернул.

4. SNI и сертификат

openssl s_client \
  -connect example.com:443 \
  -servername example.com 

Для сервера с несколькими доменами SNI особенно важен: маршрутизатор может направлять запросы к разным приложениям по имени из ClientHello.

Не делайте вывод о доступности сервиса только по строке «container Up». Контейнер может работать, а маршрут до него или TLS-настройка — нет.

5. Журналы и границы

Если сеть и TLS исправны, переходите к журналам приложения. Для Docker начните с docker compose ps и docker compose logs --tail=100. Записывайте, что именно прошло проверку, чтобы не повторять её по кругу.

← Вернуться ко всем статьям