¿Cómo configuro nginx para que devuelva el código http 429 cuando se limita la velocidad?

11

¿Cómo configuro nginx para que devuelva el código de estado http 429 (Demasiadas solicitudes) en lugar del predeterminado 503 (Servicio no disponible) cuando se limita o limita la velocidad?

FYI, estoy usando nginx como proxy inverso con el HttpLimitReqModule. El borrador de la especificación para el código de estado 429 es RFC6585 .

Esta pregunta (cerrada) en stackexchanged muestra que es posible usar la directiva error_page . Sin embargo, no quiero devolver un 429 si realmente hay un problema con el servidor (no el cliente nos golpea demasiado) y el servidor debería devolver el servicio 503 no disponible.

¿Alguna sugerencia?

nginx http-status-code

— adambrod
fuente

Para su información, he creado una solicitud de mejora para esta función, ya que no es posible sin asignar todos los 503 a 429.

— adambrod

19

Buenas noticias, con la versión 1.3.15 http://mailman.nginx.org/pipermail/nginx/2013-March/038306.html

tenemos las directivas "limit_req_status" y "limit_conn_status". Acabo de probarlos en Gentoo Linux (tenga en cuenta que necesita tener los módulos limit_req y limit_con compilados).

Con esta configuración, creo que puedes lograr lo que has pedido:

limit_req_status 429;
limit_conn_status 429;

He verificado esto con un rápido:

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

En el que la mayoría de las solicitudes fallaron después de activar la directiva debido a la alta tasa de solicitudes y al límite configurado en nginx:

limit_req zone=api burst=15 nodelay;

— vanthome
fuente

1

..que es "ab2"?

— XXL

abes una herramienta de apache2-utils. en ubuntu lo es, abpero en CentOs lo es ab2.

— dieter

1

Según la respuesta de VBart y otros comentarios, está claro que la mejor opción es asignar los errores 503 a los 429.

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

Como nginx (1.3.x) solo usa códigos de estado 503 para limit_req y limit_conn, este debería ser un buen enfoque.

— adambrod
fuente

Esta no es la mejor opción. 429 es un caso de uso específico, el mapeo de todos los 503 potenciales (servicio no disponible) para devolver un 429 es engañoso e inválido para los usuarios. Por ejemplo, un cliente puede ver un 429 y usar una lógica de reintento de retroceso, pero si el 503 no está relacionado con la aceleración, no ayuda.

— Eddie

0

Nginx nunca devuelve 503 en otros casos que no sean limit_req y limit_conn.

— VBart
fuente

1

Ah, eso es interesante. Entonces, ¿estás diciendo que si reemplazo 503 con 429 usando error_page, nunca le diré a los clientes demasiadas solicitudes a menos que realmente estén enviando demasiadas solicitudes?

— adambrod

Sí, es cierto, pero con una sola excepción, que no ha (proxy/factcgi/scgi/uwsgi)_intercept_errorshabilitado. nginx.org/r/proxy_intercept_errors

— VBart

También es posible que la aplicación que sirve nginx devuelva 503, lo que dificulta que el cliente vea si es el límite de conexión de nginx o el error del servidor de la aplicación.

— bbaja42