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        fran...@daoine.org

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Reply via email to