Como configurar o nginx para retornar o código 429 http quando o limite de taxa?

11

Como configurar o nginx para retornar o código de status http 429 (Solicitações em excesso) em vez do padrão 503 (Serviço indisponível) ao limitar / limitar a taxa?

Para sua informação, estou usando o nginx como um proxy reverso com o HttpLimitReqModule. A especificação de rascunho para o código de status 429 é RFC6585 .

Essa pergunta (fechada) no stackexchanged mostra que é possível usar a diretiva error_page . No entanto, não quero devolver um 429 se houver realmente um problema no servidor (não o cliente está nos atingindo demais) e o servidor deve retornar o Serviço 503 indisponível.

Alguma sugestão?

nginx http-status-code

— adambrod
fonte

Para sua informação, criei uma solicitação de aprimoramento para esse recurso, pois não é possível sem mapear todos os 503s para 429s.

— adambrod

19

Boas notícias, com a versão 1.3.15 http://mailman.nginx.org/pipermail/nginx/2013-March/038306.html

temos as diretivas "limit_req_status" e "limit_conn_status". Acabei de testá-los no Gentoo Linux (observe que você precisa ter os módulos limit_req e limit_con compilados).

Com essas configurações, acho que você pode conseguir o que pediu:

limit_req_status 429;
limit_conn_status 429;

Eu verifiquei isso com uma rápida:

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

Na qual a maioria das solicitações falhou após a ativação da diretiva devido à alta taxa de solicitações e ao limite configurado no nginx:

limit_req zone=api burst=15 nodelay;

— vanthome
fonte

1

..o que é "ab2"?

— XXL

abé uma ferramenta de apache2-utils. no ubuntu é, abmas sob CentOs é ab2.

— Diet #

1

Com base na resposta do VBart e em outros comentários, fica claro que a melhor opção é mapear os erros 503 para os 429s.

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

Como o nginx (1.3.x) usa apenas códigos de status 503 para limit_req e limit_conn, essa deve ser uma boa abordagem.

— adambrod
fonte

essa não é a melhor opção. 429 é um caso de uso específico, mapear todos os 503s em potencial (serviço indisponível) para retornar um 429 é enganoso e inválido para os usuários. Por exemplo, um cliente pode ver um 429 e usar uma lógica de repetição de recuo, mas se o 503 não estiver relacionado à limitação, isso não ajudará.

— Eddie

0

O próprio Nginx nunca retorna 503 em casos que não sejam limit_req e limit_conn.

— VBart
fonte

1

Ah, isso é interessante. Então, você está dizendo que se eu substituir 503 por 429 usando error_page, nunca direi aos clientes Solicitações em excesso, a menos que eles realmente estejam enviando solicitações em excesso?

— adambrod

Sim, é verdade, mas com apenas uma exceção, você não (proxy/factcgi/scgi/uwsgi)_intercept_errorsativou. nginx.org/r/proxy_intercept_errors

— VBart 1/13

Também é possível que o aplicativo veiculado pelo nginx retorne 503, o que dificulta o cliente ver se é o limite de conexão do nginx ou o erro do servidor no aplicativo.

— precisa saber é