DDoS или сбой сервера — как установить причину недоступности сайта

Сайт перестал открываться, покупатели видят 503, а хостинг сообщает о повышенной нагрузке. Чтобы понять, происходит ли DDoS-атака, нужно установить, какой компонент отказал и что происходило с запросами в тот же момент. Один код ошибки, высокий расход ресурсов или подозрительный IP не дают полного ответа.

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

Что проверить в первые минуты недоступности

Сначала определите масштаб отказа. Не открывается весь сайт или только поиск, корзина, оформление заказа? Видит ли посетитель именно HTTP-ответ 503, сообщение браузера о невозможности соединения или страницу проверки безопасности? Это разные исходные данные.

1. 01Зафиксируйте время с часовым поясом. Сохраните адрес, действие посетителя, фактический статус и снимок ошибки. Если есть идентификатор запроса, запишите его.
2. 02Проверьте доступность из другой сети. Например, через мобильный интернет. Различие результатов помогает определить границы проблемы, но само по себе не устанавливает причину.
3. 03Проверьте несколько типов обращений. Публичную страницу, заведомо существующий статический файл и ту операцию, на которой произошёл отказ. Не запускайте массовый обход перегруженного сайта.
4. 04Сохраните доступные данные за проблемный интервал. Журналы запросов и ошибок, графики нагрузки, события защиты, сведения об обновлениях и фоновых заданиях.
5. 05Назначьте ответственного за восстановление. При продолжающемся отказе передайте хостингу или специалисту конкретный эпизод. Сбор доказательств не должен задерживать необходимые меры по восстановлению работы.

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

Почему ошибка 503 не доказывает DDoS

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

Обратное утверждение тоже неверно: при DDoS не обязательно появится 503. Соединение может оборваться или не установиться; промежуточный компонент может вернуть другой статус. Если браузер не получил HTTP-ответ, начинать нужно с проверки сети, DNS, соединения и TLS, а не с поиска записи 503 в журнале приложения.

Найденная автоматизированная активность также не равна доказанной DDoS-атаке. Каталог могут обходить поисковые роботы, сервисы проверки, парсеры или собственные интеграции. Они способны создать нежелательную нагрузку, но назначение трафика и его связь с отказом требуют отдельной проверки.

Корректный вывод должен объяснять механизм отказа. Какие обращения или события заняли ресурс, где возникло ограничение и почему нужные запросы перестали выполняться. Само слово «перегрузка» этого не раскрывает.

Как определить источник ошибки

Между покупателем и приложением могут находиться CDN, система защиты, балансировщик и веб-сервер. Каждый из этих компонентов способен прервать обработку запроса. Поэтому сначала нужно определить, на каком участке появился отказ.

Сохраните фактический ответ

Для проблемного обращения нужны HTTP-статус, заголовки, содержимое ответа, время и длительность ожидания. Их можно получить в инструментах разработчика браузера или из системы мониторинга. Для корзины и оформления заказа смотрите именно запрос неработающей операции: главная страница в тот же момент может отвечать нормально.

Название сервера в заголовке или логотип на странице ошибки дают ориентир. Однако посредник может передать ответ другого компонента или заменить его оформление. Окончательный вывод делайте после сопоставления журналов.

Сопоставьте записи одного обращения

Начните с идентификатора запроса. Если сквозного идентификатора нет, сопоставьте точное время, домен, путь, метод и другие доступные признаки. Приведите время журналов к одному часовому поясу и учитывайте возможное расхождение часов.

Проверьте, что зафиксировала защита, дошёл ли запрос до веб-сервера и был ли передан приложению. Для NGINX при соответствующей настройке журнала полезны $status, $upstream_status, $request_time и $upstream_response_time: ответ посетителю, ответ следующего сервера и длительности обработки. Эти поля нужно интерпретировать с учётом кеша, повторных попыток и конфигурации.

Отсутствие строки в одном журнале ещё не означает, что запрос точно остановился перед этим компонентом. Сначала проверьте полноту записи, нужный виртуальный хост, период ротации и доступность всех экземпляров приложения. Журнал выборочных событий защиты также не заменяет полный учёт обращений.

Проверьте промежуточные сервисы

Ошибка может возникать до выполнения кода сайта. Например, AWS Application Load Balancer документирует 503 при отсутствии зарегистрированных серверов назначения или когда все они находятся в состоянии unused. Диагностика такого случая начинается с маршрутизации и состава группы серверов, а не с плагинов CMS.

У сайта с Cloudflare сравнивайте сведения на стороне Cloudflare и исходного сервера. Проверка работоспособности самого провайдера полезна, но общий статус сервиса не объясняет автоматически проблему конкретного домена.

Какие наблюдения помогают различить причины

Выберите строку, похожую на ваш эпизод, и проверьте перечисленные объяснения. В таблице нет признака, который самостоятельно подтверждает DDoS: вывод строится по совокупности данных.

Одинаковая внешняя картина может возникать при разных неисправностях. В разборе аварии Cloudflare 18 ноября 2025 года компания сообщила, что первоначально подозревала масштабную DDoS-атаку. Установленной причиной оказался внутренний сбой после изменения прав в базе данных и формирования некорректного конфигурационного файла. Масштаб отказа сам по себе не определяет его природу.

Что проверять при подозрении на DDoS

Где именно выросла нагрузка

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

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

Уточняйте границы подключённой защиты. Защита сетевого и транспортного уровней L3/L4 и защита HTTP-приложения L7 решают разные задачи. Сам факт наличия услуги анти-DDoS не подтверждает, что она покрывает наблюдаемый сценарий.

Чем обращения отличаются от обычных

Сравните проблемный интервал с нормальным периодом при похожих условиях: временем суток, рекламной активностью и работой фоновых заданий. Проверьте концентрацию на отдельных URL, повторяемость операций, сочетание методов, параметры запросов и распределение источников.

Универсального порога «столько запросов в секунду означает атаку» нет. Одинаковое число обращений к кешированной странице и к тяжёлой операции поиска создаёт разную работу. Необычная страна, отсутствие покупок или один User-Agent тоже не являются достаточными основаниями для диагноза.

Если сайт находится за прокси, сначала убедитесь, что журнал корректно определяет адрес посетителя. Иначе за источник всего потока можно принять узел CDN. Заголовки с клиентским IP следует учитывать только в настроенной цепочке доверенных прокси: произвольный входящий заголовок не удостоверяет источник.

Есть ли связь с отказом

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

Разделяйте формулировки: «обнаружена автоматизированная активность», «подтверждено истощение ресурса» и «подтверждена атака». Для последнего вывода нужны дополнительные признаки атакующего трафика и его распределённости либо заключение системы защиты, подкреплённое данными эпизода. Цель конкретного отправителя не всегда устанавливается по журналу запросов.

Почему сайт может отказать при небольшом трафике

Заняты исполнители и растёт очередь

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

В PHP-FPM полезны текущая очередь listen queue, свободные и активные процессы, а также изменение счётчиков ограничения процессов и медленных запросов. Например, ненулевое max children reached говорит о достижении лимита с момента запуска пула, но без временной привязки не доказывает причину сегодняшнего сбоя. Снимайте показатели в динамике. Страницу состояния FPM не следует открывать для всех посетителей.

Повторные попытки усиливают неисправность

Задержавшийся сервис может вызвать повторы со стороны приложения, клиента или интеграции. Если повторы происходят на нескольких уровнях, объём работы увеличивается. В таком случае проверьте таймауты, число попыток и то, продолжается ли обработка предыдущего запроса после начала следующего.

Изменения должны учитывать смысл операции. Для оплаты и создания заказа повтор нельзя считать безвредным действием: требуется проверить, как система предотвращает повторное выполнение одной операции и как сверяет её результат.

Изменилась стоимость обработки

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

Для доказательства важны измерения до события, во время отказа и после изменения. Совпадение с обновлением помогает выбрать направление проверки, но ещё не доказывает виновность конкретного модуля.

Атака не обязательно заполняет канал

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

Когда 503 создаёт собственная защита

Ограничение частоты запросов может возвращать 503 даже при наличии свободных ресурсов. Например, в модуле NGINX limit_req код для отклонённых запросов по умолчанию задаётся как limit_req_status 503. Чтобы установить такую причину, нужно найти соответствующее срабатывание и проверить фактическую конфигурацию.

Уточните, на что установлен лимит: посетителя, домен, отдельный адрес или другую группу. Ошибка в определении клиентского IP способна объединить разных посетителей в одну группу. Слишком общее правило может затронуть рабочие обращения вместе с нежелательными.

Для проверки используйте журнал решений, область действия правила и доступный режим наблюдения. Корректировку ограничивайте установленной причиной. Отключение всей защиты на действующем сайте не является необходимым способом доказать ошибку одного правила.

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

Почему обнаруженный бот не всегда объясняет все ошибки

В нашем опубликованном расследовании периодических 503 в WordPress обнаружили и заблокировали источник бот-всплеска. После этого отказы полностью не исчезли, поэтому проверку продолжили и локализовали проблему до серверного окружения. Подробная последовательность и границы установленных выводов приведены в кейсе диагностики 503 в WordPress.

Этот результат показывает, почему полезно проверять оставшиеся симптомы после каждого изменения. Устранение одного фактора не подтверждает устранение всех причин недоступности.

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

В отчёте Cloudflare за третий квартал 2026 года, опубликованном 29 октября, указано: 96% отражённых компанией сетевых DDoS-атак завершились менее чем за десять минут, а 98% не превышали 1 Гбит/с. Это данные сети конкретного провайдера по сетевым атакам, а не характеристика всех отказов сайтов или всего HTTP-трафика.

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

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

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

Какие данные передать хостингу или разработчику

Карточка одного подтверждённого эпизода полезнее сообщения «сайт иногда падает». Заполните доступные поля. Если какого-то показателя нет, укажите это и запросите его у стороны, которая управляет соответствующим компонентом.

Шаблон обращения в техническую поддержку

В интервале [дата, время и часовой пояс] на [домен и путь] зафиксирован [HTTP-статус или ошибка соединения]. Проблема возникает при [действие]. Идентификатор запроса: [значение, если доступно]. Прилагаем ответ и относящиеся к этому интервалу наблюдения.

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

Если причина связывается с атакой, просим указать затронутый уровень, временные границы, характер трафика и действие защиты. Если причина связана с лимитом, просим назвать конкретный лимит и предоставить данные его срабатывания.

После исправления просим указать выполненное изменение и способ проверки результата. Данные, которые недоступны на нашем уровне доступа: [перечень].

Передавайте материалы через согласованный закрытый канал. В заголовках, параметрах и журналах могут находиться данные посетителей, cookie и токены; для диагностики передавайте только необходимые сведения.

Как проверить восстановление сайта и магазина

После исправления повторите проверки, на которых наблюдался отказ. Сопоставляйте одинаковые операции и фиксируйте изменившиеся условия. Единственный успешный ответ сразу после перезапуска не подтверждает устойчивую работу.

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

Что проверить для поисковой видимости

При большом количестве ответов 5xx и 429 Google снижает интенсивность обхода. Если отказы сохраняются на одном URL в течение нескольких дней, страница может выпасть из индекса. Универсального безопасного срока нет: важно устранить причину и проверить доступ к полезному содержимому.

Не подменяйте временную недоступность страницей ошибки с кодом 200 ради спокойного отчёта мониторинга. Система поиска получает содержимое ответа, поэтому нужная страница должна действительно быть доступна. Для временного отказа используйте соответствующий статус; если срок восстановления известен, сервер может передать его через Retry-After.

После изменения CDN или правил защиты проверьте важные URL в Search Console, включая полученное содержимое и результат отображения. Сопоставьте это с последующими обращениями робота в журналах. Одна успешная новая проверка не означает, что все страницы уже переобойдены и поисковые данные обновились.

Как зафиксировать установленную причину

Результат расследования должен отделять наблюдение от объяснения. Удобно записать его в четырёх частях.

1. 01Подтверждённые факты. Где и когда возник отказ, какие запросы затронуты, какие события совпали по времени.
2. 02Причина и степень уверенности. Что установлено, что поддерживается косвенными данными и какие альтернативы остаются.
3. 03Выполненное действие. Какое изменение внесли, когда и на каком компоненте.
4. 04Контроль результата. Какие операции повторили, в каких условиях, за какой период и что ещё требуется наблюдать.

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

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

Ответы на частые вопросы

Полезно по теме