Мне кажется что это некорректная постановка задачи. Роботы - это кормильцы. Резать их неправильно. Вам надо решать задачу с другой стороны - надо чтобы клиент имел некую планку по загрузке системы, и в ней уже мог извращаться как ему угодно. Если совсем никак то проще отказаться от клиента. Это и для него лучше.
Уверен, что он заплатил за раскрутку( чтобы пришли роботы) во много десятков раз больше, чем за Ваш хостинг. И если Вы будете его резать, это неправильно
а у кого какой опыт есть борьбы с поисковыми ботами средствами nginx?
сегодня столкнулись с интересной проблемой - дурной клиент то-ли купил
сервис по seo-оптимизации, то-ли сам где-то научился, но его ресурс
обступили вкруговую поисковые боты.
одновременно 10-15 разных поисковых ботов начали активно индексировать
ресурс. все-бы ничего, но ресурс поднят на базе одного очень дурного
CMS разработчики которого видимо не в курсе что существуют понятия
индексов в БД.
в итоге получился небольшой DOS. сервер выдержал, но 'осадок' остался,
в виде очень нехороших iowait'ов.
хотел-бы узнать кто-как решает подобные наплывы ботов у себя?
закрывать полностью ip-адреса ботов тоже не вариант, т.к. речь идет о
шаред хостинге.
соответственно у меня возникло 2 различные идеи воплощения этой задачи;
1) разрешить только одному боту в одну единицу времени получать свой
честный 200, всем остальным - 503
2) разрешить не более одного коннекта с одного ip-адреса при условии
что user_agent соответствует некому набору бот-шаблонов.
попытался реализовать второй вариант через limit_conn следующим образом:
http {
limit_zone bots $binary_remote_addr 16m;
. . .
server {
if ($http_user_agent ~* "StackRambler|Yandex") {
limit_conn bots 1;
}
}
}
на практике получил облом, т.к. limit_conn не может быть внутри if-а.
какие варианты тут могуть быть?
реализовывал-ли кто-нибудь что-нибудь подобное первому варианту?
у меня вообще не приходят мысли как может выглядеть подобная конфигурация.
