Wordpress Wordfence Remote IP error

We have cloudflare pro on our domain
We use Cloudflare as our main DNS
We proxy everything
We WordPress installed on that domain and several subdomains of that domain
Wordfence (free) installed on ALL WP sites
The Cloudflare Plugin is installed on every site
ALL our sites pass the cloudflare diagnostics test

Continuously see this error from wordfence:

“This site is currently using the X-Real-IP HTTP header, which should only be used when the site is behind a front-end proxy that outputs this header. This site appears to be behind Cloudflare, so using the Cloudflare “CF-Connecting-IP” HTTP header will resolve to the correct IPs”

Which does not appear to make any sense, as we proxy everything thru Cloudflare? Looking for insights on this :slight_smile:

Joe C.

That makes perfect sense to me. You’ve set Wordfence to use x-real-ip, but you should be using cf-connecting-ip. Wordfence will automatically fix that for you if you click the button with that message.

One would think - but made no such setting. And when you let wordfence ‘fix it’, it says the error is still there, and we start seeing other errors in the logs about IP’s. It’s like an infinite loop. very bizarre. Wordfence claims Cloudflare setup is not a true proxy, and that is why the error appears.
I don’t think they actually know.

In addition we DO use the setting
RemoteIPHeader CF-Connecting-IP
in Apache to set the headers

So the wordfence error itself is incorrect - we do NOT use x-real-ip in headers

It’s just a bit bizzare :slight_smile:

Please check your options:

One thing I forgot is the server is Plesk and nginx reverse proxy server that runs in front of Apache, but it also doesn’t use x-real-ip but cloudflare

But yes, that IS how we setup Wordfence - have checked 3 times, on every single site. Still gives error. It’s weird :slight_smile:

It’s quite possible something in there really uses the x-real-ip header, and drops the Cloudflare header. Wordfence probably still sees some sort of Cloudflare header in there, hence the warning.

I’d take a look at $_SERVER to see what’s really there. Something like a headertest.php file:

There is a plugin that does that, but I did both

X-Real-IP isn’t used

It does show correct actual IP in [REMOTE_ADDR]

[HTTP_CDN_LOOP] => cloudflare

etc.

Can’t think of anything that would be setting X-Real-IP

It doesn’t sound like [HTTP_CF_CONNECTING_IP] is showing up in the request headers to Apache.

Possibly, yet REMOTE_ADDR is showing the correct IP, not a cloudflare IP :slight_smile:

And the logs have the correct remote IP

I found out recently that Wordfence is pretty insistent about that header if it thinks you’re using Cloudflare. I was experimenting with Transform Rules by removing cf-connecting-ip and Wordfence threw that warning. I believe I tried setting it to use x-forwarded-for and it still didn’t like it.

Not surprised. and we ARE using Cloudflare - but have also set Wordfence to the requested setting. Still error comes.

Oddly, If we had set Wordfence as it requests
but were using X-Real-IP somewhere, I imagine THAT would cause God knows what other issues!

OK, so now we HAVE all the sites set to Use “CF-Connecting-IP”
Guess what?

NOW the Error is REVERSED and says:

This site is currently using the Cloudflare “CF-Connecting-IP” HTTP header, which should only be used when the site is behind Cloudflare. This site appears to be behind a front-end proxy, so using the X-Real-IP HTTP header will resolve to the correct IPs

???

That is just weird. Wordfence says Cloudflare is to blame. But they don’t say HOW

As I’m not clear how Wordfence determines all this, I suggest you dig up all the headers your server receives for a request and then let Wordfence know what you’re seeing. Their detection process might be producing conflicting results.

You might try to reach out to @tcan1337 on Twitter for a bit of above-and-beyond help. If you can’t get a hold of him, let me know and I’ll contact him. As I’ve broken this before, I’m also curious as to how it works.

I have had some issue with Plesk and Wordfence, but only with PHP-fpm and Nginx.

So I switched to PHP-fpm and Apache and worked fine.

Could you check if you can also make a switch in Plesk panel → Hosting settings and try it out?

Plesk panel → PHP seettings:

Domain is using Cloudflare proxy :orange: too.

Wordfence is set to:

  • Use the Cloudflare "CF-Connecting-IP" HTTP header to get a visitor IP. Only use if you're using Cloudflare.

And, I did not even done the below steps on this particular domain:

1 Like

That is a very detailed reply, thank you.
Our site(s) is setup the same way, except that Cloudflare SSL/TLS is set to Full, but not to strict,
even though we have Let’s Encrypt SSL on all domains and subdomains
(we have distinct stand-alone WP on the main domain
and distinct WP installations on some sub-domains of the main.
All are configured identically,and all use Cloudflare DNS servers & DNS)

I may try that :slight_smile:
The whole thing is a bit maddening

  • each setting (cloudflare or X-Real) gives an error to use the OTHER setting
    BOTH settings show the correct (real) IP in Wordfence test (the part that says:

    Detected IP(s): **72[redacted]48
    Your IP with this setting: **72[redacted]48

Which is why the server logs show and PHP show the correct IP’s

It’s a bit insane. I will set all sites to use the "Use the Cloudflare “CF-Connecting-IP” HTTP header to get a visitor IP." setting in wordfence, and hope we have nothing that needs it to be otherwise.

Wordfence needs to add some “AI” to there test & scan :slight_smile:

1 Like

Maybe something being cached as the warning pops-up?

I have had this “cached” pop-up saying the same, while the IP was correct on one domain (but was using cPanel Apache + Wordfence + Cloudflare).

That’s the correct way :+1:

You want to set this to Strict, otherwise the SSL is pretty pointless :slight_smile:

1 Like

I wouldn’t say useless. It still encrypts both ends/both ways - a Let’s Encrypt cert is not a “self-signed”.

We changed from strict - for reasons I don’t remember - months ago. There was some issue cloudflare couldn’t seem to resolve, that went away when we went to just full without strict.

I also don’t think cache issues are involved, as the error persists even after the cache is cleared.