Come configuro nginx per restituire il codice http 429 quando la limitazione della frequenza?

11

Come configuro nginx per restituire il codice di stato http 429 (Troppe richieste) invece del 503 predefinito (Servizio non disponibile) quando si limita la limitazione / velocità?

Cordiali saluti, sto usando nginx come proxy inverso con HttpLimitReqModule. La bozza di specifica per il codice di stato 429 è RFC6585 .

Questa domanda (chiusa) su stackexchanged mostra che è possibile usare la direttiva error_page . Tuttavia, non voglio restituire un 429 se si verifica davvero un problema con il server (non il cliente ci sta colpendo troppo) e il server dovrebbe restituire 503 Servizio non disponibile.

Eventuali suggerimenti?

nginx http-status-code

— adambrod
fonte

Cordiali saluti, ho creato una richiesta di miglioramento per questa funzione in quanto non è possibile senza mappare tutti i 503s a 429s.

— Adambrod,

19

Buone notizie, con la versione 1.3.15 http://mailman.nginx.org/pipermail/nginx/2013-March/038306.html

abbiamo le direttive "limit_req_status" e "limit_conn_status". Li ho appena testati su Gentoo Linux (si noti che è necessario compilare i moduli limit_req e limit_con).

Con queste impostazioni penso che tu possa ottenere ciò che hai chiesto:

limit_req_status 429;
limit_conn_status 429;

Ho verificato questo con una rapida:

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

Su cui la maggior parte delle richieste non è riuscita dopo l'attivazione della direttiva a causa dell'elevato tasso di richieste e del limite configurato in nginx:

limit_req zone=api burst=15 nodelay;

— vanthome
fonte

1

.. cos'è "ab2"?

— XXL

abè uno strumento di apache2-utils. su Ubuntu lo è abma sotto CentOs lo è ab2.

— Dieter,

1

Sulla base della risposta di VBart e di altri commenti, è chiaro che l'opzione migliore è mappare 503 errori a 429 secondi.

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

Poiché nginx (1.3.x) utilizza solo 503 codici di stato per limit_req e limit_conn, questo dovrebbe essere un approccio valido.

— adambrod
fonte

questa non è l'opzione migliore. 429 è un caso d'uso specifico, la mappatura di tutti i potenziali 503 (servizio non disponibile) per restituire un 429 è fuorviante e non valida per gli utenti. Ad esempio, un client potrebbe vedere un 429 e utilizzare una logica di tentativi di back-off, ma se il 503 non è correlato alla limitazione non aiuta.

— Eddie,

0

Nginx stesso non restituisce mai 503 in casi diversi da limit_req e limit_conn.

— Vbart
fonte

1

Ah, è interessante. Quindi stai dicendo che se sostituisco 503 con 429 usando error_page, non dirò mai ai clienti troppe richieste a meno che non stiano davvero inviando troppe richieste?

— adambrod,

Sì, vero, ma con una sola eccezione, che non hai (proxy/factcgi/scgi/uwsgi)_intercept_errorsabilitato. nginx.org/r/proxy_intercept_errors

— VBart

È anche possibile che l'app fornita da nginx restituisca 503, il che rende difficile per il client vedere se è il limite di connessione da nginx o l'errore del server dall'app.

— bbaja42,