NGINX Login Rate Limits: Start with Dry Run, Then Enforce

Scope the rule to your actual application

This example assumes you administer NGINX and can edit its existing configuration. It does not apply unchanged to Apache, LiteSpeed or a hosting panel that generates configuration. Identify the real login route and preserve its existing proxy or FastCGI handling. Our recommended first step is a baseline of normal sign-ins, office users sharing one address and any legitimate automated clients.

Define a shared zone in the http context

The NGINX module reference documents limit_req_zone and request limits. The following rate is a teaching example, not a universal recommendation. Add the zone in the existing http context:

limit_req_zone $binary_remote_addr zone=login_per_ip:10m rate=10r/m;

In the existing location that serves the intended login route, merge these directives without removing the application handler or authentication logic:

limit_req zone=login_per_ip burst=5 nodelay;
limit_req_dry_run on;
limit_req_status 429;

Confirm which client address you are counting

Behind a proxy or CDN, the apparent remote address may be the proxy. Follow the real-IP module documentation and trust only the proxy addresses you actually operate or verify. Accepting arbitrary forwarded headers lets a client influence the address being counted. Resolve this before deciding what the observed rate means.

Validate, reload and observe

The NGINX beginner guide explains configuration testing and reload behavior:

sudo nginx -t
sudo nginx -s reload

In dry-run mode the module records excess requests without enforcing the limit. Review the relevant error log, check real sign-ins and adjust the example values. Test from accounts and addresses you control; avoid sending disruptive traffic to a live service. Keep application-level authentication and abuse controls enabled.

Enforce with a rollback plan

After reviewing the results, change limit_req_dry_run to off, validate and reload. Check that ordinary login works and excess requests receive the intended response. If genuine users are affected, return to dry run or restore the saved configuration while investigating. A per-IP limit is only one signal and can affect shared networks. Keep the decision, test results and owner with the release record. See the secrets guide and DDoS planning article for complementary controls.