Nginx rush purchase current limiting configuration implementation analysis

Due to business needs, there are often rush purchases, so it is necessary to limit the flow of errors on the load balancing front end. This article also applies to preventing CC.

  limit_req_zone $server_name zone=sname:10m rate=1r/s; #Limit the server to only one successful access per second #limit_req_zone $binary_remote_addr zone=one:3m rate=1r/s; #Limit IP, only one access per second #limit_req_zone $binary_remote_addr $uri zone=two:3m rate=1r/s; #Limit IP and path without parameters,
    #limit_req_zone $binary_remote_addr $request_uri zone=thre:3m rate=1r/s; #Limit IP and path with parameters server {
    listen 80;
    server_name www.abc.com;
    location / {
        include host/proxy.cnf;
        proxy_pass http://backend;
    }
    location /api/createOrder {
        limit_req zone=sname; #No burst, only one normal request limit_req_status 503; #Set the returned status code to 503
        #limit_req zone=sname burst=5 nodelay; #The maximum concurrency is 5, and real-time processing include host/proxy.cnf;
        proxy_pass http://backend;
        error_page 503 =200 /50x.html; #This is very important. You can set the error status code to 503 and return the result as 200
    }
    location = /50x.html {
        if ($http_user_agent ~* "mobile|android|iPhone|iphone|ios|iOS"){
            #default_type application/json;
            return 200 '{"msg": "The event is too popular, please try again later!","data": {},"code": -1}'; #Set the mobile terminal to return an error message display}
        root html; #If it is a PC, return an HTML page}
    }

Key point: Under normal circumstances, if the current limit is set, the status code returned is 503. For the mobile terminal, even if you return JSON data, the client does not recognize it. At this time, you can cleverly set the status code to 200 through error_page 403 =200 /50x.html;

The above only uses the ngx_limit_req_module, and the ngx_limit_conn_module module can also be used.

Reference: https://gist.github.com/simlegate/75b18359316cc33d8e20

Especially if some consulting websites are targeted by crawlers, the server may be killed by the crawlers (this is the case for small websites)
So what can we do? We can use variables to do

#Global configuration limit_req_zone $spider zone=spider:60m rate=200r/m; #Limit the crawler to run 200 times per minute #In a server limit_req zone=spider burst=5 nodelay;
if ($http_user_agent ~* "spider|bot") {
  set $spider $http_user_agent; #Set variables, and limit the speed if you enter here}

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.

You may also be interested in:

Detailed explanation of Nginx current limiting configuration
Detailed explanation of Nginx's connection limit configuration for IP addresses in a network segment
Practical Record of Nginx Current Limitation and Configuration Management

<<: How does Vue implement communication between components?

>>: Cause Analysis and Solution of I/O Error When Deleting MySQL Table