Hız sınırlaması yaparken nginx'i 429 http kodu döndürecek şekilde nasıl yapılandırabilirim?

11

Kısıtlama / hız sınırlaması yaparken nginx'i varsayılan 503 (Hizmet Kullanılamıyor) yerine http durum kodunu 429 (Çok Fazla İstek) döndürecek şekilde nasıl yapılandırabilirim?

Bilginize, nginx HttpLimitReqModule ile ters proxy olarak kullanıyorum. 429 durum kodu için taslak spesifikasyon RFC6585'tir .

Stackexchanged ile ilgili bu (kapalı) soru , error_page yönergesinin kullanılabileceğini göstermektedir. Ancak, ben yok gerçekten bir sunucu sorunu (çok fazla bizi vuracak müşteri) ve sunucu 503 Hizmet döndürmesi gereken varsa bir 429'a dönmek istiyorum.

Herhangi bir öneri?

nginx http-status-code

— adambrod
kaynak

Bilginize, bu özellik için bir geliştirme isteği oluşturdum çünkü 503'leri 429'lara eşlemeden mümkün değil.

— adambrod

19

1.3.15 sürümü ile iyi haber http://mailman.nginx.org/pipermail/nginx/2013-March/038306.html

"limit_req_status" ve "limit_conn_status" yönergelerine sahibiz. Onları sadece Gentoo Linux'ta test ettim (limit_req ve limit_con modüllerinin derlenmesi gerektiğini unutmayın).

Bu ayarlarla, istediğini elde edebileceğini düşünüyorum:

limit_req_status 429;
limit_conn_status 429;

Bunu hızlı bir şekilde doğruladım:

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

Yüksek istek oranı ve nginx'te yapılandırılan sınır nedeniyle yönerge etkinleştirildikten sonra çoğu isteğin başarısız olduğu:

limit_req zone=api burst=15 nodelay;

— vanthome
kaynak

1

.. "ab2" nedir?

— XXL

1

abbir araçtır apache2-utils. abUbuntu üzerinde ama CentOs altında öyle ab2.

— Dieter

1

VBart'ın yanıtı ve diğer yorumlarına dayanarak, en iyi seçeneğin 503 hatalarını 429'larla eşleştirmek olduğu açıktır.

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

Nginx (1.3.x) limit_req ve limit_conn için sadece 503 durum kodu kullandığından, bu iyi bir yaklaşım olmalıdır.

— adambrod
kaynak

bu en iyi seçenek değil . 429 belirli bir kullanım durumudur, 429'u döndürmek için tüm potansiyel 503'leri (hizmet kullanılamaz) eşlemek yanıltıcıdır ve kullanıcılar için geçersizdir. Örneğin, bir müşteri bir 429 görebilir ve bir geri çekilme yeniden deneme mantığı kullanabilir, ancak 503 kısma ile ilgisi yoksa yardımcı olmaz.

— Eddie

0

Nginx, limit_req ve limit_conn dışındaki durumlarda asla 503 döndürmez.

— VBart
kaynak

1

Ah, bu ilginç. Yani, 503'ü 42_ yerine error_page kullanarak değiştirirsem, müşterilere çok fazla istek göndermedikçe asla Çok Fazla İstek söylemeyeceğimi söylüyorsunuz?

— adambrod

Evet, doğru, ancak yalnızca bir istisna dışında, (proxy/factcgi/scgi/uwsgi)_intercept_errorsetkinleştirmediğiniz. nginx.org/r/proxy_intercept_errors

— VBart

Nginx tarafından sunulan uygulamanın 503 döndürmesi de mümkündür, bu da istemcinin uygulamadan gelen nginx veya sunucu hatasından bağlantı sınırı olduğunu görmesini zorlaştırır.

— bbaja42