Как работает сайт: браузер превращает адрес в IP-адрес через DNS, открывает TCP-соединение с сервером, для HTTPS договаривается о шифровании по TLS, отправляет HTTP-запрос и получает ответ с кодом и HTML. Затем браузер дозапрашивает стили, скрипты и картинки и собирает из них страницу. Каждый шаг ломается по-своему и даёт свою ошибку.
Ниже — путь одного запроса по шагам, как его видит администратор: что происходит на каждом этапе, какой ошибкой браузер сообщает о сбое и какой командой это проверить самому. Если вы знаете, на каком шаге всё остановилось, вы знаете, кому писать: регистратору, хостеру, разработчику или своему провайдеру.
Как работает сайт простыми словами
Сайт — это набор файлов и программ на компьютере, который постоянно подключён к интернету и отвечает на запросы. Такой компьютер называют сервером, а место на нём обычно арендуют у хостинг-провайдера. Браузер на вашем телефоне или ноутбуке — клиент: он ничего не знает о сайте заранее, пока не спросит.
Чтобы спросить, браузеру нужны три вещи: адрес сервера в сети (IP-адрес), договорённость о языке общения (протокол HTTP) и, для сайтов с замком в адресной строке, защищённый канал (TLS). Доменное имя вроде example.ru — только удобная для человека подпись к IP-адресу. Всё, что вы видите на экране, браузер собирает сам из ответов сервера.
Отсюда простое правило диагностики: «сайт не работает» почти никогда не означает, что сломалось всё. Обычно отказал один шаг цепочки, и сообщение браузера подсказывает, какой именно.
Что происходит, когда вводишь адрес сайта: 7 шагов
| Шаг | Что происходит | Типичная ошибка в браузере | Чем проверить |
|---|---|---|---|
| 1. Разбор URL | Браузер выделяет протокол, домен, путь; проверяет HSTS | Поиск вместо перехода, если адрес написан с ошибкой | Адресная строка, DevTools |
| 2. DNS | Домен превращается в IP-адрес через резолвер | DNS_PROBE_FINISHED_NXDOMAIN, ERR_NAME_NOT_RESOLVED | nslookup, dig, /dns |
| 3. TCP | Трёхэтапное рукопожатие с сервером на порт 443 или 80 | ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_RESET | Test-NetConnection, nc, /ping, /traceroute |
| 4. TLS | Проверка сертификата и выбор ключей шифрования | NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID, ERR_SSL_PROTOCOL_ERROR | openssl s_client, /ssl |
| 5. HTTP | Запрос с заголовками, ответ с кодом состояния | Страницы с кодами 403, 404, 500, 502, 503, 504; ERR_TOO_MANY_REDIRECTS | curl -v, HTTP-заголовки, /redirects |
| 6. Рендер | Разбор HTML, загрузка CSS, JS, картинок, отрисовка | Белый экран, «съехавшая» вёрстка, ошибки в консоли | DevTools: Console и Network, /speed |
| 7. CDN и кэш | Ответ отдаёт ближайший узел или кэш браузера | Старая версия страницы, ошибки 52x у Cloudflare | Заголовки Age, Cache-Control |
Шаг 1. Браузер разбирает URL
Адрес https://example.ru/catalog?page=2 состоит из схемы (https), хоста (example.ru), пути (/catalog) и строки запроса (page=2). Если схема не указана, современные браузеры обычно пробуют HTTPS. Если домен есть в списке HSTS (сайт раньше прислал заголовок Strict-Transport-Security или внесён в предзагружаемый список браузера), переход на HTTP даже не выполняется: в DevTools это видно как внутренний редирект с кодом 307.
Если в строке набрано что-то, не похожее на адрес, браузер отправит текст в поисковик. Это первая точка, где «сайт не открывается» на деле означает опечатку.
Как работает DNS-сервер при открытии сайта
Компьютер соединяется только по IP-адресам, поэтому первым делом имя нужно перевести в адрес. Сначала браузер смотрит в свой кэш, затем в кэш операционной системы и файл hosts (в Windows — C:\Windows\System32\drivers\etc\hosts, в Linux и macOS — /etc/hosts). Если ответа нет, запрос уходит на рекурсивный резолвер — DNS-сервер провайдера, роутера или публичный вроде 1.1.1.1 и 8.8.8.8.
Рекурсивный резолвер, если сам не помнит ответ, проходит цепочку: корневые серверы подсказывают, кто отвечает за зону .ru, серверы зоны .ru называют NS-серверы домена, а авторитативный NS-сервер домена возвращает A-запись (IPv4) или AAAA-запись (IPv6). Каждый ответ резолвер кладёт в кэш на время TTL — число секунд, указанное в записи. Поэтому после смены IP часть посетителей ещё какое-то время попадает на старый сервер: их резолверы честно держат прежний ответ до истечения TTL. Подробнее об устройстве системы имён — в статье что такое DNS.
Проверить DNS можно так:
# Windows (cmd или PowerShell)
nslookup example.ru
nslookup example.ru 8.8.8.8
Resolve-DnsName example.ru -Type A
# Linux / macOS
dig example.ru A +short
dig example.ru @1.1.1.1
dig +trace example.ruВторой аргумент nslookup и @1.1.1.1 в dig задают конкретный резолвер. Если ваш резолвер отвечает иначе, чем публичный, дело в кэше или в подмене на стороне провайдера. dig +trace проходит цепочку от корня сам и показывает, на каком уровне ответ обрывается. В заголовке ответа dig смотрите на поле status: NOERROR — имя найдено, NXDOMAIN — такого имени нет, SERVFAIL — резолвер не смог получить ответ (частая причина — сломанный DNSSEC или недоступные NS-серверы).
В браузере сбой DNS выглядит как DNS_PROBE_FINISHED_NXDOMAIN или ERR_NAME_NOT_RESOLVED. Типичные причины: домен не продлён, у домена не прописаны NS-серверы, в зоне нет A-записи, опечатка в имени. Записи домена снаружи, без влияния вашего локального кэша, показывает проверка DNS. Локальный кэш сбрасывается командой ipconfig /flushdns в Windows, а кэш Chrome — на странице chrome://net-internals/#dns кнопкой Clear host cache.
Как узнать IP-адрес сайта
Те же команды отвечают на вопрос, где физически живёт сайт: nslookup example.ru выдаёт IP, а по IP уже можно понять хостера или CDN. Если домен смотрит на CDN, вы увидите адрес узла сети доставки, а не настоящего сервера — это нормально и сделано намеренно.
Как работает адрес сайта и как его сделать
Чтобы у сайта появился адрес, домен регистрируют у регистратора, указывают для него NS-серверы (обычно хостера или DNS-провайдера) и в зоне домена создают A-запись с IP сервера. После этого любой резолвер в мире сможет пройти описанную выше цепочку. Адрес без A-записи существует, но никуда не ведёт.
Как работает клиент-сервер: TCP-соединение
Получив IP, браузер открывает TCP-соединение. Это трёхэтапное рукопожатие: клиент отправляет пакет SYN, сервер отвечает SYN-ACK, клиент подтверждает ACK. Для HTTPS стандартный порт — 443, для HTTP — 80. Только после рукопожатия по соединению можно передавать данные.
Здесь же видна суть модели «клиент — сервер»: клиент всегда начинает разговор, сервер слушает порт и отвечает. Сервер не может сам «прислать» страницу браузеру, который его не спрашивал; даже живые обновления (чаты, уведомления) работают через соединение, которое открыл клиент.
Что может сломаться и как это выглядит:
- ERR_CONNECTION_REFUSED — сервер доступен, но на порту никто не слушает: веб-сервер остановлен или порт закрыт, и сервер вернул отказ (RST).
- ERR_CONNECTION_TIMED_OUT — ответа нет вообще: пакеты теряются по пути, их молча отбрасывает файрвол, или сервер выключен.
- ERR_CONNECTION_RESET — соединение оборвали посередине: сервер, балансировщик или промежуточное оборудование.
Проверка доступности порта:
# Windows PowerShell
Test-NetConnection example.ru -Port 443
# Linux / macOS
nc -vz example.ru 443
# Путь до сервера
tracert example.ru # Windows
traceroute example.ru # Linux / macOS
mtr -rw example.ru # Linux, отчёт по каждому узлуВ выводе Test-NetConnection важна строка TcpTestSucceeded: True значит, что порт открыт. Учтите, что многие серверы и сети не отвечают на ping (ICMP), поэтому молчащий ping ещё не доказывает, что сайт лежит. Задержку и потери пакетов со стороны покажет проверка пинга, а участок, где маршрут обрывается, — трассировка.
Как работает HTTPS на сайтах: TLS-рукопожатие
Если адрес начинается с https, поверх TCP запускается TLS. Браузер сообщает, какие версии протокола и наборы шифров он поддерживает, и передаёт имя сайта в расширении SNI — так сервер, на котором живут сотни доменов, понимает, какой сертификат отдать. Сервер присылает сертификат и цепочку промежуточных сертификатов, стороны вырабатывают общий ключ, после чего весь обмен шифруется. В TLS 1.3 рукопожатие занимает один обмен сообщениями туда и обратно, в TLS 1.2 — два. Как это устроено по сообщениям, разобрано в статье про TLS-рукопожатие; сам протокол описан в RFC 8446.
Браузер проверяет сертификат по трём пунктам: срок действия не истёк, имя в сертификате совпадает с доменом, цепочка ведёт к корневому центру сертификации, которому доверяет система. Нарушение каждого пункта даёт свою ошибку:
NET::ERR_CERT_DATE_INVALID— сертификат просрочен или часы на устройстве пользователя сбиты;NET::ERR_CERT_COMMON_NAME_INVALID— сертификат выдан на другое имя, например только наexample.ru, а открываютwww.example.ru;NET::ERR_CERT_AUTHORITY_INVALID— самоподписанный сертификат, неполная цепочка или корень, которого нет в хранилище устройства;ERR_SSL_PROTOCOL_ERRORиERR_SSL_VERSION_OR_CIPHER_MISMATCH— клиент и сервер не договорились о версии или шифре.
Посмотреть сертификат вручную:
openssl s_client -connect example.ru:443 -servername example.ru </dev/null
openssl s_client -connect example.ru:443 -servername example.ru </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -datesВ конце вывода первой команды ищите строку Verify return code: 0 (ok); любой другой код объясняет, что не так с цепочкой. Вторая команда печатает владельца, издателя и даты действия. Флаг -servername обязателен для серверов с несколькими сайтами: без него вы можете получить сертификат соседнего домена. Со стороны сертификат, цепочку и срок покажет проверка SSL.
Как работает сервер сайта: HTTP-запрос и ответ
Когда канал готов, браузер отправляет HTTP-запрос. В HTTP/1.1 он выглядит как текст: строка запроса и заголовки.
GET /catalog?page=2 HTTP/1.1
Host: example.ru
User-Agent: Mozilla/5.0 ...
Accept: text/html
Accept-Encoding: gzip, br
Cookie: session=...Заголовок Host говорит серверу, какой из сайтов на этом IP нужен. Дальше запрос обычно принимает веб-сервер (nginx или Apache). Статический файл — картинку, CSS — он отдаёт с диска сам. Динамическую страницу передаёт приложению: PHP-FPM, Node.js, Python, которое читает данные из базы, собирает HTML и возвращает его веб-серверу. Часто перед всем этим стоит обратный прокси или балансировщик, который распределяет запросы между несколькими серверами.
Ответ начинается со строки состояния с кодом, затем идут заголовки и тело:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Set-Cookie: session=...; HttpOnly; Secure
Content-Encoding: brКод состояния — главное, что стоит проверить при сбое. 2xx — успех, 3xx — перенаправление (адрес в заголовке Location), 4xx — ошибка на стороне запроса (403 — доступ запрещён, 404 — страницы нет), 5xx — ошибка сервера (500 — сбой приложения, 502 и 504 — прокси не получил нормального ответа от приложения, 503 — сервис временно недоступен). Полный список кодов собран в справочнике кодов ответа сервера, а смысл каждого заголовка — в разборе HTTP-заголовков. Формально HTTP определён в RFC 9110.
Весь диалог можно увидеть одной командой:
curl -v https://example.ru/ -o /dev/null
curl -I https://example.ru/
curl -sL -o /dev/null -w "%{http_code} %{url_effective}\n" http://example.ru/В выводе curl -v строки со звёздочкой — служебная информация (подключение, TLS), строки с > — что отправил клиент, строки с < — что ответил сервер. -I запрашивает только заголовки, а последняя команда проходит по всем редиректам (-L) и печатает итоговый код и конечный адрес. В Windows 10 и 11 используйте curl.exe: в старом Windows PowerShell слово curl — псевдоним другой команды. Ответ сервера снаружи показывают проверка HTTP-заголовков и проверка редиректов; последняя полезна, когда браузер пишет ERR_TOO_MANY_REDIRECTS — сайт перенаправляет сам на себя по кругу.
Протокол HTTP не хранит состояние
Каждый запрос для сервера независим: сам по себе HTTP не помнит, что вы вошли в личный кабинет минуту назад. Эту связь создают cookies — сервер присылает Set-Cookie, браузер возвращает значение в заголовке Cookie с каждым следующим запросом. Поэтому «разлогинивает» чаще всего не сервер, а потерянная или заблокированная cookie.
Как браузер собирает страницу
Получив HTML, браузер начинает его разбирать и строит дерево документа (DOM). Встретив ссылки на стили, скрипты и картинки, он запрашивает их отдельно — часто это десятки дополнительных запросов, в том числе к другим доменам (шрифты, счётчики, CDN). Для каждого нового домена повторяются шаги 2–4: DNS, TCP, TLS. В HTTP/2 и HTTP/3 много файлов с одного домена идут по одному соединению параллельно, в HTTP/1.1 браузер открывает несколько соединений.
Из CSS строится модель стилей, вместе с DOM она даёт дерево отрисовки; затем браузер рассчитывает положение элементов (layout) и рисует их (paint). Обычный <script> без атрибутов async или defer останавливает разбор HTML, пока скрипт не загрузится и не выполнится, — это частая причина медленного первого показа.
Сбои этого шага сервер обычно не видит: он честно ответил 200, а пользователь видит белый экран. Откройте DevTools клавишей F12: во вкладке Console будут ошибки JavaScript, во вкладке Network — какие файлы не загрузились и с каким кодом. Сколько времени занимает загрузка и отрисовка, покажет проверка скорости.
Разложить время ответа по этапам можно и через curl:
curl -o /dev/null -s -w "dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n" https://example.ru/Значения накопительные, в секундах от начала запроса. Если большой разрыв между tls и ttfb, медленно работает само приложение или база данных, а не сеть.
CDN и кэш: почему сайт отвечает не с сервера
Многие сайты стоят за CDN — сетью серверов, расположенных ближе к пользователям. DNS такого домена указывает на узел CDN; узел отдаёт сохранённую копию или, если её нет, идёт за страницей на основной сервер (origin). Дополнительно файлы хранит браузер, если сервер разрешил это заголовком Cache-Control.
Отсюда два класса проблем. Первый: после обновления сайта посетители видят старую версию — копия ещё живёт в кэше CDN или браузера. Заголовок Age показывает, сколько секунд ответ пролежал в кэше, а у Cloudflare заголовок CF-Cache-Status сообщает HIT или MISS. Второй: CDN работает, а основной сервер — нет. Тогда ошибку рисует сама сеть доставки; у Cloudflare это коды 52x, например 521 (сервер отказал в соединении), 522 (сервер не ответил вовремя), 525 (не удалось TLS-рукопожатие с сервером).
Статический и динамический сайт: в чём разница для сервера
| Статический сайт | Динамический сайт | |
|---|---|---|
| Что отдаёт сервер | Готовые HTML-файлы с диска | HTML, собранный приложением на каждый запрос |
| Кто участвует | Веб-сервер или CDN | Веб-сервер, приложение, база данных, иногда очередь и кэш |
| Типичные сбои | DNS, сертификат, 404 после переноса | Всё то же плюс 500, 502, 504, медленный ответ базы |
| Примеры | Лендинг, документация | Интернет-магазин, личный кабинет, CMS |
На каком сервере и у какого провайдера размещать проект, зависит от этого типа; основы аренды сервера разобраны в статье что такое хостинг.
Как проверить, на каком шаге ломается сайт
Идите по цепочке сверху вниз и останавливайтесь на первом шаге, который не прошёл:
- Имя резолвится?
nslookup example.ru 8.8.8.8. Нет ответа — проблема в домене или DNS. Записи снаружи смотрите в проверке DNS. - Порт открыт?
Test-NetConnection example.ru -Port 443илиnc -vz example.ru 443. Отказ или таймаут — сервер, файрвол или сеть. - Сертификат валиден?
openssl s_clientс-servernameили проверка SSL. - Какой код отвечает сервер?
curl -Iили проверка HTTP-заголовков. 5xx — смотреть логи веб-сервера и приложения. - Код 200, а страница пустая — DevTools, вкладки Console и Network.
Если с вашего компьютера сайт не открывается, а внешние проверки проходят, проблема на вашей стороне: локальный DNS-кэш, файл hosts, расширение браузера, сеть провайдера или корпоративный файрвол.
Частые вопросы
Как работает интернет-сайт без собственного сервера?
Сервер всё равно есть, просто он чужой: хостер, облако или конструктор сайтов держат ваши файлы на своих машинах и отвечают на запросы за вас. Цепочка DNS — TCP — TLS — HTTP остаётся той же.
Почему сайт открывается у меня, но не у других?
Чаще всего из-за DNS-кэша после смены IP: ваш резолвер уже получил новый адрес, чужие ещё держат старый до истечения TTL. Сравните ответы разных резолверов через nslookup имя 8.8.8.8 и nslookup имя 1.1.1.1.
Что быстрее отвечает — HTTP или HTTPS?
HTTPS добавляет TLS-рукопожатие, но в TLS 1.3 это один обмен сообщениями, а HTTP/2 и HTTP/3 браузеры используют только поверх шифрования. На практике разница в скорости определяется сервером и сетью, а не наличием HTTPS.
Что значит «сервер не отвечает», если ping проходит?
Ping проверяет только, что узел отвечает на ICMP. Веб-сервер на порту 443 при этом может быть остановлен — тогда браузер покажет ERR_CONNECTION_REFUSED. Проверяйте именно порт, а не ping.
Где посмотреть, что сайт отправил браузеру?
В DevTools (F12), вкладка Network: выберите запрос, там будут заголовки запроса и ответа, код и время по этапам. Из командной строки то же покажет curl -v.
