Як налаштувати nginx для повернення 429 http-коду при обмеженні швидкості?

11

Як налаштувати nginx для повернення коду статусу http 429 (Занадто багато запитів) замість 503 за замовчуванням (Служба недоступна) під час обмеження / обмеження швидкості?

FYI, я використовую nginx як зворотний проксі з HttpLimitReqModule. Специфікація проекту коду статусу 429 - RFC6585 .

Це (закрите) запитання про stackexchanged показує, що можна використовувати директиву error_page . Однак я не хочу повертати номер 429, якщо дійсно є проблема з сервером (якщо клієнт не надто сильно б’є нас) і сервер повинен повертати 503 Сервіс недоступний.

Будь-які пропозиції?

nginx http-status-code

— адамброд
джерело

FYI, я створив запит на вдосконалення для цієї функції, оскільки це неможливо без зіставлення всіх 503s до 429s.

— адамброд

19

Хороші новини з версією 1.3.15 http://mailman.nginx.org/pipermail/nginx/2013-March/038306.html

у нас є директиви "limit_req_status" і "limit_conn_status". Я щойно тестував їх на Gentoo Linux (зауважте, що для цього потрібно зібрати модулі limit_req та limit_con).

За допомогою цих налаштувань я думаю, ви можете досягти того, про що ви просили:

limit_req_status 429;
limit_conn_status 429;

Я швидко це підтвердив:

ab2 -n 100000 -c 55 "http://127.0.0.1/api/v1

На якому більшість запитів не вдалося після активації директиви через високу швидкість запиту та налаштований ліміт у nginx:

limit_req zone=api burst=15 nodelay;

— vanthome
джерело

1

.. що таке "ab2"?

— XXL

1

abє інструментом від apache2-utils. для ubuntu це, abале під CentOs це ab2.

— дієта

1

На основі відповіді VBart та інших коментарів зрозуміло, що найкращим варіантом є зіставлення 503 помилок на 429s.

error_page 503 = 429 /too-many-requests.html

Оскільки nginx (1.3.x) використовує лише 503 коди статусу для limit_req та limit_conn, це повинен бути чудовим підходом.

— адамброд
джерело

це не найкращий варіант. 429 - конкретний випадок використання, відображення всіх потенційних 503 (сервіс недоступний) для повернення 429 є оманливим та недійсним для користувачів. Наприклад, клієнт може побачити номер 429 і використовувати логіку повторного повторного спроби, але якщо 503 не пов'язаний з дроселюванням, це не допоможе.

— Едді

0

Сам Nginx ніколи не повертає 503 у випадках, окрім limit_req та limit_conn.

— VBart
джерело

1

Ах, це цікаво. Отже, ви говорите, що якщо я заміню 503 на 429, використовуючи error_page, я ніколи не скажу клієнтам занадто багато запитів, якщо вони дійсно не надсилають занадто багато запитів?

— адамброд

Так, правда, але лише за одним винятком, який ви не (proxy/factcgi/scgi/uwsgi)_intercept_errorsввімкнули. nginx.org/r/proxy_intercept_errors

— VBart

Можливо також, що додаток, що обслуговується nginx, поверне 503, що ускладнює клієнту можливість бачити, чи це обмеження підключення від nginx або помилка сервера від програми.

— bbaja42