Да никто и не гадает. Это независимо предложил уже второй человек. Причем, вполне вероятно, он как и я исходил из сценария "с кучей сайтов". Ибо если проектов ~10 - ситуация абсолютно точно ненормальная.
Конечно, никто "диагноз" тут вам не ставит - поймите правильно. Может и все в порядке, но на первый взляд - уж больно подозрительно.
Вот это отдельно очень настораживает. Рискну еще раз предположить, что у данного вашего клиента как раз "куча сайтов". Может ваши "алгоритмы" работают сразу для всех скопом - тогда ложные срабатывания совершенно элементарны.
Задумываться надо было с другого конца:
"Вот он мне льет запросов столько, сколько серверу позволено обрабатывать. Я при этом вообще зайти на сервер смогу? Я смогу что-то в консоли сделать (тот же анализ лога вебсервера) - или буду видеть слайд-шоу?"
Не исключено, что это фальшивые срабатывания - вы (или ваши клиенты) теряете просто трафик. Я бы проверил.
А зачем вам адрес шлюза, за которым сидит ихняя секретутка?
Нет проблем, малыш (@dnscache.masterhost.ru):
Жду ответа на заданный ранее вопрос.
Могу (и более того - знаю), но интересует меня - ваша оценка. Пожалуйста, выдайте ее. В абсолютных числах, в процентах - как сумеете, на многое от вас я не расчитываю. Статистику, а не результат отдельной проверки.
И лучше, конечно, в качестве примера брать более типовой сайт, нежели xml.yandex.ru. Надеюсь, сумеете сообразить почему?
Я прекрасно это помню.
Вся проблема - как вы реализуете эту проверку по IP. Я предлагаю - делать так, как написано в документации. Вы - собрать все подсети яндекса из ripe и не париться.
Поясните. Вы думаете, что реально подделать ptr у ip яндекса?!
А что, кроме модераторов и поисковых ботов - там нет и ничего быть не может?
Есть, конечно. Документация.
Ей, народный целитель - я вам диагнозы не выставлял, не надо врать.
Попробуйте сделать симлинк :)
ln -s libmysqlclient.so.18 libmysqlclient.so.12
А вот это зря. Поди, кучу всего еще наломали корявыми ручками. Не пытайтесь решать проблемы наугад - ничего хорошего из этого не выйдет.
Ну "подумайте", удачи. Кто знает, может вам администраторы яндекса на домашний телефон звонят каждый раз, когда приспичит сменить IP очередному боту.
Но для большинства - это тайна. Когда они будут что-то менять в своем пуле, даже когда просто изменят информацию в своем AS (напр., добавят подсеть) - остается только гадать. Странно что это гадание вы назвали "думать".
С чего вдруг? Давайте вы будете доказывать такие спорные утверждения. Я взял из логов достаточно случайного бота - и он оказался в ns.masterhost.ru. и ns.zenon.ru. ЧЯДНТ?
Проверка PTR - не "костыль". А необходимость использования - зависит от задачи. Хочет ТС очередную эвристику или точное решение.
Как вы думаете, сколько по порядку величины занимает времени запрос ptr (не попавший в кэш, конечно)?
whois -i origin AS13238 | grep route | awk '{print $2}'
Наивный малыш. Среди этих IP есть куча тех, которые ровно никакого отношения к ботам. "Абсолютное большинство" (ц).
1) Не всегда.
2) Мне можно.
3) Так круче.
Вы писали "по днс проверять медленно". Но по ссылке речь идет не только о проверке dns.
Ну, вы же хотите достоверно определить робота? IP меняются и, что гораздо чаще - добавляются.
И вызывать его с неизвестной заранее периодичностью.
Ну так это же не обязательно *ваш* запрос.
Вы сами и ответили на свой вопрос. А вообще - у nginx есть perl и lua. Так что отрезолвить $remote_addr не проблема.
Чтобы работали - надо прочитать документацию.
Эта часть у вас правильна - проверяйте что апач получает действительно *ваш ip*, а не ip какого-нибудь прокси, что перед ним стоит (nginx?). Логи доступа смотрите.
1) там есть список UA.
2) "по IP" проверять - вам потребуется тогда поддерживать список этих IP. Проверка PTR позволяет легко избежать такого гемороя. Для "быстро" - DNS умеет кешировать.
Мораль: читай, что тебе пишут до конца, а потом комментируй.
