«Сайт не открывается» — самая бесполезная формулировка проблемы и самая частая. За ней может стоять что угодно: от забытой записи DNS до упавшего PHP, от фильтра на пути до истёкшего сертификата. Хорошая новость: после одиннадцати частей мы знаем все шаги запроса, а значит, можем проверять их по очереди, снизу вверх, и на каждом получать ответ «да» или «нет». Это заключительная часть — чек-лист с командами.

Это двенадцатая, заключительная часть цикла «Что происходит, когда открываешь сайт».

Правило номер ноль: проверить с другой точки

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

Если у вас есть доступ к серверу — второй быстрый вопрос: идёт ли туда сейчас живой трафик. Сотни запросов в минуту от чужих посетителей в журнале — и вопрос «лежит ли сервер» снят.

Уровень 1. DNS: правильный ли адрес

dig example.ru A +short                       # что отвечает ваш резолвер
dig example.ru A +short @1.1.1.1              # что отвечает публичный
dig +trace +nodnssec example.ru A | tail -4   # что отвечают серверы домена
  • пусто или NXDOMAIN — записи нет или домен не делегирован;
  • SERVFAIL — зона не обслуживается теми серверами, на которые делегирована;
  • адреса разные у разных резолверов — недавно меняли запись, ждите TTL;
  • не забудьте AAAA: устаревший IPv6-адрес ломает сайт «только у некоторых».

Подробно — во второй и третьей частях.

Уровень 2. Маршрут: доходят ли пакеты

mtr -n -r -c 10 example.ru     # потери и задержка по узлам; смотреть на ПОСЛЕДНЮЮ строку
ping -c 5 example.ru           # грубо; многие серверы ICMP режут — молчание не приговор

Потери, которые начинаются на каком-то узле и тянутся до конца, — настоящие. «???» и потери на одном узле посередине — нет. Подробно — в четвёртой части.

Уровень 3. TCP: открывается ли соединение

nc -vz -w 5 example.ru 443                    # Linux / macOS
Test-NetConnection example.ru -Port 443       # Windows PowerShell
curl -so /dev/null -w 'tcp=%{time_connect}\n' --connect-timeout 5 https://example.ru/
  • отказ сразу (refused) — пакет дошёл, но порт никто не слушает: упал прокси или веб-сервер;
  • таймаут — пакет не доходит или ответ не возвращается: фильтр, бан, проблема на пути;
  • сравните порты: если 80 открывается, а 443 нет на тот же адрес — виноват путь, а не сервер. Один процесс прокси не умеет сломать 443 и оставить 80;
  • с самого сервера всё работает, снаружи таймаут — первым делом проверьте баны: iptables -S | grep f2b.

Уровень 4. TLS: договорились ли о шифровании

echo | openssl s_client -connect example.ru:443 -servername example.ru 2>&1 \
  | grep -E 'Verify return code|subject=|NotAfter|Protocol'
curl -sv -o /dev/null https://example.ru/ 2>&1 | grep -E '^\* (TLS|SSL|ALPN|subject|expire)'
  • Verify return code не 0 — проблема с сертификатом: истёк, не то имя, неполная цепочка;
  • браузер работает, а скрипты и интеграции падают — почти всегда неполная цепочка (восьмая часть);
  • соединение рвётся на приветствии, а openssl проходит — смотрите, не режется ли конкретный вид рукопожатия на пути; проверка с другой сети это покажет;
  • не проверяйте HTTPS по голому IP: без имени (SNI) прокси не знает, какой сертификат показать. Нужен curl --resolve example.ru:443:203.0.113.22 https://example.ru/.

Уровень 5. HTTP: что ответил сервер

curl -sI https://example.ru/                       # код и заголовки
curl -s -o /dev/null -w '%{http_code} %{time_starttransfer}\n' https://example.ru/
КодГде искать
301/302 по кругупереадресация сама на себя: http ↔ https, www ↔ без www
403правило защиты, бан по адресу, права на файлы
404 на всёне тот сайт отвечает: прокси не нашёл маршрут для имени
502прокси не получил ответ: упал PHP, приложение, контейнер
504 / очень долгий ответзависший запрос: внешний вызов без таймаута, блокировка в базе
200, но страница пустаяфатальная ошибка PHP с выключенным выводом — смотрите журнал PHP

Разбор кодов и заголовков — в десятой части.

Уровень 6. Браузер: что он не смог догрузить

Если HTML пришёл, а страница «кривая» или пустая — открывайте инструменты разработчика: вкладка Network (что не загрузилось и с каким кодом) и Console (ошибки скриптов). Частые причины: заблокирован сторонний домен, смешанное содержимое (HTTP-ресурс на HTTPS-странице), скрипт упал раньше, чем дорисовал блок.

Одна команда на все уровни

Для первого взгляда хватит одной строки — она покажет, на каком шаге остановилось время:

curl -so /dev/null --connect-timeout 10 -m 20 -w \
 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code} ip=%{remote_ip}\n' \
 https://example.ru/
  • dns долгий или ошибка резолва — уровень 1;
  • tcp = 0 и таймаут — уровни 2–3;
  • tls = 0 при живом tcp — уровень 4;
  • ttfb огромный — сервер (уровень 5);
  • code не 200 — читайте таблицу выше.

Чему научил цикл

Путь одного запроса — это шесть независимых шагов, и у каждого свой способ сломаться и своя команда проверки. Пройдя их по порядку, вы почти всегда за пять минут ответите на вопрос, который без этого превращается в вечер гаданий: где именно сломалось — у вас, на пути или на сервере. А когда всё работает, те же команды показывают, куда уходит время, — и почти всегда оказывается, что не в сеть.

Сайт не открывается, и непонятно почему?

Пришлите адрес и что видите — пройду по уровням и найду, на каком шаге обрывается.

· полезно?
АЧ
Алексей Чикун веб-разработчик, команда TRIOHEAD

Делаю сайты и сервисы целиком: от вёрстки до сервера. Пишу о том, что проверил на своих проектах.

Комментарии

// загружаю комментарии…

Комментарии публикуются после проверки. Ссылки и HTML не принимаются.