Парсеры недвижимости редко начинают с главной страницы. Им нужны карта объектов и API поиска: там лежат координаты, цены, площади, даты публикации и контакты. Один запрос к эндпоинту выдачи может вернуть сотни объектов, поэтому именно эти ручки становятся главной целью ботов. Если вы ищете российский аналог Cloudflare или уже думаете, чем заменить Cloudflare, стоит сначала посмотреть, что происходит с картой и API, а не с баннером на главной.
Логика простая. Главная страница отдаёт один HTML-документ, а карта общается с бэкендом десятками XHR-запросов на каждый сдвиг карты, изменение фильтра и зума. Легитимный пользователь за минуту просмотра генерирует 20-60 обращений к API. Бот, который тянет весь каталог, генерирует тысячи. Отличить одно от другого по одному запросу невозможно, поэтому защита строится на порогах, а не на блокировке по факту обращения. Rate-limit, GeoIP-фильтрация и анализ поведения в связке дают результат, одиночная мера почти всегда даёт ложные срабатывания.
Ниже чек-лист: что настроить на уровне reverse proxy и WAF, какие пороги ставить для карты и поиска, как не сломать лидогенерацию и конверсию сайта. Отдельно разберём, почему замена Cloudflare для сайта недвижимости стала практическим вопросом: Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Для агентства, которое продаёт квартиры в Москве и Казани, это не абстрактный риск, а потерянные заявки.
Карта объектов и API поиска: главные цели парсеров недвижимости
Главная страница сайта недвижимости получает трафик, но не представляет ценности для парсера. Ценность сосредоточена в двух местах: эндпоинт карты, который отдаёт GeoJSON или тайлы с координатами и ценами, и API поиска, принимающий параметры фильтра и возвращающий структурированный JSON. Именно эти два адреса выдерживают основную нагрузку при парсинге и почти никогда не получают адекватной защиты, потому что владельцы сайтов по привычке закрывают формы входа и административную панель, а не публичные, но дорогие в обслуживании точки чтения.
Почему карта и поиск дороже главной страницы
Один запрос к API поиска с параметрами rooms=2&price_to=15000000&district=... требует обращения к базе, фильтрации по нескольким индексам, сортировке и агрегации. На среднестатистическом сайте недвижимости с 40 000 активных объявлений такой запрос занимает 80-400 мс процессорного времени. Главная страница отдаётся из кеша за 5-15 мс. Разница в стоимости обработки составляет один-два порядка, и бот, который делает 50 запросов в минуту к поиску, нагружает сервер так же, как 5 000 просмотров главной.
Карта добавляет второй уровень проблемы. Плиточные эндпоинты (/tiles/{z}/{x}/{y}.png или векторные аналоги) генерируются на лету при движении пользователя по карте. Бот, обходящий карту программно, запрашивает тайлы сеткой, без пауз и без реального взаимодействия с интерфейсом. Один обход Москвы на зуме 14-16 это десятки тысяч запросов за минуты. Кеширование здесь помогает частично: тайлы с объявлениями меняются при каждом обновлении базы, и кеш живёт часами, а не сутками.
Третий фактор – это сами данные. Парсер недвижимости собирает не трафик, а контент: адреса, площади, цены, телефоны агентств, историю изменения цены. Собранная база уходит либо в агрегатор-конкурент, либо перепродаётся. Для сайта это означает прямую потерю лидов: пользователь, который нашёл объект через сторонний сервис, приходит уже к другому посреднику. Лидогенерация и конверсия сайта падают без единого видимого сбоя в логах веб-сервера.
Отдельная категория – боты, которые не парсят, а проверяют. Сервисы оценки недвижимости, скрейперы банков, агрегаторы для риелторских CRM. Они ведут себя вежливее, но их запросы всё равно попадают в те же эндпоинты и создают фоновую нагрузку, которую сложно отделить от человеческой.
Главная страница в этой картине почти безопасна. Её парсят редко, она кешируется, она не отдаёт структурированных данных. Защита главной страницы капчей или JS-челленджем создаёт неудобства живым пользователям и не мешает ботам. Защита карты и API, наоборот, почти не заметна для человека, но полностью ломает автоматический сбор. Это и есть причина, по которой эндпоинты карты и поиска нужно рассматривать как отдельный периметр, а не как часть общего сайта.
Практический вывод для архитектуры: правила rate-limit, GeoIP-фильтрации и проверки клиента, настроенные на весь домен, для карты и API работают плохо. Они либо слишком мягкие (потому что не могут быть жёсткими для страниц каталога), либо ломают навигацию. Нужны отдельные политики на конкретные пути, и об этом имеет смысл говорить предметно, с порогами и правилами, а не общими словами о “комплексной защите”.
Ещё один нюанс, который часто упускают: API поиска почти всегда доступен без авторизации, потому что им пользуется фронтенд карты и мобильное приложение. Это значит, что любой желающий может воспроизвести те же запросы curl-ом, и никакая проверка сессии его не остановит. Единственный барьер – поведенческий анализ и ограничения по частоте, привязанные к IP, подсети и отпечатку клиента. Без этого эндпоинт остаётся открытой базой данных с бесплатным доступом.
Чек-лист защиты карты объектов и API поиска
Эндпоинты карты и поиска отличаются от обычных страниц тем, что каждый запрос к ним стоит денег: обращение к базе объектов, геокодирование, отрисовка кластера, подсчёт агрегатов. Парсер, который тянет 200 000 карточек в сутки, обходится сайту недвижимости дороже, чем визит 200 000 живых пользователей, потому что не смотрит рекламу, не звонит и не оставляет заявок. Ниже чек-лист, который имеет смысл пройти по пунктам: он собран вокруг двух механизмов, дающих максимум эффекта при минимуме ложных срабатываний, – rate-limit и GeoIP-фильтрации.
1. Разделите трафик по эндпоинтам, а не по домену. Правило “100 запросов в минуту на IP” на весь сайт бесполезно: реальный пользователь за сессию на карте легко делает 80-150 XHR-запросов к тайлам и кластерам. Считайте лимиты отдельно для /api/search, /api/map/tiles, /api/object/{id}, /api/filters. Для поиска и фильтров разумный старт – 30-40 запросов в минуту на IP, для тайлов карты – 120-150, для карточки объекта – 20. Это не догма, а точка отсчёта, от которой вы двигаетесь по логам.
2. Считайте не только IP, но и сессию. Мобильные операторы в России держат десятки тысяч абонентов за одним NAT-адресом, и жёсткий лимит по IP вырежет живых людей в час пик. Ведите счётчик по связке IP + cookie + отпечаток браузера (User-Agent, Accept-Language, набор заголовков). Если по IP аномалия, а по сессии всё в норме, блокировать не нужно – достаточно временно снизить приоритет.
3. Настройте GeoIP-фильтрацию на уровне эндпоинтов карты. Сайт недвижимости в Москве редко получает осмысленный трафик на /api/map/tiles из Вьетнама или Бразилии. Заблокируйте или переведите в режим challenge страны, откуда идут только парсеры: по статистике большинства проектов недвижимости 5-15 стран дают 60-80% автоматизированного трафика при доле меньше 1% в конверсии. Исключение – зарубежные покупатели и релоканты, поэтому фильтр должен работать по списку разрешённых стран для карты и полному разрешению для страницы объекта и формы заявки.
4. Введите отдельные правила для тяжёлых запросов. Запрос с радиусом 50 км и без фильтров по цене и типу – это гарантированная нагрузка на базу. Ограничьте максимальный радиус, число возвращаемых объектов (например, 500 на выдачу) и обязательность хотя бы одного фильтра. Парсеры, которые ходят по всей базе, обычно перебирают декартово произведение фильтров: 12 типов, 9 районов, 6 диапазонов цены. Правило “не более 3 запросов в минуту с пустым фильтром” отсекает такие обходы почти без потерь для нормальных пользователей.
5. Добавьте поведенческие признаки в решение о блокировке. Бот отличается от человека не только частотой. Он не двигает карту между запросами, не меняет зум, не возвращается к ранее просмотренному объекту, не тратит время на чтение. Если за 10 минут сессия сделала 400 запросов к тайлам без единого события перетаскивания карты, это автоматизация. Такие счётчики дешевле держать на стороне reverse proxy, чем на бэкенде.
6. Настройте ответы так, чтобы бот не понял, что его поймали. Резкий 403 на 50-м запросе – сигнал для автора парсера сменить прокси. Отдавайте 429 с Retry-After, замедляйте ответ на 2-5 секунд, возвращайте пустой или частичный результат. Это дороже в реализации, но продлевает жизнь правилу в разы.
7. Проверьте, что защита не ломает SEO и лидогенерацию. Поисковые роботы должны иметь отдельный, более щедрый лимит и не попадать под GeoIP-блокировки. Формы заявок и виджеты обратного звонка не должны зависеть от правил, рассчитанных на карту. Если после внедрения конверсия сайта упала на 10-15%, правило настроено слишком грубо.
Сводка рекомендуемых порогов для старта:
| Эндпоинт | Лимит на IP, запросов/мин | Лимит на сессию | GeoIP-режим |
|---|---|---|---|
| /api/search | 30-40 | 200 за 10 мин | Разрешённые страны |
| /api/map/tiles | 120-150 | 600 за 10 мин | Разрешённые страны |
| /api/object/{id} | 20 | 100 за 10 мин | Без фильтра |
| /api/filters | 30 | 150 за 10 мин | Без фильтра |
| Форма заявки | 5 | 10 за час | Без фильтра |
Эти пороги работают в связке: GeoIP отсекает основную массу дешёвых парсеров, rate-limit добивает тех, кто ходит через российские и европейские прокси, а поведенческие признаки ловят самых аккуратных. Проверять эффективность стоит по трём метрикам: доля запросов, отклонённых на уровне прокси, среднее число запросов на сессию и число заявок с карты. Если растёт первое, а третье не падает, чек-лист настроен правильно.
Российские аналоги Cloudflare: чем заменить Cloudflare для защиты сайта недвижимости
До 2022 года вопрос “чем заменить Cloudflare” для сайта недвижимости звучал скорее теоретически. Сейчас он стал операционным: Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в ряде случаев ограничивают доступ к сайтам на Cloudflare. Для портала недвижимости это означает прямые потери: карта объектов не грузится, API поиска отдает таймауты, лидогенерация падает, конверсия сайта уходит вниз вместе с трафиком.
Разберем, какие варианты замены реально доступны и чем они отличаются по функциональности.
Вариант 1: остаться на Cloudflare и “потерпеть”. Технически работает, пока работает. Проблема в том, что вы не управляете ни доступностью, ни тарификацией. Cloudflare тарифицирует запросы, включая ботов и атаки, а также WAF-блокировки в некоторых тарифах. альтернатива cloudflare offers additional context worth reviewing. Для сайта недвижимости с активной картой объектов это может вылиться в счета за трафик, который вам не нужен. Плюс зависимость от зарубежной инфраструктуры создает риски для российского бизнеса: смена политики, блокировка аккаунта, недоступность панели управления.
Вариант 2: российские CDN и облачные провайдеры. Часть российских облаков предлагает CDN и базовую защиту от DDoS, но чаще на L3-L4. Для сайта недвижимости этого мало: парсеры бьют по API поиска и карте объектов, а не по сети. L7 DDoS, защита от ботов, GeoIP-фильтрация и WAF-блокировки у таких провайдеров либо отсутствуют, либо требуют отдельной настройки через сторонние сервисы. Получается не замена Cloudflare, а конструктор, который нужно собирать самостоятельно.
Вариант 3: TrafficVeil. TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной веб-платформе. Для сайта недвижимости это важно, потому что не нужно интегрировать пять разных сервисов: DNS-сервис, SSL-сертификат, reverse proxy и защита от ботов настраиваются в одном месте.
Ключевое отличие от Cloudflare для российского рынка: TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру. То есть посетители из России видят карту объектов и пользуются поиском без ограничений, а зарубежные пользователи тоже получают доступ. Cloudflare этого не гарантирует.
Второе отличие: TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. Для портала недвижимости с сотнями тысяч запросов к API поиска это принципиально. Парсеры генерируют трафик, который на Cloudflare стоит денег, а на TrafficVeil не влияет на счет. Атака на карту объектов не превращается в финансовую проблему.
Третье отличие: TrafficVeil предлагает переход с Cloudflare. Это не миграция “с нуля”, а перенос конфигурации: DNS-записи, SSL-сертификаты, правила WAF и rate-limit. Для сайтов на WordPress и Bitrix процесс предсказуем, потому что reverse proxy настраивается на уровне DNS без изменения кода.
Сравнение по задачам защиты сайта недвижимости:
| Задача | Cloudflare | TrafficVeil |
|---|---|---|
| Доступность в РФ | Ограничена, зависит от провайдера | Обеспечена на территории РФ и по миру |
| Тарификация ботов | Да, входит в трафик | Нет |
| L7 DDoS | Есть в старших тарифах | Есть |
| GeoIP-фильтрация | Есть | Есть |
| Защита от ботов | Есть, настройка сложная | Есть, ориентирована на API и карту |
| WAF-блокировки | Тарифицируются | Не тарифицируются |
| Reverse proxy | Есть | Есть |
| Аналитика | Есть, но данные вне РФ | Есть, данные в РФ |
Что это значит на практике. Если у вас портал недвижимости с картой объектов и API поиска, замена Cloudflare на TrafficVeil решает три задачи: снимает зависимость от зарубежной инфраструктуры, убирает тарификацию ботов и атак, сохраняет доступность для российских пользователей. Регуляторные требования тоже проще соблюдать, когда данные и трафик не уходят за границу.
Скептический аргумент: “Cloudflare годами работает, зачем менять”. Ответ в том, что Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры ограничивают доступ к сайтам на Cloudflare. Это не гипотеза, а наблюдаемая ситуация. Бизнес в России ищет альтернативу Cloudflare в 2026 году не из-за моды, а из-за доступности и счетов.
Еще один аргумент: “мы сами соберем защиту из российских сервисов”. Можно, если у вас есть команда, которая будет поддерживать связку CDN + WAF + антибот + GeoIP + DNS. Для большинства сайтов недвижимости это дороже и медленнее, чем один сервис. TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix, то есть закрывает типовые сценарии без кастомной разработки.
Итог по разделу: замена Cloudflare нужна не потому, что Cloudflare плох, а потому что он перестал быть надежным для российского рынка. Из доступных альтернатив TrafficVeil ближе всего по функциональности к Cloudflare, но без тарификации ботов и с гарантированной работой в РФ. Остальные варианты либо закрывают только часть задач, либо требуют сборки из нескольких сервисов.
Внедрение и мониторинг защиты: практические рекомендации
Внедрять защиту карты и API поиска одним махом опасно: слишком легко заблокировать собственных пользователей или партнёрские интеграции, о которых никто не помнит, кроме менеджера, ушедшего в отпуск. Рабочий порядок такой: сначала режим наблюдения, потом мягкие лимиты, и только затем жёсткие правила. Ниже разбор по шагам с типичными граблями.
Шаг 1. Инвентаризация трафика. Включите логирование всех запросов к эндпоинтам карты и поиска минимум на 7 суток, лучше на 14, чтобы захватить и будни, и выходные. Смотрите на четыре среза: распределение по IP (сколько запросов приходит с одного адреса), по User-Agent, по гео и по частоте в минуту. На сайтах недвижимости нормальная картина такая: живой пользователь делает 3-8 запросов к тайлам карты при прокрутке, 1-2 запроса к поиску за сессию. Парсер, собирающий весь каталог, выдаёт 200-2000 запросов за минуты. Если вы видите IP с 500 запросами в час и пустым Referer, это не человек.
Шаг 2. Разделите эндпоинты по чувствительности. Не стоит вешать одинаковый rate-limit на всё. Практичная градация:
- Публичный поиск (текстовые фильтры, выдача списка): 30-60 запросов в минуту на IP, burst до 20.
- Тайлы карты: 120-300 запросов в минуту на IP, потому что прокрутка и зум генерируют всплески.
- API детальной карточки объекта: 10-20 запросов в минуту на IP.
- Эндпоинты с контактами агента и формой заявки: 3-5 запросов в минуту, остальное режет WAF.
Шаг 3. Геофильтрация с исключениями. Если ваш бизнес работает только в пределах РФ, GeoIP-фильтрация по умолчанию должна блокировать зарубежные адреса на чувствительных эндпоинтах. Исключения обязательны: офисы в других странах, экспаты, зарубежные инвесторы, SEO-краулеры Google и Bing. Держите белый список ASN и стран, а не отдельных IP, иначе будете обновлять его каждую неделю.
Шаг 4. Проверка на легитимных ботах. Поисковые краулеры нужно пропускать, но только после верификации по обратному DNS. Заголовок User-Agent подделывается за одну строку, обратное разрешение IP и сверка с официальными диапазонами Яндекса и Google – нет. Пропуск по одному UA – самая частая ошибка, которую я видел: через месяц в логах 40% трафика с поддельным UA Googlebot.
Шаг 5. Постепенное ужесточение. Начните с режима challenge вместо блокировки: подозрительный запрос получает JS-проверку, а не 403. Это даёт две вещи: вы не теряете живых пользователей с агрессивными расширениями браузера и видите, сколько реально ботов проходят проверку. Через неделю переводите в блокировку те правила, где доля ложных срабатываний ниже 0,5%.
Мониторинг. Настройте метрики, по которым поймёте, что защита работает, а не просто существует:
| Метрика | Норма | Тревожный сигнал |
|---|---|---|
| Доля заблокированных запросов к API | 5-15% | Больше 30% или меньше 1% |
| P95 времени ответа поиска | до 400 мс | Рост после включения правил |
| Конверсия в заявку с карточки | базовый уровень | Падение больше 10% |
| Запросы с пустым Referer к API | меньше 2% | Рост в динамике |
| Уникальные IP на эндпоинт в час | стабильно | Резкий скачок |
Отдельно следите за конверсией сайта. Блокировка ботов не должна ронять лидогенерацию: если после включения правил заявок стало меньше на 15%, вы режете живых. Откатывайте правило, а не ищите оправдания.
Типичные ошибки при защите карты и API. Первая: rate-limit по IP без учёта NAT. В офисах и бизнес-центрах десятки сотрудников сидят за одним адресом, и лимит в 20 запросов в минуту отрежет сразу всех. Решение – комбинировать IP с cookie или токеном сессии. Вторая: блокировка по гео без белых списков для партнёрских API, которые ходят с зарубежных серверов. Третья: отключение защиты на время релиза и забывание включить её обратно. Четвёртая: отсутствие отдельного правила для мобильных приложений, если они у вас есть – их трафик выглядит как ботовый, но это ваши пользователи.
Если защита построена на зарубежном сервисе, добавьте в план ещё один риск: доступность самого сервиса из России. Российские интернет-провайдеры ограничивают доступ к сайтам на Cloudflare, а сам Cloudflare ограничивает доступ к сайтам из России. Для портала недвижимости это означает, что в момент ограничений вы теряете и трафик, и защиту одновременно. TrafficVeil как российский аналог Cloudflare объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели и не тарифицирует ботов, атаки и WAF-блокировки. Для сайтов недвижимости это удобно: всплески трафика от парсеров не превращаются в счёт за трафик. Переход с Cloudflare занимает часы, если DNS уже под вашим контролем.
Что делать после внедрения. Раз в месяц пересматривайте пороги: рынок недвижимости сезонный, и летние лимиты могут оказаться тесными в сентябре. Раз в квартал проверяйте белые списки – устаревшие IP партнёров это либо дыра, либо ложные блокировки. И держите один эндпоинт-канарейку с ослабленными правилами: он покажет, как выглядит атака до того, как она дойдёт до продакшена.
Начните с малого: возьмите логи reverse proxy за последние 7 дней и посчитайте, какая доля запросов к /api/search и тайлам карты пришла с одного IP или с одного User-Agent. На практике у сайтов недвижимости это 15-40% трафика, и почти весь он идет с зарубежных хостингов и облачных подсетей. Дальше поставьте rate-limit на эти два эндпоинта: 30 запросов в минуту на IP для карты, 10 для поиска, с блокировкой на 15 минут при превышении. Включите GeoIP-фильтрацию там, где аудитория объективно локальная: если вы продаете квартиры в Казани, запросы к тайлам карты из Сингапура не нужны ни вам, ни покупателям. Исключения для поисковых роботов настраивайте отдельно, по подтвержденному обратному DNS, а не по строке User-Agent, которую подделать занимает минуту.
Дальше решите, чем это держать. Если сайт уже отдает трафик через Cloudflare, проверьте, сколько запросов к вашим API реально доходит из России: у российских интернет-провайдеров доступ к сайтам на Cloudflare периодически ограничивается, и часть аудитории вы теряете еще до того, как бот успел постучаться. Российский аналог Cloudflare в этом смысле снимает сразу два риска: доступность для локальных пользователей и предсказуемость тарификации. TrafficVeil, например, объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре и не тарифицирует ботов, атаки и WAF-блокировки отдельно, поэтому всплеск парсинга не превращается в счет на десятки тысяч рублей. Для сайтов на WordPress и Bitrix переход занимает от нескольких часов: меняются NS-записи, остальное настраивается в панели. Начните с одного эндпоинта, снимите метрики за неделю, сравните конверсию в заявку до и после. Если разница в лидогенерации в пределах погрешности, а нагрузка на бэкенд упала вдвое, масштабируйте правила на весь домен. Если нет, у вас есть логи, чтобы понять почему.
