How to use limit_req_zone in Nginx to limit the access to the same IP

Nginx can use the limit_req_zone directive of the ngx_http_limit_req_module module to limit access and prevent users from maliciously attacking and overwhelming the server. The ngx_http_limit_req_module module is installed by default in nginx, so you can configure it directly.

First, configure under the http module in the nginx.conf file

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

Note: The area name is one (custom), the occupied space size is 10m, and the average request frequency cannot exceed once per second.

$binary_remote_addr is the binary format of $remote_addr (client IP), which is fixed at 4 bytes (probably the long type length in C language). $remote_addr is stored as a string, taking up 7-15 bytes. It seems that using $binary_remote_addr can save space, but the Internet says that 64-bit systems all take up 64 bytes. I don’t understand it clearly. Anyway, try to use $binary_remote_addr.

Second, configure it under the submodule server of the http module

location ~* .htm$ {
limit_req zone=one burst=5 nodelay;
proxy_pass http://backend_tomcat;
}

Here I limit the request with URI suffix htm. Note that limit_req zone=one burst=5 nodelay;

Where zone=one corresponds to the previous definition.

The word burst is often referred to as peak value on the Internet. However, through personal experiments, I found that this is not accurate. It should be called the length of the buffer queue.

Nodelay literally means no delay. Specifically, it means that user requests are not delayed but processed immediately. For example, the rate I defined above is 1r/s, which means only one request is processed per second. If two requests with the suffix htm come in at the same time, if nodelay is set, these two requests will be processed immediately. If nodelay is not set, the rate=1r/s configuration will be strictly enforced, that is, only one request will be processed, and then another request will be processed in the next second. Intuitively, the page data is stuck and it takes one second to load.

The configurations that really work for current limiting are rate=1r/s and burst=5. Let’s analyze a specific case below.

At a certain moment, two requests arrive at nginx at the same time, one of which is processed and the other is placed in the buffer queue. Although nodelay is configured so that the second request is processed instantly, it still occupies a certain length of the buffer queue. If no request comes in the next second, the space occupied by the burst length will be released. Otherwise, it will continue to occupy the burst space until the burst space occupies more than 5. Then, further requests will be directly rejected by nginx and a 503 error code will be returned.

It can be seen that if two more requests come in the second second, one of the requests occupies another burst space. In the third second, the fourth second, and the fifth second, two requests come in every second. Although both requests are processed (because nodelay is configured), one of the requests still occupies a burst length. After five seconds, the entire burst length = 5 is occupied. Two more requests came in the sixth second, and one of them was rejected.

This is my inference based on actual test results. It may differ from the real theory, but I think it is easier to understand this way. Anyone who knows the answer is welcome to let me know!

The $binary_remote_addr used here is when there is no proxy layer between the client and nginx. If you configure CDN before nginx, the value of $binary_remote_addr is the IP address of CDN. This is not right to limit the flow. The user's real IP address needs to be obtained for current limiting.

A brief description is as follows:

## Get the original user's IP address here map $http_x_forwarded_for $clientRealIp {
"" $remote_addr;
~^(?P<firstAddr>[0-9\.]+),?.*$$firstAddr;
}

## Limit the original user IP address limit_req_zone $clientRealIp zone=one:10m rate=1r/s;

Similarly, we can use the limit module to limit the flow of web crawlers.

http module

limit_req_zone $anti_spider zone=anti_spider:10m rate=1r/s;

Server module

location / {

limit_req zone=anti_spider burst=2 nodelay;
if ($http_user_agent ~* "spider|Googlebot") {
set $anti_spider $http_user_agent;
}

}

You can test it with curl -I -A "Baiduspider" www.remotejob.cn/notice.jsp

The above method of using limit_req_zone in Nginx to limit the access of the same IP is all the content that the editor shares with you. I hope it can give you a reference. I also hope that you will support 123WORDPRESS.COM.