История реанимации наркологической клиники
Считаем время и деньги. Как fail2ban чуть не убил SEO клинике за 2 месяца — разбор
Сегодня — история о том, как самый дешёвый поток лидов чуть не убила банальная настройка файрвола.
Кейс анонимизирован по просьбе клиента: без домена и цифр выручки — только техническая механика и относительные показатели. Речь о медицинской клинике в Москве на WordPress с несколькими десятками региональных поддоменов.
Давай по порядку
Конец мая. Органика из Яндекса начинает падать.К концу июня от месячного объёма остаётся чуть больше половины. Если сравнивать с прошлогодним летним пиком — минус 70%.
Для наркологической тематики это не абстрактная метрика - каждый процент трафика — это человек, который не долистал до формы записи в момент, когда ему реально нужна помощь.
Ну, и что дальше?
Самая простая версия — грешить на алгоритм Яндекса, фильтр или сезонность.
Мы тоже с этого начали.
Разгадка оказалась прозаичнее: часть падения устроил не поисковик, а собственная система защиты сайта, которая несколько дней подряд банила IP-адреса… сервиса защиты от DDoS, стоящего перед этим же сайтом.
Да, сайт сам себе перекрыл кислород.
Как выглядело падение — данные
Трафик из Яндекса терял позиции постепенно ещё с прошлого года. Но в конце мая случился резкий перелом.
Google в этот же период оставался стабилен.
Это сразу сузило круг подозреваемых до чего-то специфичного именно для Яндекса или именно для инфраструктуры — не до общего «сайт сломался».
Параллельно в Яндекс.Вебмастере загорелся диагностический флаг о переизбытке поддоменов в поиске — больше тысячи гео-адресов на одном движке, из которых трафик получали единицы. Это реальная и отдельная проблема. Но темп падения на неё одну не ложился.
Версия первая: тяжёлый рендеринг
Первая гипотеза — самая очевидная технически.
Логи показывали: часть запросов от YandexBot получала HTTP 500 в дни начала падения.
На сайте — задвоенные модули защиты, два генератора карты сайта, первый байт за 1,5-2 секунды.
Убрали дубли, поставили кэш для XML-карты, почистили логи.
500-е ушли. Органика продолжала падать.
Версия вторая: 502 без причины
Настоящей зацепкой стали 502 — периодические, без закономерности.
Хостинг разводил руками.
Проверка каждого слоя ничего не дала:
- Бэкенд отвечал за единицы миллисекунд
- Веб-сервер показывал ноль ошибок апстрима
- Штатная DDoS-защита хостинга не работала уже месяцами
- Живой краулер Яндекса в контрольный день прошёл 1500 запросов без единой ошибки
Вывод неприятный: проблема не в коде и не на сервере. Она выше — на сетевом уровне.
Разгадка
Весь входящий трафик на сайт на самом деле не идёт напрямую.
Он проходит через прокси-сеть внешнего анти-DDoS сервиса.
То есть с точки зрения сервера абсолютно весь трафик — от людей, от Яндекс-бота, от кого угодно — физически приходит с ограниченного набора IP-адресов защиты.
А на сервере тем временем работал fail2ban — стандартный инструмент, банящий «подозрительные» IP.
Один из джейлов реагировал на запросы без нормального User-Agent.
Картина для него выглядела как классическая DDoS-атака.
Логично — заблокировать.
Проблема в том, что эти адреса и были всей входящей магистралью защиты.
Забанив их, сайт сам себе перерезал канал, через который к нему вообще приходит трафик.
Дальше — по цепочке: прокси анти-DDoS пытался достучаться до источника, получал обрыв — и отдавал 502 всем подряд. Включая краулер Яндекса.
Поддержка провайдера защиты подтвердила: сами они трафик ботов не режут. Проблема была целиком на стороне клиента.
Цифры до фикса
До исправления система банила чужие адреса защиты десятками раз в сутки.
По несколько раз в час сайт на несколько минут отрезал себе кислород — ровно на том канале, по которому приходил и поисковый робот.
При чём тут любой сайт с анти-DDoS прокси
Механика воспроизводима на любой похожей инфраструктуре.
Если перед сайтом стоит внешняя защита в режиме reverse-proxy — весь легитимный трафик физически идёт с адресов этого сервиса.
Любой автоматический баннер на сервере (fail2ban, модуль хостинг-панели, самописный rate-limiter) рано или поздно примет узел защиты за атакующего.
Просто потому, что через него идёт весь объём трафика — а не за конкретное вредоносное поведение.
Это самая обидная разновидность даунтайма:
- Не постоянная (то работает, то нет)
- Не видна по одному ручному запросу из браузера
- Хостинг честно говорит «у нас всё зелёное» — и это правда. Проблема выше по цепочке.
Что сделали
Решение техническое, простое — как только причина найдена.
Диапазоны адресов анти-DDoS сервиса добавили в исключения fail2ban.
Действующие баны сняли сразу.
Дополнительно — почасовой мониторинг: если хотя бы один адрес защиты снова попадёт в бан, узнаём раньше, чем это увидят пользователи или поисковик.
Результат — считаем в цифрах
Эффект был виден в течение той же недели.
Количество 5xx-ошибок в статистике обхода Яндекс.Вебмастера ушло в ноль почти сразу.
Недельная органика, упавшая к тому моменту до минимума, за следующие две недели восстановилась в полтора раза — вернувшись к уровню до обвала.
Что вскрылось следом
Убрав главную причину, нашли ещё два слоя.
Слой 1. Часть 404-страниц на самом деле отдавалась с кодом 500 — из-за ошибки в плагине хлебных крошек. Для поисковика это сигнал «страница нерабочая», а не «страницы не существует».
Слой 2. Примерно в те же дни кто-то до нас вручную поправил код темы и случайно вернул статичный заголовок вместо динамического. SEO-плагин продолжал генерировать правильные title — но в HTML они не попадали.
Три независимые причины сработали почти одновременно.
Это и создало резкий обвал графика, а не плавную деградацию.
Чек-лист, если у вас похожая картина.
А также ссылка на мой личный контакт по теме технической диагностики вашего сайта
ШАГ 1: Диагностика
- Хостинг видит только 200, но поисковик и пользователи ловят 502/503? → Проверяйте не свой сервер, а сетевой уровень выше: CDN, анти-DDoS прокси, балансировщик
- Смотрите заголовки ответа на 502-странице (server, x-…) — они обычно прямо называют виновника
ШАГ 2: Проверка защиты
- Внешняя защита в режиме reverse-proxy? → Сверьте официальные диапазоны её адресов с логами бана вашего fail2ban
- Совпадения есть? → Это самая частая причина «необъяснимых» 502
ШАГ 3: Профилактика
- Занесите диапазоны своей защиты в исключения заранее — не дожидаясь падения трафика
- Поставьте мониторинг банов (даже почасовой cron) — регресс не разовый, конфигурации откатываются при апдейтах
ШАГ 4: Мониторинг
- В Яндекс.Вебмастере и GSC смотрите не только график трафика, но и статистику кодов ответа
- Диагностические флаги показывают техническую причину на 2-3 недели раньше, чем это станет заметно по визитам
ГЛАВНОЕ ПРАВИЛО:
Считайте падение органики многофакторным, пока не доказано обратное.
В этом кейсе резкий обвал — три независимые причины сразу. Устранение только одной не дало бы полного восстановления.
И зачем я это всё пишу
Для наркологии цена такой недели простоя выше, чем для среднего интернет-магазина.
Человек, который не смог дозвониться или не увидел рабочую форму записи в момент, когда решился обратиться за помощью — может не вернуться к этой мысли завтра.
Инфраструктурный аудит здесь — не техническая гигиена.
Это часть той же ответственности, что и лицензия на медицинскую деятельность.