Làm cách nào để định cấu hình nginx để trả về mã 429 http khi giới hạn tốc độ?

11

Làm cách nào để định cấu hình nginx để trả về mã trạng thái http 429 (Quá nhiều yêu cầu) thay vì 503 mặc định (Dịch vụ không khả dụng) khi điều chỉnh / giới hạn tốc độ?

FYI, tôi đang sử dụng nginx làm proxy ngược với httpLimitReqModule. Thông số dự thảo cho mã trạng thái 429 là RFC6585 .

Câu hỏi (đóng) này trên stackexchanged cho thấy có thể sử dụng chỉ thị error_page . Tuy nhiên, tôi không muốn trả lại 429 nếu thực sự có sự cố máy chủ (không phải khách hàng đánh chúng tôi quá nhiều) và máy chủ sẽ trả lại 503 Dịch vụ không khả dụng.

Bất kỳ đề xuất?

nginx http-status-code

— quảng cáo
nguồn

FYI, tôi đã tạo một yêu cầu nâng cao cho tính năng này vì không thể thực hiện được nếu không ánh xạ tất cả 503 đến 429.

— adambrod

19

Tin vui, với Phiên bản 1.3.15 http://mailman.nginx.org/pipermail/nginx/2013-March/038306.html

chúng tôi có các chỉ thị "limit_Vq_status" và "limit_conn_status". Tôi vừa thử nghiệm chúng trên Gentoo Linux (lưu ý rằng bạn cần phải có các mô-đun giới hạn numq và giới hạn được biên dịch).

Với những cài đặt này, tôi nghĩ bạn có thể đạt được những gì bạn đã yêu cầu:

limit_req_status 429;
limit_conn_status 429;

Tôi đã nhanh chóng xác minh điều này:

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

Trên đó hầu hết các yêu cầu không thành công sau khi kích hoạt lệnh do tỷ lệ yêu cầu cao và giới hạn được cấu hình trong nginx:

limit_req zone=api burst=15 nodelay;

— vanthome
nguồn

1

.. "ab2" là gì?

— Xxx

ablà một công cụ từ apache2-utils. trên ubfox nó là abnhưng dưới CentOs nó là ab2.

— ăn kiêng

1

Dựa trên phản hồi của VBart và các nhận xét khác, rõ ràng tùy chọn tốt nhất là ánh xạ 503 lỗi thành 429 giây.

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

Vì nginx (1.3.x) chỉ sử dụng 503 mã trạng thái cho giới hạn numq và giới hạn_conn, nên đây là một cách tiếp cận tốt.

— quảng cáo
nguồn

đây không phải là lựa chọn tốt nhất 429 là trường hợp sử dụng cụ thể, ánh xạ tất cả 503 tiềm năng (dịch vụ không khả dụng) để trả lại 429 là sai lệch và không hợp lệ cho người dùng. Chẳng hạn, một khách hàng có thể thấy 429 và sử dụng logic thử lại dự phòng, nhưng nếu 503 không liên quan đến điều chỉnh thì điều đó không có ích.

— Eddie

0

Bản thân Nginx không bao giờ trả lại 503 trong các trường hợp không phải là giới hạn và giới hạn.

— VBart
nguồn

1

Ah, thật thú vị. Vì vậy, bạn đang nói rằng nếu tôi thay thế 503 bằng 429 bằng error_page, tôi sẽ không bao giờ nói với khách hàng Quá nhiều yêu cầu trừ khi họ thực sự đang gửi quá nhiều yêu cầu?

— adambrod

Đúng, đúng, nhưng chỉ với một ngoại lệ, bạn không (proxy/factcgi/scgi/uwsgi)_intercept_errorskích hoạt. nginx.org/r/proxy_intercept_errors

— VBart

Cũng có thể ứng dụng được cung cấp bởi nginx sẽ trả về 503, điều này khiến khách hàng khó nhận ra đó là giới hạn kết nối từ nginx hoặc lỗi máy chủ từ ứng dụng.

— bbaja42