<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">I am highly suspicious about the content found at the address pointed by the link provided by mex.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Unless I am mistaken, the variable filled by the geo module is not used anywhere else... thus I guess the limiting works OK, but the 'white-list' feature probably does not work, as it was expected/advertised.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">TL;DR: it probably does not work.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br>==========<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Francis gave you an answer which is working. I will try to explain it with other words, hoping you will understand what to do.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">The limit_* modules (req and conn) filter requests based on a variable, which content is used as a key. If you use $binary_remote_addr there, nginx will keep counters per (non empty) each value of the key and limit each of them. In that case, each unique non-empty value is the binary IP address of a client.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Now, you want to exclude clients from that list, so you cannot use it directly. The trick you can use to exclude requests from being limited by the limit_* module is ensuring that requests that should be unlimited provide an empty value for the variable used by these modules.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Since you base your limit_* behavior on IP addresses, you thus need to set an "empty" IP address for whitelisted addresses, so they are unlimited.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">How to get that filtered list? nginx's map module allows you to fill a variable depending on the value of another, used as a key.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">That idea there is that if your key says "should not limit" (or, say, 0), the new variable should be empty, while in all other cases the new variable should contain $binary_remote_addr.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">That gives you the last map Francis provided:<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">map $should_limit $filter {<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"> default $binary_remote_addr;<br> 0 "";<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">}<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">You wanna use the $filter variable on your limiter.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Now, for each request, you want to fill up this $should_limit variable with 0 for unlimited requests and anything else (say, 1) to limit them.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">That is where the geo module kicks in, where you set the default value of the variable it is working on with 1, and put rules matching the white-listed IP addresses associated with the value 0.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Read the answer from Francis in the light of this attempt at explaining it step-by-step.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">The goal of the first part of his message was to explain why this 2-steps process is mandatory, due to limitations in the inner workings of the geo directive.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Hoping to have cleared things a little...<br></div><div class="gmail_extra"><div><div class="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Sun, Dec 21, 2014 at 4:11 PM, ASTRAPI <span dir="ltr"><<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for your replies but i am confused now :(<br>
<br>
Can anyone please try to post:<br>
<br>
What i must add to main nginx config at:<br>
<br>
http { ?<br>
<br>
<br>
and what to add to the nginx domain config file at:<br>
<br>
server { ?<br>
<br>
<br>
Target is to have connections limit per ip 20 and requests limits per ip to<br>
40 and requests burst up to 80 !<br>
<br>
Posted at Nginx Forum: <a href="http://forum.nginx.org/read.php?2,255697,255710#msg-255710" target="_blank">http://forum.nginx.org/read.php?2,255697,255710#msg-255710</a><br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div></div>