Как открывается сайт: DNS → TCP → TLS → HTTP

Когда человек вводит адрес сайта и нажимает Enter, кажется, будто браузер просто «подключился к сайту». На самом деле за доли секунды происходит целая цепочка: DNS, соединение с сервером, TLS и только потом HTTP.

Если понимать эту последовательность, искать причину недоступности становится намного проще.

Шаг 1. URL

Браузер получает адрес:

https://example.com/page

Из него важны:

• схема HTTPS;
• hostname example.com;
• путь /page.

Шаг 2. DNS

Сначала нужно понять, на какой IP подключаться.

example.com
↓ DNS
203.0.113.25

Если DNS не работает, до HTTP браузер вообще не дойдёт.

Шаг 3. Выбор IPv4 или IPv6

У домена могут существовать A и AAAA.

A    → IPv4
AAAA → IPv6

Из-за неправильной AAAA часть пользователей может иметь проблему, даже когда IPv4 полностью исправен.

Шаг 4. Сетевой маршрут

Пакеты должны дойти до нужного IP через сеть провайдера и интернет-маршрутизацию.

Проблема здесь уже не является DNS-ошибкой.

Шаг 5. TCP

Для обычного HTTPS браузер должен установить транспортное соединение с портом 443.

Упрощённо:

клиент → SYN
сервер → SYN/ACK
клиент → ACK

Что ломается на TCP-уровне

• порт закрыт;
• firewall блокирует соединение;
• сервер не слушает порт;
• маршрут нарушен;
• адрес указан неправильно.

Шаг 6. TLS

Для HTTPS после установления соединения начинается TLS-handshake.

Клиент и сервер договариваются о защищённом соединении, а сервер показывает сертификат.

На этом этапе проверяется сертификат

Браузер смотрит в том числе:

• срок действия;
• соответствие домену;
• цепочку доверия;
• поддерживаемую версию TLS.

Шаг 7. HTTP

Только после предыдущих уровней браузер отправляет запрос примерно такого смысла:

GET /page HTTP/2
Host: example.com

Шаг 8. Серверное приложение

Nginx или другой frontend может передать запрос дальше:

браузер
↓
nginx
↓
PHP / Node.js / Python / другое приложение
↓
база данных

Поэтому 502 — это уже не DNS

Домен может прекрасно разрешаться, TCP и TLS работать, но backend за nginx упал. Тогда пользователь получает 502.

А 504?

Frontend подключился к backend, но не дождался ответа вовремя.

Как понять, где проблема

Идите в том же порядке, в котором работает соединение:

1. DNS.
2. IP.
3. маршрут.
4. порт.
5. TLS.
6. HTTP.
7. приложение.

Проверка DNS

dig example.com A
dig example.com AAAA

Проверка соединения

curl -v https://example.com/

Verbose-режим curl показывает гораздо больше, чем просто конечную страницу.

Проверка конкретного IP

curl --resolve example.com:443:203.0.113.25 https://example.com/

Это позволяет временно проверить сервер, не меняя публичный DNS.

Проверка TLS

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

Почему ping недостаточно

Ping проверяет ICMP и не доказывает, что HTTPS работает.

Сервер может игнорировать ping и при этом прекрасно отдавать сайт.

Как NexIP помогает

Смысл набора инструментов NexIP именно в том, чтобы не смотреть на сайт как на чёрный ящик. DNS, SSL, HTTP-заголовки, IP и доступность — разные уровни одной цепочки.

FAQ

Если DNS работает, сайт обязан открываться?

Нет. DNS — только первый этап.

Если ping идёт, сайт исправен?

Нет.

Почему полезно проверять уровни по порядку?

Так вы не тратите время на SSL, когда домен вообще указывает не туда, или на DNS, когда ошибка уже очевидно находится в backend.