История реанимации наркологической клиники

Считаем время и деньги. Как 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 недели раньше, чем это станет заметно по визитам

ГЛАВНОЕ ПРАВИЛО:

Считайте падение органики многофакторным, пока не доказано обратное.

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

И зачем я это всё пишу

Для наркологии цена такой недели простоя выше, чем для среднего интернет-магазина.

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

Инфраструктурный аудит здесь — не техническая гигиена.

Это часть той же ответственности, что и лицензия на медицинскую деятельность.

33