Keeping your Nginx limit_* Anti-DDoS behind CloudFlare's servers

c0nw0nk nginx-forum at
Tue Sep 13 08:51:50 UTC 2016

I was going to do a cookie method but its bad because on browsers with no
cookies that make legitimate requests (first time visitors maybe that don't
have a cookie set) or browsers on legitimate users who disable cookies or
use extensions / add-ons to only whitelist cookies from sites they
specifically allow like facebook, youtube etc.

So that's why I decide to peruse the connection and requests per second /
min limits because it can't be spoofed by the server proxying / making the

It is so easy for me to proxy and spoof those client headers its pretty

proxy_set_header "User-Agent" "custom agent";
proxy_set_header "Cookie" "cookiename=cookievalue";
proxy_set_header "Referer" "";

And my example above is why I am not trusting the client for anything and
want to go with the one thing they can't fake to me their IP.

gariac Wrote:
> ‎What about Roboo? It requires a cookie on the website before the
> download takes place. (My usual warning this is my understanding of
> how it works, but I have no first hand knowledge.) I presume the hot
> linkers won't have the cookie.
>   Original Message  
> From: c0nw0nk
> Sent: Tuesday, September 13, 2016 1:09 AM
> To: nginx at
> Reply To: nginx at
> Subject: Keeping your Nginx limit_* Anti-DDoS behind CloudFlare's
> servers
> So I noticed some unusual stuff going on lately mostly to do with
> people
> using proxies to spoof / fake that files from my sites are hosted of
> their
> sites.
> Sitting behind CloudFlare the only decent way I can come up with to
> prevent
> these websites who use proxy_pass and proxy_set_header to pretend that
> files
> they are really hotlinking of my site is on and hosted by theirs is
> using
> Nginx's built in Anti-DDoS feature.
> Now if I was to use "$binary_remote_addr" I would end up blocking
> CloudFlare
> IP's from serving traffic but CloudFlare do provide us with the real
> IP
> address of users that pass through their service.
> It comes in the form of "HTTP_CF_CONNECTING_IP"
> But when it comes to limiting files that are being hot linked to break
> their
> servers from serving traffic they are stealing from mine I don't know
> if I
> should be using "$http_cf_connecting_ip" or the equivalent with
> "$binary_"
> ?
> limit_req_zone $http_cf_connecting_ip zone=one:10m rate=30r/m;
> limit_conn_zone $http_cf_connecting_ip zone=addr:10m;
> location ~ \.mp4$ {
> limit_conn addr 10; #Limit open connections from same ip
> limit_req zone=one; #Limit max number of requests from same ip
> mp4;
> limit_rate_after 1m; #Limit download rate
> limit_rate 1m; #Limit download rate
> root '//';
> expires max;
> valid_referers none blocked *;
> if ($invalid_referer) {
> return 403;
> }
> }
> So the above is my config that should work I have not tested it yet
> but I
> really wanted to know what the purpose of the "$binary_" on these
> would be
> and if i should make them resemble this. (Not even sure if the below
> is
> correct I am sure someone will correct me if
> "$binary_http_cf_connecting_ip"
> won't work.)
> limit_req_zone $binary_http_cf_connecting_ip zone=one:10m rate=30r/m;
> limit_conn_zone $binary_http_cf_connecting_ip zone=addr:10m;
> Thanks for reading :) looking forward to anyone's better idea's /
> solutions
> and also recommended changes to preventing stealing of my bandwidth on
> these
> kinds of static files that can be up to >=2GB in size.
> Posted at Nginx Forum:
> _______________________________________________
> nginx mailing list
> nginx at
> _______________________________________________
> nginx mailing list
> nginx at

Posted at Nginx Forum:,269502,269506#msg-269506

More information about the nginx mailing list