Анонимный зарубежный кейс · HTTP/L7 DDoS · OpenCart · Cloudflare
Задача была не просто заблокировать ботов, а оставить магазин доступным покупателям
Ко мне обратился владелец интернет-магазина с покупателями из США и Европы. На сайт шли многомиллионные волны HTTP-запросов. Владелец вручную усиливал фильтрацию Cloudflare, иногда закрывал отдельные страны, но настоящие посетители всё равно периодически получали ошибки подключения. Я разделил проблему на три части: атакующий трафик, связь Cloudflare с сервером и работоспособность самого магазина.
Цифры получены из контрольных срезов Cloudflare за сентябрь 2026 года. Это статистика запросов и решений защиты, а не количество посетителей или гарантированный uptime.
География решения: этот подход с Cloudflare я применял для зарубежного магазина с покупателями в США и Европе. Для сайтов, ориентированных прежде всего на посетителей из России, есть существенные сетевые ограничения — объясняю ниже, почему здесь нужен другой выбор защиты. Если проект развивает зарубежный рынок, могу помочь и с SEO-продвижением за рубежом.
Проблема со стороны владельца: магазин работает, пока нет атаки — потом снова 522
Для владельца коммерческого сайта DDoS — это не только график запросов. Если страница товара не открылась, покупатель не добавит товар в корзину. Если административные запросы попадают на проверку безопасности, сотрудники не увидят часть информации. Если сервер перестаёт отвечать CDN, обычный посетитель может получить Connection timed out, даже когда большинство вредоносных запросов уже заблокировано.
Магазин работал на OpenCart с шаблоном Journal и дополнительным модулем ускорения страниц. В разные моменты владелец включал режим Under Attack и географические блокировки. При этом целевая аудитория находилась в нескольких странах. Простое «закрыть весь подозрительный регион» здесь означало потенциально закрыть и часть покупателей.
Что клиент хотел получить
Работающий каталог, корзину и оформление заказов при атакующем трафике — без постоянного ручного переключения режима защиты и блокировки целых стран.
Что требовало отдельного разбора
Почему после фильтрации DDoS в Cloudflare сайт иногда продолжал возвращать 522, а административные AJAX-запросы сталкивались с дополнительными проверками.
Мой подход: в подобных проектах я не считаю настройку WAF законченной только потому, что стало больше событий Block. Нужно убедиться, что реальный покупатель открывает магазин, а сервер не блокирует сам Cloudflare.
С чего начал: разделил Cloudflare, веб-сервер и приложение
При DDoS часто показывают один большой график и делают вывод, что вся проблема в ботах. Здесь этого было недостаточно. Пришлось сопоставлять Cloudflare Security Events и HTTP Security Analytics с access/error-журналами origin-сервера, сообщениями владельца, ответами хостинга и поведением OpenCart.
- Собрал хронологию всплесков и ошибок. Для каждого интервала зафиксировал время, тип запросов, массовые URL, действия Cloudflare и симптомы у посетителей. Не складывал несопоставимые окна статистики.
- Разобрал характер HTTP-флуда. Сравнил GET и POST, обращение к главной и служебным путям, User-Agent, страны и сети источников, срабатывания Custom Rules и Rate Limiting.
- Проверил разницу между edge и origin. Запрос, остановленный Cloudflare, не равен запросу, выполненному PHP. Ошибка 522 тоже не равна доказательству того, что WAF «пропустил атаку».
- Проверил покупательские и административные сценарии. Защита должна учитывать AJAX, сессии, корзину, оформление заказа, динамическое кэширование и работу поисковых роботов.
- Выделил инфраструктурные вопросы. Серверные лимиты, поведение firewall хостинга, подключение к MySQL, корректность доверия прокси и необходимость изоляции origin требуют отдельной диагностики.
Именно на этой стадии стало понятно, что перед нами не одна «атака с одним решением», а несколько параллельных причин возможной недоступности. Часть симптомов относилась к фильтрации на CDN, часть — к соединению CDN с хостингом, часть — к PHP и базе данных.
Что показала статистика: не просто бот-трафик, а повторяющиеся L7-волны
В одном из коротких интервалов Cloudflare зарегистрировал около 13,09 млн HTTP-запросов за 20 минут; примерно 12,96 млн система классифицировала как mitigated. В другом шестичасовом срезе видны 109,13 млн запросов. Это независимые временные окна, а не накопленный итог проекта.
В логах встречались массовые GET-запросы к главной странице, отдельные подозрительные POST-сценарии, вариативные User-Agent и попытки обращения к путям, которые не относятся к рабочим функциям OpenCart. Трафик шёл не от одной очевидной машины, которую достаточно заблокировать по IP. Из-за распределения источников грубая GEO-фильтрация не подходила.
Отдельно я исследовал журналы самого сервера. Например, в одном из примерно сорокаминутных интервалов было зарегистрировано 295 641 HTTPS-обращение к origin с участием 730 уникальных IP. Это другой слой измерения: здесь учитываются запросы, попавшие на сервер, а не вся активность на стороне Cloudflare.
Как перестроил защиту Cloudflare без тотальной блокировки покупателей
Основная работа выполнялась с Cloudflare WAF, Custom Rules, Rate Limiting и штатными механизмами HTTP DDoS Protection. Вместо бесконечной ручной блокировки отдельных IP и стран я построил слои фильтрации по наблюдаемым паттернам трафика и характеру URL.
1. Отсечение очевидного шума
Отделил известные шаблоны сканирования, попытки обращения к нерелевантным служебным путям и подозрительные повторяющиеся запросы от обычного просмотра каталога.
2. Ограничение частоты
Для части массовых L7-сценариев задействовал Rate Limiting. Параметры подбирались не по красивым цифрам блокировок, а с учётом реального пользовательского поведения.
3. Защита административного контура
Дополнительные проверки сосредоточил на чувствительных сценариях. При этом административные AJAX-методы и статические ресурсы нельзя бездумно отправлять на CAPTCHA или Managed Challenge.
4. Сохранение рабочих функций CMS
Не блокировал весь POST, общий index.php, действия покупателя и поисковых роботов. Динамические страницы магазина требуют исключений из грубого кэширования.
Почему обычное Under Attack Mode — не единственный ответ
Режим усиленной проверки бывает полезен во время активной атаки, но его постоянное использование может мешать покупателю открыть страницу. Аналогично, увеличение числа блокировок по странам не гарантирует защиту: реальные покупатели и источники атаки могут находиться в одной географии. Поэтому я оставил ручной аварийный режим как дополнительный инструмент, а основную работу переложил на постоянно действующую фильтрацию.
Что особенно важно для OpenCart / Journal
Корзина, личный кабинет, поиск, изменение валюты, авторизация, генерация кэша, AJAX-функции и оформление заказа работают не как статическая HTML-страница. Универсальное правило «заблокировать все POST» или «кэшировать всё» способно решить задачу фильтрации ценой сломанного магазина. В этом проекте я отдельно учитывал взаимодействие защиты с модулем ускорения страниц и динамическими запросами.
Почему этот вариант защиты подходит зарубежным сайтам, но не является универсальным для России
В этом кейсе принципиально важна география покупателей. Интернет-магазин работал на рынках США и Европы, поэтому Cloudflare использовался как внешний CDN, обратный прокси и уровень фильтрации HTTP/L7-атак. Для таких международных проектов Cloudflare может быть практичным решением: защиту можно настраивать с учётом поведения посетителей, WAF и особенностей конкретной CMS.
Зарубежная аудитория: США, Европа, другие рынки
Cloudflare можно рассматривать как часть архитектуры: защита от HTTP-флуда, WAF, rate limiting, кэширование статических ресурсов, мониторинг реальных пользователей. Но и здесь отдельно проверяю origin, ошибки 520/522, ложные блокировки и доступность оформления заказа.
Основная аудитория в РФ: ограничения сетевой доступности
В российских сетях наблюдаются серьёзные ограничения трафика к инфраструктуре Cloudflare, включая обрывы соединений и неполную загрузку страниц. Если сделать Cloudflare единственной точкой входа, можно получить ситуацию, когда атака фильтруется, но покупатели из России не могут нормально открыть сайт.
Моя позиция: если сайт продаёт преимущественно в России, сначала надо проверять доступность из целевых российских сетей и подбирать защиту с соответствующей маршрутизацией, CDN, WAF и инфраструктурой. Использовать Cloudflare по инерции только потому, что он хорошо показал себя на зарубежном магазине, я бы не стал. Возможны локальные провайдеры Anti-DDoS/CDN, защита у хостера или гибридная схема — выбор зависит от приложения, инфраструктуры и реальных посетителей.
Почему защита и международное SEO связаны
Для зарубежного продвижения мало собрать англоязычную семантику, подготовить контент и настроить hreflang. Зарубежный пользователь и поисковый робот должны получать страницы без лишних challenge, блокировок WAF и ошибок origin. Иначе техническая доступность становится ограничением для обхода сайта, индексации, органического трафика и продаж — даже при хорошей SEO-стратегии.
Я рассматриваю это как две разные, но связанные задачи: защита сайта от DDoS обеспечивает устойчивость инфраструктуры, а продвижение сайта за рубежом охватывает международную семантику, локализацию, структуру, индексацию Google и развитие органического спроса. Одно не заменяет другое, но технические ошибки способны свести на нет усилия в обеих областях.
Почему магазин выдавал Cloudflare 522, даже когда атака фильтровалась
Одна из главных находок — проблема доступности была не только на стороне DDoS. Хостинг использовал собственный серверный firewall. При высокой нагрузке он мог ограничивать соединения, в том числе от узлов Cloudflare, обслуживающих нормальных посетителей. Поддержка подтверждала такие блокировки и необходимость их снятия в отдельных эпизодах.
| Симптом | Что он означает | Что я проверяю |
|---|---|---|
| 522 Connection timed out | Cloudflare не смог вовремя установить соединение с origin | Firewall, доступность сервера, маршрутизацию, ограничения соединений и логи хостинга |
| 520 Web server returned an unknown error | Origin вернул неожиданное, пустое или некорректное поведение соединения | Время ошибки, HTTP-заголовки, логи веб-сервера/PHP/MySQL, обрывы до HTTP-ответа |
| Managed Challenge для AJAX | WAF может подменить ожидаемый JSON или ресурс страницей проверки | Security Events, метод, маршрут, контекст сессии и ложные срабатывания |
Позднее появлялись и кратковременные 520. Я не стал приписывать их автоматически DDoS или последним патчам: причина такого события определяется только по совпадающим во времени данным Cloudflare и origin. В доступной выборке был зафиксирован сам симптом, но не доказана его единственная причина.
После DDoS-разбора обнаружились отдельные риски безопасности и стабильности
В ходе дальнейшего технического сопровождения я проверил не только запросы, но и PHP-логи, работу MySQL, дополнительные модули OpenCart и историю изменений файлов. Это не означает, что все найденные дефекты возникли из-за атаки: часть ошибок могла существовать намного раньше.
Массовые ошибки соединения с MySQL
В исторических журналах было 571 385 записей о невозможности подключения к MySQL; основные пики приходились на два августовских дня. Это число записей ошибок, не число атак и не число потерянных заказов. По времени часть сбоев совпала с периодом, когда владелец сообщал об атаках, но без метрик сервера и MySQL нельзя однозначно доказать причинную связь.
Для расследования я выделил отдельные проверки: лимиты соединений, PHP workers, состояние базы, перезапуски, обрывы существующих соединений и раннюю инициализацию модуля кэширования. Это уже работа на стыке инфраструктуры, производительности и отказоустойчивости, а не простая настройка CDN.
Небезопасный обработчик данных заказов
В одном из служебных PHP-обработчиков я обнаружил код, возвращавший сведения о заказах без собственной проверки прав доступа. По согласованию было выполнено точечное ограничение функциональности. Позднее безопасные контрольные обращения к обработчику возвращали HTTP 404, а владелец подтвердил работу сайта и тестового заказа.
Важная граница: наличие дефекта не доказывает, что данные покупателей кто-то выгрузил. История происхождения кода и потенциальное использование в прошлом требовали отдельной проверки. В публичном кейсе я не раскрываю пути к обработчику, структуру ответа, архивы исходников и способы его вызова.
Публичный вывод PHP-ошибок и доверие к прокси
Также обнаружились настройки, которые могли раскрывать посетителям служебные диагностические сообщения. Были внесены точечные изменения в рабочие файлы и выполнена первичная проверка заказа и уведомлений. Отдельно проверялась архитектура доверия к сетевым заголовкам и схема доступа к серверу за CDN; инфраструктурные решения согласовываются с хостингом, а детали не публикуются.
Ложные срабатывания WAF в административной панели
При проверке запросов админки нашлось дополнительное осложнение: Cloudflare отправлял некоторые служебные AJAX-запросы на Managed Challenge. Настройку скорректировали, но окончательную приёмку всех административных функций, включая Dashboard, сессии и динамические блоки, нельзя объявлять завершённой без полноценного тестирования владельцем.
Именно поэтому я предпочитаю короткие контролируемые изменения с проверкой, а не замену десятков модулей или полное отключение защиты одним движением.
Результат работы: что подтверждено, а что осталось открытым
| Задача | Результат | Статус |
|---|---|---|
| Фильтрация HTTP/L7 DDoS | Применены адресные правила Cloudflare и ограничения частоты; в одном интервале ≈99% запросов отмечены mitigated | Подтверждено |
| Снижение ручных GEO-блокировок | Вместо постоянных блокировок стран выстроены слои правил под типы запросов | Внедрено |
| Причины 522 | В части эпизодов получено подтверждение ограничений серверного firewall хостинга | Причина конкретных эпизодов установлена |
| Риск экспорта заказов | Точечная защитная заглушка, безопасные маршруты дают 404, первичный тест заказа пройден | Исправление проверено; ретроспектива открыта |
| Полная стабильность origin и MySQL | Определены необходимые проверки сервера и дополнительные входные данные от хостера | Требует продолжения |
| Все функции админки / оплаты | Проведены первичные проверки; после изменений WAF требуется полный сквозной сценарий | Не выдаю за полностью принятое |
Я не обещаю клиенту «сайт больше никогда не упадёт». Такой результат нельзя доказать по одному графику Cloudflare. Зато можно построить управляемую защиту, увидеть её реальные ограничения, устранить конкретные риски и сформировать понятный план следующего этапа.
Какие решения я сознательно не применял
- Не закрывал целые страны без оценки покупателей. География атакующих и коммерческая география магазина могут пересекаться.
- Не блокировал все POST-запросы. Для интернет-магазина это угроза авторизации, заказу и другим действиям.
- Не включал Cache Everything на динамический HTML без проверки. Корзина, сессии и личные данные не должны попадать в общий кэш.
- Не трактовал каждый 5xx как DDoS. Ошибки Cloudflare, PHP, MySQL, сети и firewall требуют разных методов диагностики.
- Не называл подозрительные файлы доказанным взломом. Без журнала происхождения и доступа к историческим событиям это было бы не расследование, а догадка.
Как я работаю, если на ваш сайт уже идёт DDoS-атака
Для похожих задач начинаю не с продажи тарифа Cloudflare, а с симптомов и доступных данных. Сначала выясняю, что именно недоступно и где находится узкое место.
- Быстрая первичная диагностика. Какие ошибки видят покупатели: 403, 429, 500, 520, 522 или 524? Когда начались сбои, какой CMS пользуетесь, какой CDN и хостинг, что уже включали?
- Разбор данных. Аналитика Cloudflare, Security Events, access/error логи, нагрузка origin, сетевые ограничения, следы настоящих пользователей и поисковых роботов.
- Приоритетный план. Отделяю срочные настройки WAF/Rate Limiting от вопросов shared hosting, MySQL, PHP и архитектуры origin. Не смешиваю всё в одну неопределённую задачу.
- Точечное внедрение. Вношу согласованные изменения, фиксирую что было изменено и на каких данных основано решение, сохраняю возможность отката.
- Проверка бизнес-сценариев. Главная, каталог, карточки товаров, корзина, оформление заказа, административные функции, CDN-кэш, поисковые роботы.
- Наблюдение и следующий этап. Если серверная инфраструктура остаётся ограничением, формулирую конкретный запрос хостеру или обоснование перехода на другой тип размещения.
Какие смежные проблемы сайта я также могу закрыть
Нередко DDoS лишь проявляет старые ограничения, но не создаёт их. Поэтому при необходимости разбираюсь с технической частью глубже, не подменяя проверку атаки бесконечным «аудитом всего сайта».
Cloudflare, DNS и CDN
Настройка проксирования, SSL/TLS, WAF, исключений, анализа ошибок и маршрута от CDN до веб-сервера. Подробнее о настройке Cloudflare.
Технические ошибки CMS
Разбор логов PHP, MySQL, HTTP 4xx/5xx, конфликтов кэша, AJAX, сессий и последствий устаревших расширений. При необходимости составляю отдельное ТЗ программисту.
Антибот-защита и качество трафика
Отделение вредоносной автоматизации от реальных пользователей и подтверждённых поисковых роботов, контроль ложных срабатываний.
SEO и индексация после технических сбоев
Проверка robots.txt, XML sitemap, HTTP-статусов, доступности поисковым системам, редиректов и проблем обхода. Технический SEO-аудит.
Например, при отдельной проверке этого магазина были выявлены 404 у sitemap и служебных ресурсов. Эти замечания не объясняют DDoS, но важны для нормального сопровождения сайта и его доступности пользователям и роботам.
Если сайт работает на покупателей из других стран, дополнительно могу подключиться к зарубежному SEO-продвижению: проверить региональную структуру, международные посадочные, локализацию, hreflang, индексацию Google и доступ поисковых роботов через CDN. Это отдельный этап — его не следует смешивать с устранением текущей атаки.
Частые вопросы о защите интернет-магазинов от DDoS
Подходит ли Cloudflare для защиты сайта с посетителями из России?
Для российского массового трафика Cloudflare в роли единственного прокси/CDN сейчас рискован: часть провайдеров ограничивает соединения, из-за чего страницы могут не открываться или загружаться не полностью. Это не означает одинаковую тотальную блокировку во всех сетях. Для аудитории РФ я сначала проверяю доступность из целевых регионов и подбираю подходящий Anti-DDoS/CDN или схему защиты. Рассматриваемый кейс относится к зарубежному магазину, ориентированному на США и Европу.
Можно ли совмещать защиту от DDoS и SEO-продвижение сайта за рубежом?
Да, как последовательные или согласованные направления работ. Защита решает проблемы доступности и фильтрации вредоносного трафика, а международное SEO — семантику, контент, структуру, региональность и индексацию Google. При этом важно не закрывать поисковых роботов правилами WAF и не нарушать доступ к страницам из целевых стран. Подробнее — на странице услуги зарубежного SEO.
Поможет ли бесплатный Cloudflare защититься от HTTP DDoS?
Да, в части сценариев бесплатный тариф позволяет существенно сократить L7-нагрузку за счёт встроенной защиты, WAF и ограничений частоты. Эффективность зависит от типа атаки, поведения сайта и настроек origin. Покупать платный тариф до диагностики не всегда оправданно.
Почему Cloudflare блокирует атаку, а сайт всё равно показывает 522?
Ошибка 522 связана с тем, что Cloudflare не смог вовремя установить соединение с origin. Возможные причины — firewall хостера, недоступный сервер, перегрузка или сетевая проблема. В кейсе роль firewall была подтверждена для отдельных эпизодов.
Что означает ошибка 520 и чем она отличается от 522?
520 обычно означает неожиданное поведение ответа от origin, тогда как 522 — тайм-аут установления соединения. Они не являются синонимами, и причина определяется по логам и времени возникновения.
Почему при защите нельзя блокировать все страны с подозрительным трафиком?
У злоумышленников могут быть IP в странах ваших покупателей. Безразборная геоблокировка повышает риск потери клиентов и не гарантирует прекращения распределённой атаки.
Можно ли настроить WAF так, чтобы не сломались корзина и админка?
Это основная часть качественной настройки: нужны проверки POST, AJAX, сессий, генерации кэша, платежных и административных маршрутов, а также анализ False Positives в Security Events.
Нужен ли VPS/VDS для защиты от DDoS?
Не всегда. Но если shared-хостинг ограничивает доступ к origin, контролю соединений и серверному firewall, возможностей одной настройки CDN может оказаться недостаточно. Решение о переезде принимается по реальным ограничениям и ресурсам.
Работаете только с OpenCart?
Нет. Принципы диагностики Cloudflare, origin, серверных ошибок и фильтрации HTTP-атак применимы и к другим CMS, в том числе WordPress и MODX. Специфичные исключения всегда определяются поведением конкретного приложения.
Что я получу после диагностики?
Разделение подтверждённых фактов и гипотез, список рисков, приоритетный план действий, согласование первоочередных правок и контрольные сценарии проверки. Объём внедрения, работа с хостером и сопровождение оговариваются отдельно.
Нужно сразу присылать FTP, пароли и доступ в Cloudflare?
Нет. Для первого обращения достаточно симптомов, скриншотов, времени инцидента и общих сведений о хостинге и CMS. Доступы передаются только после согласования конкретного этапа, желательно временные и с минимальными правами.
Ваш сайт тоже атакуют или Cloudflare уже подключён, но 520/522 продолжаются?
Напишите, что происходит, и я помогу отделить атаку от проблем хостинга, WAF и CMS. Сначала определим объём диагностики и приоритеты; обещать результат без логов и проверки сервера я не буду.
Кейс обезличен: название проекта, домен, IP-адреса и работающие правила защиты исключены. Показатели относятся к конкретным интервалам 2026 года; результат не является обещанием аналогичной доли фильтрации для каждого сайта.