Почему сайт не работает: 7 причин и как восстановить за 10 минут

Открываешь свой сайт — а там белый экран. Или 502-ка. Или этот вечный кружочек, который крутится-крутится... Знакомая картина? У меня за последние лет восемь это было примерно раз триста. И знаешь что? В подавляющем большинстве случаев причина оказывается смешной до слёз, а чинится за время одной чашки кофе. Если знать, куда смотреть.

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

Сначала проверь — это только у тебя или у всех?

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

Расскажу историю. Пару лет назад коллега мне в час ночи пишет: "сайт упал, всё горит, заказчик орёт". Я лезу с ноута — открывается. Лезу с телефона — открывается. А у него — нет. Час диагностики. Оказалось — провайдер у него в Балашихе режет один конкретный CDN-узел. Сайт прекрасно работал у всех остальных пользователей планеты. Кроме него.

Так что прежде чем рвать на себе тельняшку — 60 секунд на проверку.

Открой сайт на телефоне через мобильный интернет. Вот прям отключи Wi-Fi и переключись на 4G. Если открывается — поздравляю, проблема локальная. Это твой провайдер, твой роутер, твой DNS-кэш, твой AdBlock или ещё какая-то ерунда на твоей стороне. Не на сервере.

Если на телефоне тоже не открывается — подключай тяжёлую артиллерию. Друг из другого города, желательно из другого региона. Знаю случай когда сайт упал ровно в Москве (магистральный узел Ростелекома лёг), а из Новосибирска отвечал как ни в чём не бывало. Половина клиентов не заметила вообще ничего.

И третье — внешний чекер с распределённой проверкой. Тут важно: проверка должна идти не из твоей сети. Любой инструмент, работающий из одной точки, врёт. Именно поэтому серьёзный мониторинг всегда распределённый — PingMap, например, бьёт по сайту одновременно из Москвы и Питера, чтобы отличить "сайт лежит у всех" от "лежит конкретный канал между регионами". Подробнее про инструменты — в [/tools/].

Убедился что лежит не только у тебя? Поехали дальше.

7 главных причин почему сайт не работает

За годы я видел причины разные — от мыши, которая перегрызла оптоволокно в подвале дата-центра (реально, Selectel, 2022), до уволенного админа, который перед уходом удалил A-запись. Но если без экзотики, то 90% инцидентов укладываются в семь сценариев. Ниже — каждый.

1. DNS — домен не резолвится

Самое подлое. С сервером всё хорошо, файлы лежат, nginx крутится, БД отвечает — а домен указывает в никуда. Бывает после переноса хостинга, после правок в DNS-зоне, после опечатки в A-записи (один лишний нолик в IP, привет), после того как счёт за продление домена улетел в спам и никто не заметил.

У меня была история когда из-за TTL 86400 откат полтора суток ехал. Полтора. Суток. Клиент звонил каждые два часа.

Проверяется элементарно:

nslookup pingmap.ru
dig pingmap.ru A +short

Пустой ответ? NXDOMAIN? IP не тот, что должен быть? Нашёл. Дальше — лезешь в личный кабинет регистратора и смотришь срок регистрации домена. Reg.ru особенно любит присылать письма о продлении в spam-папку, я уже отдельный фильтр настроил.

И помни про TTL. После правки записи реальное распространение по миру занимает от пары минут до 48 часов. Это не баг, это фича — и поэтому DNS меняют до переезда, а не во время него.

2. Хостинг лёг или закончился оплаченный тариф

Вторая по частоте, особенно у небольших проектов на условном Beget или Timeweb. Хостер может упасть сам — ДЦ обесточили, сетевой сбой, плановые работы которые никто не анонсировал. А может тебя отключить за неоплату. Без писем, без уведомлений. Просто — 502 и таймаут.

Что делаешь. Заходишь в панель хостинга, смотришь баланс. Открываешь статус-страницу хостера (status.selectel.ru, status.timeweb.com — у всех нормальных хостеров это есть). Если у тебя VPS — пробуешь по SSH. uptime, top, df -h, логи nginx. Стандартный набор.

А вот если SSH не отвечает, а в панели сервер гордо горит зелёным "online" — это самое неприятное. Пиши в саппорт, прикладывай скрины, время. Готовься ждать. Beget отвечает минут за 15, Timeweb — за час, у Hetzner я однажды три часа тикет провисел.

3. SSL-сертификат истёк

Классика. Особенно у Let's Encrypt с автообновлением, которое внезапно сломалось — потому что три месяца назад кто-то поменял пути к webroot и забыл подправить crontab. Симптом тебя не порадует: сайт открывается, но браузер шлёпает огромное красное предупреждение NET::ERR_CERT_DATE_INVALID. Современный Chrome дальше пользователя просто не пускает. Всё, конверсия в нуле.

Проверка:

curl -vI https://example.com 2>&1 | grep -E "expire|subject"
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Можно ещё SSL Labs (https://www.ssllabs.com/ssltest/) — там полный отчёт по сертификату, цепочке доверия, шифрам. Лечится перевыпуском или починкой cron-задачи с certbot. Параноидальный мониторинг должен орать об истечении дней за 14 — про это в [/features/http-monitoring/].

4. Деплой сломал прод — последний релиз с багом

Вот это меня всегда бесило. Сайт не работает, потому что вы сами его сломали полчаса назад. Зашла новая фича, миграция БД проехала криво, кто-то обновил зависимость с major-bump (и не прочитал changelog), и теперь на главной — 500-я.

Что делаешь. Первое — git log, какой коммит сейчас на проде. Когда задеплоен. Второе — лезешь в логи. journalctl -u app -n 200 или docker logs container --tail 200. Стектрейс есть? Читай. Понимаешь что там? Чини.

Не понимаешь за пять минут — откатывайся. Просто откатывайся. Это не позор, не признание поражения — это нормальное инженерное решение. Каждая минута даунтайма — это деньги, и деньги не твои, а заказчика. Помню падение на Чёрной пятнице 2024 — RPS улетел в 8 раз за минуту, новый код не вытянул, откатились на предыдущий тэг и спокойно разбирались уже после распродажи.

5. DDoS или резкий всплеск трафика

Сценарий: у тебя через VPN сайт открывается, у обычных пользователей — нет. Сервер задыхается. Либо это атака, либо вирусный пост в Х (бывшем Twitter), либо парсеры зашли стаей и сосут контент со скоростью пожарного шланга.

Признаки видны сразу:

• В access.log nginx — десятки тысяч одинаковых запросов с одних подсетей
• LA скачет за пределы разумного, CPU в полке
• iftop или nethogs рисуют аномалию

И тут начинается дискотека. Cloudflare на проксирование, BotFAQtor для фильтрации, временно — iptables забанить совсем уж наглые подсети, в nginx — limit_req_zone. Если же это легитимный трафик (репост от блогера на миллион подписчиков, например) — ну, поздравляю, и масштабируй. Вертикально — больше CPU/RAM. Горизонтально — реплики за балансером.

6. Сайт упал в одном регионе

Особенность нашей сетевой реальности: бывает что сайт работает в Москве, но из Питера — 504. Или наоборот. Или из Екатеринбурга всё хорошо, а в Краснодаре пользователи матерятся. Причины — магистральный провайдер чудит, региональная блокировка по IP подцепилась случайно (привет, РКН), маршрутизация через сломанный hop.

Симптом этих штук — самый коварный. Половина пользователей жалуется, половина не замечает. Если ты сидишь в Москве и у тебя всё открывается — ты вообще никогда не узнаешь, что в Новосибирске у клиентов 504-я уже четыре часа. Без распределённого мониторинга такие инциденты не ловятся в принципе.

Диагностика:

mtr -r -c 30 example.com
traceroute example.com

И запускаешь это с разных точек. Со своего ноута, с VPS в другом регионе (любой Hetzner или Aeza за 200 рублей в месяц подойдёт), через VPN. Сравниваешь маршруты. Трасса обрывается на конкретном hop у одного из провайдеров? Поздравляю, это сетевая проблема между регионами, а не у тебя.

7. Браузерная проблема — куки, кэш, расширения

Сайт открывается — но не работает. У тебя одного. У всех остальных нормально. Тогда дело почти всегда в браузере.

Сломанные куки сессии. Закэшированный старый JS, который конфликтует с новым API. Расширение типа AdBlock или Privacy Badger режет нужные запросы (особенно весело когда твой собственный домен попал в какой-то списочек). Service Worker от старой версии PWA, который упорно отдаёт устаревший offline-кэш...

Лечение тривиальное — открыл в инкогнито без расширений, проверил. Работает? Иди и чисти кэш конкретного домена. DevTools → Application → Storage → Clear site data. Всё.

Что делать ПРЯМО СЕЙЧАС если сайт не работает

Сайт лежит, телефон разрывается, в Telegram пять чатов горят красным. Не паникуй — иди по чек-листу. На каждый шаг минута, общий тайминг диагностики семь-десять минут.

Первое что делаешь — пингуешь. Не сервер, нет. Сначала проверяешь, что сайт лёг не только у тебя. Открыл на мобильном через 4G, попросил коллегу из другого города, прогнал через внешний чекер. Если только у тебя — иди чини свой DNS-кэш. На винде это ipconfig /flushdns, на маке sudo dscacheutil -flushcache, на линуксе зависит от systemd-resolved.

Дальше — смотришь жив ли вообще сервер.

ping example.com
traceroute example.com
mtr -rwbzc 30 example.com

Ping не идёт, traceroute умирает на твоём провайдере? Проблема между тобой и сервером, не в сервере. Обрывается у дата-центра — ну, привет, лежит хостинг.

Третье. Curl с заголовками. Это самая полезная команда в твоём арсенале, я не шучу.

curl -I https://example.com
curl -vL https://example.com 2>&1 | head -50

И смотришь HTTP-код. По нему сразу понятно где копать:

| Код | Что значит | Куда смотреть | |---|---|---| | 200 | Сервер отвечает | Инфраструктура ок, ищи в JS на фронте | | 301/302 (бесконечно) | Цикл редиректа | Сломан конфиг nginx или приложения | | 403 | Доступ запрещён | Whitelist в nginx, права на файлы | | 500 | Внутренняя ошибка | Приложение упало — лезь в логи | | 502 | Bad Gateway | Backend помер: PHP-FPM, Node, upstream не отвечает | | 503 | Service Unavailable | Перегрузка или плановые работы | | 504 | Gateway Timeout | Backend жив но не успевает за nginx-таймаут | | Таймаут | Сервер недостижим | Сетевой уровень или сервер выключен |

Четвёртое — DNS. На всякий случай. Даже если уверен что не оно.

dig example.com A +short
dig example.com NS
nslookup example.com 8.8.8.8

Сравни IP с тем что ожидаешь увидеть. NS-серверы не те? Кто-то трогал делегирование. Бегом в кабинет регистратора смотреть.

Пятое — сертификат. SSL Labs либо консолью:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Шестое. Прежде чем лезть глубже — открой статус-страницу хостинга и CDN. Reg.ru, Selectel, Timeweb, Cloudflare — у всех есть status.*. Красные значки? Расслабься, чинят за тебя. Поставь себе в саппорт-чат и иди пить кофе.

И седьмое, если до сих пор причина не нашлась — SSH на сервер.

ssh user@server
uptime
df -h
free -m
journalctl -u nginx -n 50 --no-pager
journalctl -u app-name -n 100 --no-pager

df -h отдельно — раз в год кто-нибудь обязательно ловит "no space left on device" из-за того что логи распухли до сотни гигов. У меня было.

Чего НЕ делать в панике. Не деплой ещё что-то поверх — пока не знаешь причину, сделаешь только хуже (проверено лично, не повторять). Не перезагружай сервер вслепую — потеряешь логи в /tmp и все улики, потом не разберёшься что вообще случилось. Не меняй DNS на лету если не уверен — TTL может растянуть откат на сутки. И не пиши клиентам "всё работает" пока сам не убедился через распределённый чекер. Хуже нет чем сказать "починили" а оно ещё лежит у половины пользователей.

Как узнать о падении первым (а не от клиента)

Признайся. Чаще всего ты узнаёшь о падении не из мониторинга. А из сообщения клиента в Telegram: "у вас там лежит что-то?". А лежит уже минут сорок. За эти сорок минут ты потерял заказы, доверие, SEO-позиции (Яндекс и Google тоже ходят на сайт, и им очень не нравится встречать 502), и нервные клетки.

Догонялки. Постоянные догонялки. Ручная проверка раз в день не работает — сайт может упасть через пять минут после твоего утреннего "всё ок", и пролежать до вечера, пока клиент не напишет.

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

Что должен уметь нормальный мониторинг. Проверки с интервалом от 30 секунд, не раз в пять минут (за пять минут можно успеть потерять три тысячи рублей на интернет-магазине средней руки). Распределённые агенты — минимум из двух регионов, чтобы отличить локальный сетевой сбой от настоящего падения. Несколько типов проверок — HTTP-код это база, но ещё нужно время ответа, наличие ключевого текста на странице (а то бывает: 200 OK, а вместо контента — пустая заглушка), валидность SSL, отклик ping и TCP-порта. Уведомления туда, где ты их точно увидишь — Telegram, email, webhook. И публичная статус-страница, которую можно показать клиентам, чтобы они не заваливали поддержку одинаковыми вопросами.

PingMap делает ровно это. Распределённые проверки из MSK + SPB, минимальный интервал 30 секунд, алерты в Telegram, мониторинг SSL с предупреждением об истечении за 14 дней, проверка контента страницы а не только HTTP 200, публичные статус-страницы. Тарифы Free / Solo / Team — все по 0₽ во время беты, без кредитки.

Подключи бесплатный мониторинг за 2 минуты — 3 проверки на Free-тарифе навсегда: pingmap.ru. Настройка — в [/docs/getting-started/], алерты — в [/features/alerts/].

FAQ — частые вопросы

Что делать, если сайт открывается, но не работает (формы, кнопки)?

Скорее всего залип JavaScript или API-бэкенд. Жми F12, открывай DevTools, иди во вкладку Console — там увидишь ошибки JS прямо красным. Дальше Network — смотришь, какие запросы валятся (тоже подсвечены красным), какой статус, что в ответе. Чаще всего это либо API сломали последним деплоем, либо CORS косячит, либо умер микросервис к которому фронт ходит за данными. Лечится со стороны бэкенда или конфига nginx. Иногда — через простое "забыли задеплоить новую версию API одновременно с фронтом", и тогда фронт зовёт endpoint которого ещё нет.

Как понять, что сайт упал у всех или только у меня?

Самый быстрый способ — телефон, отключить Wi-Fi, открыть сайт через 4G. Это другая сеть, другой DNS, другой провайдер. Открывается? Значит у тебя локально что-то — провайдер режет, роутер залип, DNS-кэш протух, или AdBlock в браузере сошёл с ума. Не открывается и там тоже — звонишь коллеге из другого города, или прогоняешь через распределённый чекер. Локальная проверка с одной точки — это всегда немножко гадание.

Сайт работает, но медленно — это тоже считается, что не работает?

С точки зрения пользователя — абсолютно да. Если страница грузится дольше трёх секунд, около 40% посетителей просто закрывают вкладку и уходят. Поисковики тоже не дремлют — TTFB за 5 секунд и Google спокойно понизит тебя в выдаче. Так что нормальный мониторинг следит не только за "жив или нет", но и за временем ответа. И алертит при превышении — например "ответ дольше двух секунд пять минут подряд". У меня такой алерт раз в неделю спасает от тихой деградации после очередного релиза.

Что значит "сервер не отвечает"?

Это сетевой уровень. Браузер послал запрос на IP — и не получил ничего в разумное время (обычно секунд тридцать-шестьдесят). Причин может быть пачка: сервер физически выключен, между тобой и сервером оборвана сеть, файрвол на сервере молча дропает пакеты в /dev/null, упал nginx или apache при живой ОС, или сервер просто захлебнулся под нагрузкой. Диагностика — ping (жив ли хост вообще), traceroute (где обрывается путь), telnet host 80 или nc -zv host 443 (отвечает ли конкретный порт).

Можно ли получать SMS вместо Telegram, если сайт упал?

В PingMap из коробки — Telegram, email, webhook. Через webhook прикручиваешь любой сторонний SMS-шлюз — SMS.ru, Twilio, BeelineSMS, что душе угодно. Webhook прилетает на твой эндпоинт, оттуда дёргаешь API шлюза. Но я бы советовал Telegram — у меня лично он работает быстрее SMS секунд на десять-двадцать (особенно у МТС бывают задержки), история вся в чате, можно настроить разные чаты для разных проектов и не путаться. Плюс Telegram-бот не теряется при смене номера.

Сколько стоит мониторинг сайта?

PingMap во время беты — бесплатно. На всех тарифах. Free даёт 3 проверки, Solo — 10, Team — 50, и все три по 0₽. Этого хватает чтобы покрыть основной сайт, API, плюс пару критичных сторонних интеграций (платёжка там, или внешний CRM-вебхук) с интервалом в 30 секунд. Регистрация без карты, отписаться можно в любой момент. Нужно больше пятидесяти проверок или какие-то специфические интеграции — пиши в саппорт, договоримся.