- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Устал от ботов. Интересует некая помощь в организации чуда блокирующего назойливых ботов, может получится создать подобное общими силами.
Что могу сам, но не хочу, т.к. есть проблемы в будущем:
Могу создать систему на основе ipset+fail2ban (скан на брут)+белый список подсетей поисковиков на основе APN. Но проблема, как заверяет Гугл и Яндекс, иногда их IP адреса ботов меняются, добавляются новые. Очень бы не хотелось блочить в prerouting наших уважаемых полезных ботов и в итоге вылетать из поиска, ipset злая штука. Отсюда делаю вывод - способ рабочий на некоторое время. Режим поставил и забыл тут не сработает.. хотя на пару лет думаю хватит.
Что нужно в идеале?
Имеем NGINX. Как известно там есть прекрасная limit_req. Только проблема, у меня поисковые боты настроены так, что сканируют мой сервер по 5-10 запросов в секунду. Сайтов на сервере несколько. Медленно сканировать каждый сайт не вариант. От 10-30 сайтов на одном сервере получится каша в запросах, могут сканироваться равномерно, а могут и сразу 10 сайтов за секунду и иногда будет срабатывать limit_req. Поэтому юзать limit_req без белого списка не вариант.
Как получать такой белый список поисковиков?
Есть только одно предложение: все запросы, возможно на основании логов nginx или в реальном времени сканировать и делать обратный запрос rDNS lookup, но при каждом коннекте брута это будет расточительством. Т.е. нужна некая логика, например, видим что за 1 час было более 100 запросов к бэкэнду (чтобы картинки и и прочая статика там не оказались). Срабатывает burst встроенный в limit_req . Если он срабатывает то отправляем запрос rDNS lookup. Если видим там yandex или google, то сохраняем этот IP в белый список и далее более никогда для этого списка белых IP limit_req не применяем. Также сделать возможность этот белый список подключать к PHP, что будет хуже по скорости но расширит возможности автоматизации.
Сам писать модули для NGINX не умею, умел бы, то не спрашивал, а выложил готовый вариант. Но могу принять участие в помощи для разработки логики и т.п. На крайний случай всё это реализовать на PHP. Вопрос лишь один, будет ли точность в определении rDNS или я так понимаю туда можно записать любой домен и он его отрезольвит как родной? т.е. получится тоже самое что и подмена useragent.
Короче, как вообще определять эти гребаные ip адреса поисковиков, ведь эти неблагодарные ***** почемуто не хотят выкладывать в открытый доступ все свои ip в виде xml списка. Это для меня загадка, ведь списки AS доступны всем, в чем здесь секретность?? ЯНДЕКС ОТВЕТЬ! ЗАЧЕМ ТЫ НАМ СОЗДАЕШЬ НАДУМАННЫЕ ПРОБЛЕМЫ?
А можно тупой вопрос? А зачем?
Я вот вообще установил лимит на количество запросов и всё. Что значит устали от ботов? Сервер грузят что-ли? Там надо настройки делать, кэши подключать на сайты. Если большая посещалка, то наверное сервер надо менять. Возможно банальная замена HDD на SSD решил 95% проблем.
VDS на SSD. Шустрый. Вопросов к нему нет. Но с ростом посещаемости вопрос ботов тырящих контент с сайта растет в прогрессии. В конечном итоге получаем 502..504. Сайт в яндекс вебмастере падает на глазах. Падает в выдаче и понеслось. Лимит на количество запросов не актуален в обычном виде. На сервере куча сайтов, поисковики обращаются к ним на столько часто, что нет никакого смысла в лимитах. Чтобы поставить такой лимит в стандартном виде нужны белые списки ип адресов поисковиков, иначе они первые кто попадут под фильтр.
Дело в том, что я уже попадал в такую ситуацию. Когда количество ботов нагло сканирующих более 50 страниц в секунду растет и в конечном итоге сервер не справляется. Мой случай может достаточно редкий и для когото 150 запросов php страниц это мало (вордпресс на обычном дешевом vds вообще не тянет более 10 страниц в сек). Но и у меня не лэндинг, а портал с более чем 5 млн страниц использующие везде поисковик sphinx. В итоге 300 страниц в сек повесят сервак.
Сейчас rate от единичных ботов+yandex+google составляет примерно 5-15 страниц в сек круглосуточно, при этом load average выше 0.4 не подымается. Но еще пара таких ботов и сервер начнет медленно умирать.
VDS разные бывают.
Какие у вас параметры? На каком движке сайты и сколько посещаемость суммарная?
На VDS один процессор и одно ядро что-ли? Или что для вас эта цифра должна означать? 502 ошибка это апатч, если он там стоит не успевает ответить.
---------- Добавлено 20.01.2017 в 23:37 ----------
Просто понимаете, бывает иногда такое, что проблема кроется не в том, о чём вы думаете и что решаете сделать.
Да как бы с самим сервером и ПО проблем нет, оптимизировать можно до бесконечности. Всё самописное и работает шустрее любых народных движков, в т.ч. фреймворка Yii. Вообще вопросов к части сервера и ПО нет. Я о методе отсеивания ботов в целом. Можно конечно выпендриваться и горизонтально развернуть свои сервера подобно яндексу, вопрос в целесообразности и цене. Когда можно отделаться более простыми решениями и пофиксить лишнюю нагрузку на самом обычном одиночном сервере. Мой на данный момент тянет свыше 2 млн просмотров за 10 часов, но логгер говорит о том, что армия ботов наступает настолько, что моментами нагрузка может в любую секунду превысить.
Если интересно: сервер 2 ядра и 3 гб ОЗУ, остальное на шустрых SSD, в цифрах не помню, но гораздо шустрее моего домашнего kingston KC300 по реальным тестам записи-чтения. Я повторюсь, у меня не 10-100 страниц, а 5 млн, с соответствующей базой MariaDB на движке Aria. Nginx+php5-fpm. Почти все 5 млн страниц используют полнотекстовый двиг по тем же 5млн строкам с сортировкой ASC-DESC, группировкой и JOIN. Программная нагрузка уже более чем приличная, и парадокс, но с ней нормально справился только Debian 8. И каждый бот внаглую сканирующий без паузы между запросами прилично отнимает ресурсов.
Вам сервер менять надо на более мощный.
---------- Добавлено 21.01.2017 в 00:33 ----------
У вас там чисто просмотр идёт, без редактирования, без добавления или удаления?
В основном просмотр. Insert в базу не более 10 тыс в день. Он вприницпе не заметен. Ну и PHP логгер в файл.. 1 запрос=1 запись.
Вы вот просто считаете, что ваша система которую вы себе в голове придумали, ну никак ресурсов не будет жрать. Вы глубоко ошибаетесь, она просто убьёт систему.
У вас очень слабенький сервер для таких работ. Смотрите нагрузку. У вас БД не справляется что-ли или как? Или вы nginx зажали и он не успевает всё обрабатывать? Система кэша файлового хоть какая-то существует?
Сервер справляется, на диск ничего не свопит. Все индексы в ОЗУ. Всё можно сказать идеально. Вопрос то не в этом.
Со временем всё чаще и всё больше боты начинают сканировать сайт и контент со своего сайта вижу на просторах. Вот от них то и есть цель избавиться. Обычные юзеры+гуглоботы вообще не грузят сервер более 2%. Поэтому умощнять сервер с такой посещаемостью нет никакого смысла. У меня цель защитить его от нападков.
3 гб озу и 5 млн., база наверно 5гб+? Как выше сказали берите мощнее сервер, вдс-ми тут не отделаешься, думаю не дороже чем ваш вдс будет https://www.online.net/en/winter-2017/sales
думаю не дороже чем ваш вдс будет https://www.online.net/en/winter-2017/sales
они уже как бы кончились ;D