Фильтрация трафика на Nginx/Apache: где режется запрос и как не сломать боевую схему

Фильтрация трафика на Nginx/Apache: где режется запрос и как не сломать боевую схему

Анализ логов показывает: большинство ошибок в фильтрации появляется не в rules, а в точке, где запрос уже сменил контекст — прокси, PHP-FPM, WAF, backend. Проверка цепочки прохождения запроса начинается с простого: реальный IP, X-Forwarded-For, Host, User-Agent, referer, cookie. Если хотя бы один слой читает заголовки «как есть», а другой — через свои доверенные прокси, вы получите расхождение в логике и случайные блоки.

В Nginx базовая схема строится на map, geo, if внутри location и отдельном deny/allow. Для Apache аналогично — mod_rewrite, mod_setenvif, Require. Не смешивайте фильтрацию и рендер: сначала определяем класс запроса, потом принимаем решение. Например, мобильный бот, подозрительный ASN, пустой referer или кривой fingerprint должны уходить в разные ветки, а не в один универсальный 403.

Практика: — доверяйте только своим proxy и жестко задавайте real_ip_header; — пишите правила не по одному признаку, а по набору: IP + UA + URI + cookie; — отдельным контуром логируйте отказы, иначе диагностика превращается в гадание; — не пытайтесь фильтровать все на уровне одного if, это путь к хаосу. В Apache держите тяжелую логику вне .htaccess: она медленнее и хуже контролируется.

Верификация простая: прогоняете тестовый запрос через curl с подменой заголовков, смотрите access/error log и сверяете, где именно сработал блок. Конфиг готов, можно деплоить, если каждый отказ можно объяснить по логам, а не по ощущениям.