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