Comments 20
а как у вас на одном сервере и .htaccess и Nginx?
А что в этом удивительного? Потребность разносить апач и нжинкс на разные сервера - это уже высоконагруженные сайты...
Давайте я поясню: два веб-сервера - это немного перебор. Вполне хватит и одного. Поэтому наличие Aпача и удивительно. И не очень понятно, откуда вы здесь взяли "высоконагруженные сайты".
Вообще это классика уже на сегодня.
ngnix на входе, за ним апач, который исполняет пхп...
Это было "классикой" 20 лет назад. С тех пор кое-что изменилось, и "Апач, который исполняет пхп" (mod_php) больше не нужен. И как раз "высоконагруженные сайты" никогда не используют Апач с mod_php из-за очевидных проблем с безопасностью и производительностью, a ставят только Nginx, который проксирует динамику напрямую через php-fpm, и Апач здесь просто физически становится не нужен.
А описанная вами конфигурация осталась разве что вот только на хостингах, ради поддержки файла .htaccess, который пользователи РНР искренне считают частью этого языка, и которые замучают техподдержку, если он не будет работать.
^^^ вот! @ipatievабсолютно прав. Апач с mod_php - это совсем не оптимально (а при наличии nginx - попросту не нужно, разве что только тем людям, что без .htaccess - никак, например shared-хостинги).
Осталось чуть чуть. Довести это до разработчиков сайтов и заставить их применять это все правильно )
Вот, свеже развернутый bitrix. nginx+apache. Причем на их виртуалке ) Дальше искать примеры? с высокой степенью вероятности утыкаемся в htaccess, который надо настраивать... А его почему то кроме апача никто и не юзает...
Ещё кейс где таки нужен Апач - легаси сайт/CMS, которая ориентируется на apache в плане обработок url и прочего. И переписывать в эмуляцию конфига nginx с "поведением апача" - очень лень...
Это типичная ситуация для хостинга reg.ru там стоит nginx для статики и проксирования, апач для динамики и директорий с правилами htaccess
Nginx это реверс прокси так это используется для баланса нагрузки это уже база
Да уж, добавлять 10000 строк в файл, который читается заново при каждом обращении к сайты - это было конечно гениальной идеей.
И непонятно, что это за "хостинг", где пользователь управляет веб-сервером и файрволлом.
В целом, очередная история с бодрым заголовком "Я сам ничего не понимаю, ИИ сделал всё заменя", а внутри - бессмысленные метания и снижение нагрузки на 70% (то есть нагрузка всё ещё на порядки больше стандартной) и подписывайтесь на мой канал.
Мда... Не стоит спрашивать ИИ... Стоит поучить матчасть...
Классный кейс. Геоблок и капчи — это временно; надёжнее вынести фильтрацию на периметр (CDN/edge-WAF) и кэшировать, а на сервере включить простые лимиты в Nginx (limit_req/limit_conn) и защитить «дорогие» эндпойнты. Так L7-флуд не добирается до приложения.
Странно, что ИИ не предложил сразу Fail2ban...
Ну и апач тут конечно лишнее. На средненагруженном сайте (50к уников в день) я уже лет 15 использую только Nginx, а последний год - Angie.
Ещё часто DDDoS путают с ботами и сканерами уязвимостей, по логам видно как они ломяться на разные wp-admin, .env и и.д. Достаточно легко блокируются
Встречал такое, часто пытаются загрузить файлы на сервер, войти под logshell и т.д. Не до конца понятно зачем это делать на сайтах, которые особо никто и не посещает. И которые в случае проблем могут просто сбросить или закрыть, если они не используется практически.
Ищут дыры в системе, чтобы потом использовать в составе ботнета...
У меня один и тот же фильтр fail2ban для анализа логов nginx покрывает 90% потребностей на многих серверах. Где-то конечно приходится дописывать, но в целом устраивает. Здесь выкладывал (для себя больше, чтобы не искать каждый раз): https://dzen.ru/a/Z0W9rGxYTnfTW47S
Еще можно как вариант rate limit в angie/nginx настраивать. Но в случае мощных атак спасет только провайдер или ничего не спасет :) Т.к. вряд ли даже на сервак не получится зайти. Но мощные DDDoS стоят денег и вряд ли будут тратится на наши мелкие сайтики
Есть такое. Как говорится, если на вас наслали DDoS - немного порадуйтесь, вы кому-то нужны 😁
Когда IP десятки тысяч или сотни, каждый отправляет 1-2 запроса приведенный по ссылке конфиг не поможет. В этом случае "нужно угадать зоовреда с одного запроса". А если DDoS идёт на легитимную страницу, просто очень большим потоком, то не так просто вычленить ботовый запрос от легитимного пользователя, перешедшего по директу или из поисковика.
Сам по себе способ блокировать на уровне .htaccess не верен в случае ddos. Это все равно потребует серверу обработать запрос и соответственно затратить CPU. Нагрузка возможно и меньше будет, но незначительно. Атакующему пофиг что ему вернёт сервер. Главное занять threads/сокеты/прочие ресурсы. Iptable нужно было изначально применять, но и это решило проблему толком потому что атака на layer 7, в вашем случае https.
По поводу "зачем Apache и ngnix" скажу что это вообще не важно. Загруженный/не загруженный каждый решает сам, что ему проще и удобнее. Тем не мение не понятно, если предложено было блокировать запросы на уровне web servera, то почему сразу не в ngnix раз уж он на "фронте" стоит?
Capcha на мой взгляд вообще бред.
Возможно что если бы ai изначально понял вектор атаки, то решение появилось бы быстрее.
Автор просто поделился идеей , что решение ddos можно передать AI и рассказал что у него получилось.
Миллион IP против одного GPT-5: история одной DDoS-атаки