This isn’t an effective way to block non-Cloudflare traffic unfortunately - anyone can set a CF-RAY header if they want via curl etc. and completely bypass this if they have your origin IP.
To block non-Cloudflare traffic, you need to only allow traffic from Cloudflare either via their IPs, or via a Tunnel, and/or with Authenticated Origin Pull. Depending on what plan you’re on, see the following for more info:
Duplicate headers aren’t really the issue here. The CF-RAY header is simply not a good way to validate Cloudflare requests alone. Anyone can set this header if they know your origin IP. Please review the previous comments and advice you have been given.
Curl is a very popular tool for making HTTP requests - it was just an example I used since it’s one of the most ubiquitous. Any HTTP client will be able to add headers to a request.
I am sorry to hammer this in, but if you can’t have duplicate headers, then why bother having my server parse through a list of IP’s to see if it’s allowed, rather than a single header.
So I guess my question remains, can you have duplicate named headers or not?
Let’s say your server’s IP is 192.0.2.0, and you have your domain example.com protected via Cloudflare. When a user hits example.com and the request then hits your server, it’ll have a CF-RAY header attached, with the CF Ray ID. That’s great.
But then let’s say I find your server’s IP is 192.0.2.0 and decide I want to do something malicious. I could very easily send a request directly to your server IP, bypassing Cloudflare entirely, with my own made up CF-RAY header, and as far as your server would be concerned, I’d be allowed.
This is why validating and ensuring the requests are coming from Cloudflare is important, via the methods that have been previously outlined.
If I understand correclty, might not be related to the topic question or what you’re trying to achieve, but they/it might be merged into one with two (or more) values?, if HTTP header accepts it?.
Likewise, you set it first time, then again with different one in a configuration file, or forget about you’ve set it already since before, then end-up having as the example I’ve had ended-up with was the Website was having (still has got): vary: Accept-Encoding, Accept-Encoding, Cookie
instead of vary: Accept-Encoding, Cookie
or vary: Accept-Encoding, Accept-Encoding, User-Agent
instead of vary: Accept-Encoding, User-Agent
At least what I do see in HTTP headers when I check the particular URL.