Even after enabling the IP Geolocation functionality in the Network tab, I am unable to see the “CF-IPCountry” in the response headers of my site.
Also, the CF-Connecting-IP header and the other headers mentioned in that support article are not visible when I check my requests. Do I need to make some settings changes in the Cloudflare dashboard to make those headers visible in the requests?
It’s important to understand that your cURL there is showing HTTP Response headers. The CF-Connecting-IP and CF-IPCountry header are HTTP Request headers.
Keep in mind when Cloudflare is enabled a HTTP request goes like this:
Visitor > Cloudflare > Origin Server
Your origin server will receive the HTTP request headers from Cloudflare. Depending on what scripting technology you use on your origin server, there are different ways of outputting the HTTP Request headers the server receives if you just want to view them for testing. For example with PHP there are a few different ways of doing this:
(I added them from the top of my head, so please check they work before using)
A few things about relying on those request headers.
You need to make sure that you do not allow CF to cache the responses. Otherwise you run the risk of making a response based on the assumed IP or Country, but the second request to the CF server will be served from cache and your Origin logic will not be applied. Cloudflares cache key is Origin Request Header (for CORS), proto, host, path (and perhaps query string if configured), so client IP or country is not relied on for caching.
You need to ensure that the headers have not been spoofed. The best way to do this is using Authenticated Origin Pulls. You can have good assurance that the header has been set by CF, and not by another party you knows where your origin is. (I do not think that firewall rules on the origin are enough, as an attacker could use a Cloudflare account with Host Header Override to get through your firewall rules and send spoofed CF-IPCountry headers)
If you perform caching on your Origin, make sure you include those Headers in the Cache-Key.
Thanks @michael , @tanto259 and @simon for the all the information. This cleared the doubts that I had.
I am new to this and wrongful assumed that those headers would be sent in the response. Thanks for explaining things in detail
My main goal was to pass the visitor IP address to Nginx so that those could be used by fail2ban. I was able to do that now. ( I utilized this as well - How do I restore original visitor IP with Nginx )
Q1. I check the Cloudflare IP’s every couple months, use the NGINX realip module and have rules set in a /etc/nginx.custom.d/realip.conf file, and this has worked fine for years. Now, I see our own origin server address when someone fills out a form and a plugin (this being gravity forms wp) records it incorrectly. This did not happen for years. Otherwise my server logs do record the correct IP’s but the plugin prints out useful data and now I can’t follow it.
Separate note:
It probably would be a better idea if Cloudflare pushed out when these changed (not like they don’t send out millions of emails anyway…).
Q2. So, why did I have 199.27.128.0 in there a while back (and it is a CF ip) and now I see it’s not on the current list? I don’t think I’m crazy but you never know.
@Stuart if you’re seeing your origin server IP and not a Cloudflare IP that sounds like something unrelated to Cloudflare. I would expect if it were Cloudflare related for you to see a Cloudflare IP. Are you running any form of proxy or cache on your origin such as Varnish?
Regarding the IP ranges, these do not change very often, for a feel for this take a look at the change detection log (a 3rd party service) for the IPv4 ranges:
That said, we definitely appreciate giving you better notice of any changes is important and this feedback has been shared internally so we’ll make sure we communicate better in future.