Почему падают сайты: 12 главных причин

Почему сайты вообще «падают»

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

Задача администратора — не просто перезапустить сайт «на удачу», а быстро локализовать, на каком слое произошёл сбой. Условно весь путь запроса выглядит так:

браузер пользователя → DNS → сеть/хостинг → веб-сервер → приложение → база данных

Отказ на любом из этих слоёв делает сайт недоступным. Ниже — 12 самых частых причин, по которым сайты падают, сгруппированные по слоям. Для каждой — как это выглядит снаружи, как проверить самому и что делать.

Прежде чем разбирать причины, запомните главный инструмент диагностики: если сайт не открывается у вас, но непонятно — проблема у всех или только у вас, проверьте его через независимую точку — проверку доступности сайта. Это сразу отсекает локальные проблемы (ваш роутер, DNS-кеш, блокировки) от реального сбоя на стороне сервера.

---

1. Проблемы с DNS

DNS — это телефонная книга интернета: браузер сначала спрашивает, какой IP-адрес соответствует домену, и только потом идёт по нему. Если DNS-записи сломаны, сайт «не находится» ещё до того, как запрос дойдёт до сервера.

Как это выглядит

• Браузер пишет DNS_PROBE_FINISHED_NXDOMAIN или «Не удалось найти IP-адрес сервера».
• Сайт не открывается ни у кого, при этом сервер жив и отвечает по IP.
• Проблема появилась сразу после переноса домена или смены хостинга.

Частые сценарии

Симптом	Причина	Решение
NXDOMAIN (домен не найден)	Домен не привязан к DNS-серверу или удалены записи	Проверить NS-записи у регистратора, восстановить зону
Домен открывается «через раз»	Прописано несколько NS, один из них лежит	Убрать мёртвый NS, оставить рабочие
Сайт «уехал» на чужой IP	A-запись указывает на старый/чужой сервер	Обновить A/AAAA-запись на актуальный IP
Резко перестал открываться	Истёк срок делегирования домена	Проверить дату окончания регистрации и продлить

Как проверить самому

Команда dig показывает, что реально возвращает DNS-сервер, в отличие от браузера, который использует локальный кеш:

dig example.com A +short

Построчный разбор вывода:

93.184.216.34

• Если вывелся IP — A-запись на месте, проблема дальше по цепочке.
• Если пусто и есть строка status: NXDOMAIN — домен не резолвится, надо смотреть зону.
• Если пусто и status: SERVFAIL — DNS-сервер домена отвечает ошибкой.

Полезно проверить и сами NS:

dig example.com NS +short

Если здесь пусто или вернулись не те серверы, которые вы настраивали, — зона не делегирована корректно. Полную картину по записям домена можно собрать проверкой DNS-записей, а состояние самого домена (регистрация, RDAP/WHOIS) — проверкой домена.

---

2. Истёкший или невалидный SSL-сертификат

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

Как это выглядит

• NET::ERR_CERT_DATE_INVALID — сертификат просрочен.
• NET::ERR_CERT_AUTHORITY_INVALID — браузер не доверяет центру, выдавшему сертификат.
• NET::ERR_CERT_COMMON_NAME_INVALID — сертификат выдан на другое имя домена.

Причины

Код/симптом	Причина	Решение
CERT_DATE_INVALID	Не продлили сертификат вовремя	Перевыпустить и настроить автопродление
CERT_COMMON_NAME_INVALID	Сертификат не покрывает www-поддомен или выдан на другой домен	Перевыпустить с нужным SAN
CERT_AUTHORITY_INVALID	Отсутствует промежуточный сертификат в цепочке	Переустановить полную цепочку
Ошибка только на части устройств	Разные корневые сертификаты в системах	Проверить цепочку доверия

Как проверить самому

openssl показывает даты действия сертификата и для какого имени он выдан:

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

Разбор ключевых строк вывода:

notBefore=Jul  1 00:00:00 2026 GMT
notAfter=Sep 29 23:59:59 2026 GMT
subject=CN = example.com

• notAfter — дата, после которой сертификат станет невалидным. Если она в прошлом — причина найдена.
• subject=CN = ... — имя, на которое выдан сертификат. Если оно не совпадает с вашим доменом, браузер выдаст ошибку.

Отдельно проверьте, сколько дней осталось до истечения, через проверку срока SSL-сертификата, а корректность самой цепочки — проверкой SSL. Полезно настроить напоминание заранее: чаще всего сертификаты «падают» просто потому, что никто не вспомнил про продление.

---

3. Проблемы на стороне хостинга или сервера

Классика: сайт лежит, потому что упал сам сервер. Причины бывают и внешние (авария в дата-центре), и внутренние (закончилось место, упал сервис).

Как это выглядит

• Браузер долго грузит и выдаёт ERR_CONNECTION_TIMED_OUT или ERR_CONNECTION_REFUSED.
• Сайт не отвечает ни по HTTP, ни по SSH.
• В панели хостинга виден статус «недоступен».

Частые сценарии

Симптом	Причина	Решение
CONNECTION_REFUSED	Веб-сервер (nginx/Apache) остановлен	Перезапустить сервис
CONNECTION_TIMED_OUT	Файрвол закрыл порт или сеть недоступна	Проверить правила файрвола и сеть
Сайт отвечает, но медленно	Диск забит на 100%	Освободить место, найти лог-файлы
Резко «всё легло»	Авария в дата-центре	Проверить статус-страницу хостера

Как проверить самому

Сначала проверьте, доступен ли сервер вообще — по порту:

nc -zv 93.184.216.34 443

Разбор вывода:

Connection to 93.184.216.34 443 port [tcp/https] succeeded!

• succeeded — порт открыт, сеть и файрвол не блокируют; проблема внутри (веб-сервер).
• timed out или refused — сервер или порт недоступен снаружи.

Если открыт порт 443, но сайт не грузится — смотрим сам веб-сервер. Полезно понять, на каком именно порту должен отвечать ваш сайт: проверка порта покажет, открыты ли 80/443/22 снаружи.

---

4. Перегрузка ресурсов (CPU, память, трафик)

Сайт может «падать» не потому, что что-то сломалось, а потому что сервер не справляется с нагрузкой. Это случается при резком всплеске трафика (новость, акция, хайп в соцсетях) или при медленном росте, который никто не отслеживал.

Как это выглядит

• Сайт то открывается, то выдаёт 502 Bad Gateway или 504 Gateway Timeout.
• В пиковые часы страницы грузятся десятки секунд.
• В мониторинге ресурсов CPU или память держатся на 100%.

Признаки и решения

Симптом	Причина	Решение
502/504	Бэкенд-процесс (PHP/Node) не успевает отвечать	Увеличить лимиты, оптимизировать код
Рост времени ответа вечером	Сервер слабее пиковой нагрузки	Масштабировать или кешировать
OOM-killer убивает процессы	Закончилась память	Найти утечку, добавить swap/память
Резкий всплеск трафика	Вирусный приток/атака	Включить кеш, CDN, автоскейл

Как проверить самому

Время ответа сервера — первый индикатор перегрузки. Измерьте его с точностью до миллисекунды:

curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s\n" https://example.com

Разбор вывода:

ttfb: 0.214s

• ttfb (time to first byte) — сколько сервер думал до первого байта ответа. Норма — доли секунды; значение в несколько секунд указывает на перегруженный или медленный бэкенд.

Сравните замер в разное время суток. Если вечером TTFB растёт в разы — это перегрузка, а не случайный сбой. Быструю оценку скорости и времени ответа можно снять проверкой скорости/TTFB.

---

5. Ошибки конфигурации веб-сервера

Одна «удачная» правка конфига nginx или Apache способна положить весь сайт. Это одна из самых обидных причин: сайт лежит не из-за железа или атаки, а из-за опечатки.

Как это выглядит

• Сайт перестал открываться сразу после деплоя/правки конфигов.
• В логах веб-сервера — ошибка парсинга конфигурации.
• Работает одна часть сайта, другая отдаёт ошибку.

Частые ошибки

Симптом	Причина	Решение
Сервис не стартует после правки	Синтаксическая ошибка в конфиге	nginx -t перед перезапуском
Отдаётся не тот сайт	Неверный server_name/vhost	Поправить директивы
403 Forbidden	Неверные права на файлы/каталоги	Проверить права и владельца
Рекурсивный редирект	Зацикленные rewrite-правила	Упростить правила редиректа

Как проверить самому

Перед перезапуском nginx всегда проверяйте конфигурацию — это ловит опечатки до того, как они положат сайт:

nginx -t

Разбор вывода:

nginx: configuration file /etc/nginx/nginx.conf test is successful

• test is successful — синтаксис в порядке, можно перезапускать.
• Если выводит emerg и номер строки — исправьте указанную строку и не перезапускайте сервис.

Ошибки редиректов (когда сайт «крутится» и не открывается) удобно ловить проверкой редиректов — она покажет всю цепочку переадресаций и найдёт зацикливание.

---

6. Проблемы с базой данных

Даже если веб-сервер работает, сайт «падает» при недоступной базе данных — особенно это видно на динамических сайтах (WordPress, интернет-магазины). Без базы страницы либо не собираются, либо отдают ошибку подключения.

Как это выглядит

• Error establishing a database connection (WordPress).
• SQLSTATE[HY000] ... Connection refused в логах приложения.
• Страницы грузятся, но контент не подгружается (пустые списки, ошибки).

Причины

Симптом	Причина	Решение
Connection refused	СУБД остановлена или не слушает порт	Перезапустить MySQL/PostgreSQL
Too many connections	Исчерпан лимит подключений	Поднять лимит, пулинг соединений
Запросы выполняются секундами	Нет индексов, тяжёлые запросы	Оптимизировать запросы, добавить индексы
Диск базы забит	Неконтролируемый рост данных	Почистить логи, архивировать

Как проверить самому

Проверьте, слушает ли база свой порт и отвечает ли:

nc -zv localhost 3306

Connection to localhost 3306 port [tcp/mysql] succeeded!

• succeeded — порт открыт, СУБД слушает; смотрите лимиты и запросы.
• refused — база не запущена или слушает другой порт/сокет.

Если база отвечает, но сайт всё равно падает в пиках, смотрите Too many connections в логах — это классика при всплесках трафика.

---

7. Ошибки в коде приложения и деплое

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

Как это выглядит

• 500 Internal Server Error на части или всех страницах.
• Падение началось сразу после релиза/обновления.
• Ошибка воспроизводится на конкретной странице или действии.

Частые причины

Симптом	Причина	Решение
500 после релиза	Фатальная ошибка в новом коде	Откатить релиз, чинить код
Ошибка на одной странице	Баг в конкретной функции	Локализовать по логам
Падение при нагрузке	Утечка памяти/ресурсов	Профилировать, фиксить утечку
Ошибка после обновления зависимости	Несовместимость библиотек	Откатить зависимость

Как проверить самому

Логи приложения — главный источник правды. Смотрите хвост лога сразу после воспроизведения ошибки:

tail -n 50 /var/log/nginx/error.log

• Ищите строку с временем, совпадающим с моментом сбоя, и стек ошибки (файл + строка).
• PHP Fatal error: ... или Uncaught Exception ... прямо укажут на проблемное место.

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

---

8. DDoS-атаки и вредоносная активность

Сайт может «падать» от злонамеренной нагрузки. DDoS перегружает сервер потоком запросов, а взлом или майнер на сервере расходуют ресурсы изнутри.

Как это выглядит

• Внезапный рост трафика и загрузки CPU без видимой причины.
• Сайт недоступен из-за переполнения канала или процессов.
• Появление подозрительных процессов/файлов на сервере.

Признаки

Симптом	Причина	Решение
Резкий всплеск запросов с многих IP	DDoS-атака	WAF, CDN, ограничение по IP
CPU 100% от неизвестного процесса	Майнер/вредонос	Найти и удалить, закрыть дыру
Сайт попал в blacklist	Рассылка спама со взломанного сайта	Почистить, запросить разблокировку
Массовые попытки входа	Перебор паролей (brute force)	Ограничить попытки, 2FA

Как проверить самому

Если сайт или IP попал в спам-листы — это объясняет резкое «падение» (письма не доходят, доступ блокируется). Проверить репутацию IP можно проверкой IP в blacklist. А при подозрении на перебор смотрите число одновременных подключений к серверу:

ss -tn state established | wc -l

• Резко выросшее число установленных соединений с одного или множества IP — признак атаки.

---

9. Сбои у CDN или внешних сервисов

Многие сайты отдают статику и даже страницы через CDN. Если CDN-провайдер лёг, сайт может не открываться, хотя ваш сервер полностью исправен. То же касается внешних API, от которых зависит страница.

Как это выглядит

• Сайт работает, но не грузятся картинки/стили (CDN-домен не отвечает).
• Ошибка при обращении к стороннему API (платежи, карты, виджеты).
• Проблема массовая и совпадает с аварией у провайдера.

Причины

Симптом	Причина	Решение
Не грузится статика	CDN недоступен	Переключить на прямой источник, ждать восстановления
Ошибка в платежах	Сторонний API лёг	Обработать ошибку, показать заглушку
Страница зависит от виджета	Внешний скрипт блокирует рендер	Загружать асинхронно, fallback

Как проверить самому

Проверьте, отвечает ли CDN-домен отдельно от основного:

curl -I https://cdn.example.com/app.css

• HTTP/2 200 — CDN жив, проблема в другом.
• timed out или 5xx — виноват CDN, а не ваш сервер.

Главный вывод: «сайт упал» не всегда означает «упал наш сервер». Разделяйте слои, чтобы не чинить то, что не ломалось.

---

10. Сбой на стороне регистратора или истечение домена

Домен — это аренда, а не покупка навсегда. Если не продлить регистрацию, домен перестанет резолвиться, и сайт «исчезнет» для всех, хотя сервер продолжает работать.

Как это выглядит

• Домен перестал открываться без изменений на сервере.
• NXDOMAIN или страница регистратора «домен не оплачен».
• Письма о продлении ушли в спам и были пропущены.

Причины

Симптом	Причина	Решение
NXDOMAIN после даты окончания	Домен не продлён	Срочно продлить у регистратора
Домен в статусе pendingDelete	Прошёл grace-период	Восстановление (дороже) или новый домен
Смена владельца/контактов	Неверные WHOIS-данные	Обновить контакты
Домен «заблокирован»	Нарушение правил регистратора	Связаться с поддержкой

Как проверить самому

Проверьте дату окончания регистрации, чтобы знать запас по времени:

whois example.com | grep -iE "expir|paid-till|registrar:"

• Строка expiry date / Registry Expiry Date покажет, до какого числа домен оплачен.
• Если дата в прошлом или близко — это причина или надвигающаяся проблема.

Следить за состоянием домена проще через проверку домена: она покажет ключевые RDAP/WHOIS-поля без ручного парсинга.

---

11. Сетевые проблемы и маршрутизация

Иногда сайт «недоступен» не потому, что он упал, а потому что до него нельзя достучаться: проблемы у интернет-провайдера, обрыв канала, неверная маршрутизация или блокировка на уровне сети.

Как это выглядит

• Сайт недоступен только из определённой сети/региона.
• ERR_CONNECTION_TIMED_OUT при живом сервере (проверка извне проходит).
• Проблема исчезает при смене сети (мобильный интернет работает, Wi-Fi — нет).

Причины

Симптом	Причина	Решение
Недоступен из одной сети	Проблема у провайдера	Проверить из другой сети
Маршрут до сервера обрывается	BGP/маршрутизация	Связаться с хостером/провайдером
Блокировка по IP/региону	Firewall, геоблокировка	Проверить правила
Потеря пакетов	Нестабильный канал	Диагностика сети

Как проверить самому

Проверьте, доходит ли вообще трафик до хоста, и на каком узле он теряется:

ping -c 4 example.com

Разбор вывода:

4 packets transmitted, 4 received, 0% packet loss

• 0% packet loss — сеть до хоста стабильна.
• Большой процент потерь или Destination Host Unreachable — проблема на маршруте.

Проверить доступность хоста с независимой точки можно пинг-проверкой — это отличает локальную сетевую проблему от реального падения сервера.

---

12. Человеческий фактор и незапланированные работы

Последняя, но не по частоте причина: сайты падают из-за людей — случайных правок, удаления файлов, неверных команд, деплоя в неподходящий момент.

Как это выглядит

• Сбой начался сразу после чьих-то действий.
• Удалены/перезаписаны файлы, сброшены настройки.
• Деплой в часы пик положил продакшен.

Типичные случаи

Симптом	Причина	Решение
Удалили файлы/БД	Случайная команда	Бэкапы, ограничение прав
Деплой в пик	Нет регламента релизов	Релизы вне пиковых часов
«Работало и перестало»	Незадокументированная правка	Логирование изменений
Ошибка в скрипте миграции	Непроверенная миграция	Тест на staging перед prod

Как защититься

• Держите бэкапы (файлы + база) и проверяйте, что они восстанавливаются.
• Используйте staging-окружение и проверяйте миграции до продакшена.
• Ограничивайте права на сервере: не всем нужен root.

Большинство человеческих ошибок можно было бы поймать заранее, если бы кто-то вовремя заметил, что сайт перестал отвечать. Здесь ключевая роль — у мониторинга: про регулярную проверку доступности читайте в соседней статье о том, почему сайт не открывается.

---

Что делать, когда сайт упал: порядок действий

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

1. Отсечь локальные проблемы. Проверьте сайт через проверку доступности из независимой точки. Если там сайт открывается — проблема на вашей стороне (DNS-кеш, сеть, блокировка).

2. Проверить DNS. dig example.com A +short — резолвится ли домен и на тот ли IP указывает.

3. Проверить сеть и порт. nc -zv <ip> 443 — доступен ли сервер по нужному порту.

4. Проверить сертификат. openssl s_client ... — не истёк ли сертификат.

5. Проверить веб-сервер и базу. Логи nginx/Apache, статус СУБД.

6. Проверить нагрузку. CPU, память, число соединений, TTFB.

7. Проверить код и деплой. Когда сделали последние изменения и что именно.

Этот чек-лист экономит часы: вместо «перезапустить всё и надеяться» вы идёте сверху вниз по слоям и находите причину за минуты.

---

Как не пропустить падение

Поймать проблему «по звонку клиента» — это уже опоздание: пользователи заметили сбой раньше вас. Гораздо надёжнее узнать о падении до того, как о нём расскажут посетители.

Регулярная проверка доступности сайта и контроль ключевых параметров — SSL, DNS, времени ответа — дают ранний сигнал, когда что-то пошло не так. Причём важен не разовый запуск, а именно регулярность: многие из перечисленных причин (истечение сертификата, домена, рост нагрузки) развиваются постепенно и отлично ловятся при систематическом наблюдении.

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

Начните с простого: проверьте свой сайт прямо сейчас и зафиксируйте базовое состояние. Дальше проще заметить любое отклонение.