Automatic Platform Optimization Enabled & I No Longer See Visitor IP?

Would this be one of the existing two headers, or will there be another? I’m hoping it would be an existing header (X-Forwarded-For), so NGINX can continue to log correct IP addresses.


We will use existing header X-Forwarded-For.



I have already used that setting in WordFence but still, the issue is same.

Same issue here, Since APO all visitor IP’s show as; 2a06:98c0:3600::103
Which is not desired.

What can we do in a Wordpress enviroment (Nginx on my end as webserver) to get the real visitor IP again and keep APO running?

Hope you can resolve this as all related IP-checks will have issues otherwise.

We just released a change that should pass real client IP via X-Forwarded-For header. Please check from your side it works as expected.


Very cool, will let it propogate for a few minutes before checking.
Hope this resolves it but will get back later to confirm either situation.

Sorry to report but it is still not giving the Visitor IP when I tail the log file.

Would be nice if CF kept a public WP APO change log we can follow - similar to CF WAF change log at :slight_smile:

1 Like

Sadly it is now working yet it seems.

We cleared every thinkable cache there is but
Multiple plugins / logs etc still see the mentioned IP.
Detected IP: 2a06:98c0:3600::103

Just to make sure this has all to do with APO;
I disabled the Cloudflare plugin on WP end.
Disabled APO from within Cloudflare CP.
Cleared all the caches again.

And tadaaa it works again for everything in Wordpress.

I would love to use the APO service but this is dealbreaker in so many forms. (Security for one but also various other IP related checks will simply not work at the time).

I do hope you get this resolved, and will be monitoring this ticket for future updates.

1 Like

Yep same.
Until this gets resolved APO is unusable for me.

Hello @yevgen

Please check these two screenshots and let me know shall I go ahead with - Use the X-Forwarded-For HTTP header. Only use if you have a front-end proxy or spoofing may result


With this one:

I think Use the X-Forwarded-For HTTP header. Only use if you have a front-end proxy or spoofing may result option is good to go, please advise.


Currently Both CF-Connecting-IP and X-Forwarded-For headers are not sending real client IP when APO is enabled. We are working on a fix, ETA for the release is Wednesday.


Thanks Yevgen for the update and sorting this out. And great feature - a big thanks to your team for creating it!

It does not seem to be working. How do I know… just about had a heart attack when I received an email stating someone with an IPv6 email address logged into my website, and even though I just logged in… from an IPv4 address… spent the last 20-minutes a little “upset” and concerned and checking into things… but noticed quickly the IPv6 address was a Cloudflare one (which made me wonder about the VPN stuff, and if someone was using it to hack)

Just rebumping as it’s Wednesday

I hope it will be fixed today.

If it’s any help, I’m finding this passes along an IPv6 address even when the client from which I’m connecting definitely has none.

The server upon which I’m running the cloudflare plug-in also doesn’t not have an IPv6 address, though Obviously I understand that’s not an issue.

Anyway, I hope that helps, and I hope we’re still on for a fix.

Thanks for all your work!

from @yevgen that IPv6 address is the Cloudflare IP used for the CF Worker subrequest

correct, we have a fix for this, pending a release to go it live.


Got it! Now I get the real user’s IP! Thank you.

1 Like