On Tue, Sep 13, 2016 at 04:07:51PM -0400, c0nw0nk wrote:
Hi there,
> Oh in that case then in didn't work when i tried it with the following
> configuration.
It looks like configuration like this should probably work; but perhaps
some parts were lost in the copy-paste.
However, if you have the chance to test, could you try adding
location = /test {
return 200 "x-forwarded-for=:$http_x_forwarded_for:
cf-connecting-ip=:$http_cf_connecting_ip:\n";
}
the the appropriate server{} block, and running
curl -H X-Forwarded-For:1.2.3.4 -H CF-Connecting-IP:2.3.4.5 http://your-server/test
and seeing what the output is?
If my reading of
https://support.cloudflare.com/hc/en-us/articles/200170986
is correct, I think you should see x-forwarded-for having two values
(I suspect that 1.2.3.4 will be first, despite what that web page says)
and cf-connecting-ip having a value which does not include 2.3.4.5.
If that "single-valued cf-connecting-ip" is true, then you should be
able to omit all of the set_real_ip_from directives without breaking
your config. (And therefore, you will not need to worry about keeping
the list of them up to date.
> limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;
> limit_conn_zone $binary_remote_addr zone=addr:10m;
For what it's worth:
quick tests here show that stock nginx *does* correctly set
$binary_remote_addr to be a compact representation of $remote_addr, even
when real_ip_header is being used. So what you are trying to do, can work.
f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx