Путь запроса: от имени до ответа

Четыре шага, на каждом из которых всё может сломаться по-своему.

Четыре шага

Между вводом адреса и ответом происходит следующее:

DNS — имя превращается в IP-адрес.
TCP — устанавливается соединение с этим адресом на нужный порт.
TLS — для https стороны договариваются о шифровании, сервер предъявляет сертификат.
HTTP — уходит запрос, приходит ответ.

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

Проверять по шагам

dig +short devoops.uz            # шаг 1: имя резолвится?
nc -vz devoops.uz 443            # шаг 2: порт открыт?
openssl s_client -connect devoops.uz:443 -servername devoops.uz   # шаг 3
curl -v https://devoops.uz/      # шаг 4 целиком

Ошибка на первом шаге — это NXDOMAIN или пустой ответ dig. Проблема в DNS-записях, приложение здесь ни при чём.

Refused против timeout

Различие, которое экономит больше всего времени:

Connection refused — пакет дошёл, хост ответил отказом: на этом порту никто не слушает. Сеть исправна. Смотрите сервис: запущен ли, на каком адресе слушает.

ss -tlnp | grep 8080

Частая причина — сервис слушает 127.0.0.1 вместо 0.0.0.0 и потому доступен только локально.

Connection timeout — ответа не было вовсе. Пакет отбросили молча: firewall с политикой DROP, security group в облаке, отсутствующий маршрут. Смотрите сеть между вами и хостом, а не сам сервис.

Кеш DNS

Ответ DNS кешируется — резолвером, системой, иногда самим приложением. Поэтому после смены записи «у всех работает, а у меня нет» может длиться часами.

dig devoops.uz +noall +answer     # смотрим TTL
dig @8.8.8.8 devoops.uz +short    # в обход локального кеша

Если ответ от публичного резолвера отличается от локального — вы смотрите на кеш, а не на реальность.

Что смотреть в curl -v

curl -v https://devoops.uz/ 2>&1 | head -20

Строки с * — это шаги установки соединения: резолв, TCP, TLS. Строки с > — ваш запрос, с < — ответ. Место, где вывод обрывается, и есть сломавшийся шаг.