nginx сброс соединения по превышению limit_req

http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html

Ну я как бы в курсе. Только вот в случае keep-alive-соебинения, соединения с IP адресом который превышает количество запросов в минуту остаётся висеть. А я бы хотел все эти соединения прибивать.

Наеврное, тогда это не к nginx

Почему, что мешает ему закрыть соединение? Да и ничто не сможет соединения корректно закрыть кроме самого nginx или клиента.

Ваш keep-alive timeout. Соединение завершится после окончания лимита последнего запроса. Соединение != запрос.

Да я понимаю, только вот мне кажется логичным отключить от сервера тех, кто превышает лимит и не давать подключиться до тех пор, пока не появится возможность выполнить запрос исходя из лимитов. Но мне хотя бы первое. Но я понял, что в nginx это не сделать.

Может как-то так

Example: Limit Connections Per Second
The following example will drop incoming connections if IP make more than 10 connection attempts to port 80 within 100 seconds (add rules to your iptables shell script)

#!/bin/bash
IPT=/sbin/iptables
# Max connection in seconds
SECONDS=100
# Max connections per IP
BLOCKCOUNT=10
# ....
# ..
# default action can be DROP or REJECT
DACTION="DROP"
$IPT -A INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
$IPT -A INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds ${SECONDS} --hitcount ${BLOCKCOUNT} -j ${DACTION}
# ....
# ..

http://www.cyberciti.biz/faq/iptables-connection-limits-howto/

мне кажется логичным отключить от сервера тех, кто превышает лимит и не давать подключиться до тех пор, пока не появится возможность выполнить запрос исходя из лимитов

На ведь в этом и суть keep-alive. Уменьшаете затраты на установку нового соединения, и тем самым уменьшаете нагрузку на машину. А если keep-alive timeout больше интервала ограничения числа запросов на единицу времени, зачем закрывать соединение и снова открывать? По вашей логике вы будете каждый раз заново создавать соединение. По логике nginx соединение keep-alive вообще может работать неизвестное время в зависимости от активности клиента. Т.е. это N*m-ное кол-во сэкономленных ресурсов на установку N-соединений. Вы конечно можете их прибивать вручную через доп. слой, но в конечном счете вы только потеряете в производительности, но не выиграете.

Тот тоже лимит соединений, а в одном соединении может быть множество запросов.
У меня всё сложнее, я блокирую через iptables совместно с ipset тех, кто злостно превышает лимиты по количеству запросов к контенту, nginx о таких пишет в лог. Вариант очевидный все пакеты проверять в ipset, но хотелось бы уменьшить количество проверок в ipset, для этого бы было достаточно проверять те пакеты которые имеют статус NEW, но возникает проблема, что по уже установленным соединениям могут продолжать насиловать сервер запросами.

Согласен, если нет больше никаких блокировок на уровне ядра. Но я блокирую iptables-ом тех, кто злостно превышает лимиты и там как раз лучше, что бы соединения разрывались, см. предыдущий пост.

Хм, тогда может быть проще и убивать эти соединения на уровне OS? То есть не воркеры, т.к. в вокреке хз сколько их, а сами соединения, утилитами типа tcpkill/killcx/cutter/etc, тем более что данные у вас все есть в логах. На уровне nginx, насколько мне известно, этого не сделать. По-крайней мере я не знаю, а plus версии у меня нет. М.б. в ней и есть такая возможность, но она противоречит логике keep-alive соединений, поэтому маловероятно.

а «return 444» не помогает ?

Похоже почти получается. Закрываются не все соединения, но то, на котором было превышение, похоже закрывается.