Фильтрация трафика на Nginx/Apache: где ставить правила, чтобы не ловить мусор в логах
Анализ логов показывает: большинство ошибок в фильтрации возникает не в самом regex, а в точке, где вы пытаетесь его применить. Если задача — отсечь ботов, мусорные рефереры и лишние страны, фильтр должен стоять как можно раньше: на уровне server или location, а не внутри тяжелой backend-логики.
Разберем техническую составляющую реализации. Для Nginx базовый набор — map по User-Agent, referer и geo, затем return 403 или редирект в отдельный контур. Для Apache — mod_rewrite и mod_setenvif, но без фанатизма: сложные цепочки в .htaccess тормозят сильнее, чем помогают. Если фильтрация завязана на IP, держите отдельный список в include-файле, а не размазывайте логику по конфигу.
Проверка цепочки прохождения запроса обязательна: сначала определяем, что видит веб-сервер, потом — что попадает в upstream. Частая ошибка — фильтровать только по Host и забывать про X-Forwarded-For, CF-Connecting-IP или прокси-слой перед сервером. В итоге в логах один IP, а в приложении — другой, и статистика плывет.
Если нужен минимальный рабочий шаблон, строите его так: белый список по ключевым признакам, черный список по очевидному мусору, отдельный fallback для спорного трафика. Не пытайтесь сразу распознать весь мир по одному заголовку — это быстро превращается в театр с ложными срабатываниями.
Конфиг готов, можно деплоить. Дальше только верификация: access/error-log, тестовые запросы с разными UA, прокси и referer, плюс контроль того, куда реально уходит трафик после правила.
Клоакинг: разборы
@cloaking_lab_arb
Фильтрация трафика на Nginx/Apache: где ставить правила, чтобы не ловить мусор в логах
Этот пост опубликован в Telegram-канале Клоакинг: разборы. Подписаться можно по ссылке: @cloaking_lab_arb.