Конспект: limit_req и дырявое ведро

Ограничение частоты - дырявое ведро, а не квота за календарную секунду.

Зона и лимит

# в http:
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# в location:
limit_req zone=login burst=10 nodelay;
limit_req_status 429;

Почему при rate=1r/s из десяти одновременных проходит один

rate - это скорость вытекания. Ведро без burst вмещает один запрос: девять остальных получают отказ немедленно, а не «в течение секунды».

Как внедрять безопасно

limit_req_dry_run on;      # считать и логировать, но не отказывать

Посмотреть по логам, кого бы отсекли, - и только потом включать по-настоящему.

Ловушки джокера

• Одно ведро на все location с этой зоной. Ключ и зона - это состояние, а не свойство location: три limit_req zone=api в разных местах считают вместе.
• Ключ за прокси. Без realip все клиенты придут с одного адреса и получат общий лимит. Никогда не считать по $http_x_forwarded_for - он подделывается.
• 503 вместо 429. Умолчание - 503, а клиенты и мониторинг ждут 429: ставь limit_req_status 429.
• limit_conn - про соединения, а не про запросы: он ограничивает одновременные скачивания, а не частоту.

Что показал стенд

Десять одновременных запросов при rate=1r/s:

Пять одновременных скачиваний при limit_conn 2 - 200 x2 и 503 x3. rate=30r/m - это один запрос раз в две секунды, а не тридцать в начале минуты. max_headers 5: два заголовка 200, двенадцать - 400.

Ловушки джокера

• limit_req в блоке с return 200 не работает: return идёт на фазе rewrite, лимит - на preaccess. Проверять надо на отдаче файла или бэкенде.
• limiting requests пишется на уровне error, delaying request - на warn, и означают они противоположное.
• Ключ из X-Forwarded-For даёт боту новое ведро на каждый запрос; ключ берут $binary_remote_addr после realip с узким списком доверия.
• Пустое значение ключа выключает лимит - на этом строят белые списки через map.
• Большой burst на точке входа бесполезен против перебора: сотня попыток проходит до начала ограничений.