<p>Given that this is symptomatic of rate limiting in Nginx in this case, the solution is to configure the <a href="https://www.nginx.com/blog/rate-limiting-nginx/" rel="nofollow noreferrer">rate limiting feature of Nginx to allow this</a></p>

<p>A whitelist could  be created in the configuration to remove ratelimiting from the url generating the traffic.</p>

<p>To follow the <a href="https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/#limiting-the-request-rate" rel="nofollow noreferrer">Nginx documentation</a>, this could be specified as whitelisting an IP.</p>

<p>The current server setup is : </p>

<pre><code>limit_req_zone $binary_remote_addr zone=flood:10m rate=12r/s;
limit_req_zone $binary_remote_addr zone=bot:10m rate=200r/m;
limit_req_status 429;
limit_conn_zone $binary_remote_addr zone=connperip:10m;
limit_conn_status 429;
</code></pre>

<p>This sets up the rate limit on connections. A whitelist can be created as suggested above, by simulating a boolean condition with a key value map:</p>

<pre><code>geo $limit {
    default 1;
    10.0.0.0/8 0;
    192.168.0.0/24 0;
}

map $limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}
</code></pre>

<p>This removes the rate limit (sets it to 0) if the remote address falls into the whitelist:</p>

<pre><code>limit_req_zone $limit_key zone=req_zone:10m rate=5r/s;

server {
    location / {
        limit_req zone=req_zone burst=10 nodelay;
</code></pre>

CC BY-SA 4.0
2018-10-31T13:56:36.360Z
2018-11-03T17:59:27.977Z
2018-11-03T17:59:27.977Z
Bruce Becker
<p>I am using Jmeter to investigate the performance and capacity needs of a few web services. Jmeter sends traffic to the web-facing url (served by Nginx), with a rising rate, to see where the service fails. At the moment, this traffic is generated using a single machine, in the CI/CD pipeline.</p>

<p>Before I can really stress the resources, the web server is responding with <a href="https://http.cat/429" rel="nofollow noreferrer">HTTP 429</a></p>

<p>Is there a way to set data in the header or something to force each connection to be seen as new, instead of being banned by the server?</p>

<p>Edit : specified that the http server is nginx</p>

<testing><resilience-testing><http>
Jmeter simulating traffic and avoiding 429
Bruce Becker
# Jmeter simulating traffic and avoiding 429

(Asked by: username_0 on 2018-10-31)

I am using Jmeter to investigate the performance and capacity needs of a few web services. Jmeter sends traffic to the web-facing url (served by Nginx), with a rising rate, to see where the service fails. At the moment, this traffic is generated using a single machine, in the CI/CD pipeline.

Before I can really stress the resources, the web server is responding with [HTTP 429](https://http.cat/429)

Is there a way to set data in the header or something to force each connection to be seen as new, instead of being banned by the server?

Edit : specified that the http server is nginx

**Tags:** testing, resilience-testing, http


---

## 1 answers

### Answer by username_0 on 2018-10-31. Score: 2 | Accepted answer

Given that this is symptomatic of rate limiting in Nginx in this case, the solution is to configure the rate limiting feature of Nginx to allow this
A whitelist could  be created in the configuration to remove ratelimiting from the url generating the traffic.
To follow the Nginx documentation, this could be specified as whitelisting an IP.
The current server setup is : 
limit_req_zone $binary_remote_addr zone=flood:10m rate=12r/s;
limit_req_zone $binary_remote_addr zone=bot:10m rate=200r/m;
limit_req_status 429;
limit_conn_zone $binary_remote_addr zone=connperip:10m;
limit_conn_status 429;

This sets up the rate limit on connections. A whitelist can be created as suggested above, by simulating a boolean condition with a key value map:
geo $limit {
    default 1;
    10.0.0.0/8 0;
    192.168.0.0/24 0;
}

map $limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

This removes the rate limit (sets it to 0) if the remote address falls into the whitelist:
limit_req_zone $limit_key zone=req_zone:10m rate=5r/s;

server {
    location / {
        limit_req zone=req_zone burst=10 nodelay;


---

