Hi Luke,
Ok, I know I said I would take this over to Github, but actually since the thread contains a fair amount of information regarding proxy caching, and other people may find the discussion useful, I thought I would just finish up my commentary here.
@maelga kind of jumped in there with an issue specifically related to Cloudflare (no problem, but actually off-topic).
The particular issue I have been dealing with has nothing to do with Cloudflare, although the backend symptom is similar, in that proxy caches use the last address from which the request was forwarded, and this results in the Stream reporting all activities from the server IP address rather than the true origin.
In terms of Cloudflare, it does also use proxy caching so it is similar in that the incorrect IP addresses are being picked up because the origin headers are not being forwarded without further configuration of the server directly (or the server via php).
There is a ton of information, and plugins available to forward the headers for Cloudflare. One would also hope that being Cloudflare it will be much more difficult to spoof the X Forward headers.
Moving away from Cloudflare now, since it doesn’t have any relation to my own situation. I also tested Stream on another server which only uses Nginx as the frontend reverse proxy, and it seems to work natively without any issue.
The problem I encountered seems to be specific to using Varnish as a reverse proxy, although it might be that it is a combination of the chained reverse proxy which is using both Nginx and Varnish as the proxy cache. I have not had time to test it using Varnish only.
In particular, the host server I have been working on uses a cPanel plugin called Apachebooster. This could become a discussion specifically about that, but let’s not go there as this is probably quite an edge case..
Here is a link to some insightful information if it is of interest though:
https://www.cpanelkb.net/apachebooster-cpanel-plugin/
The real cause seems to be that when using Nginx + Varnish in a chain, even if one sets the X Forwarded For headers in WordPress, then the last address in the chain is the one that gets forwarded.
At this point it gets tricky, because in my “special” case I am using this cPanel plugin, and I solved it by using an apache module called mod_reverse_proxy, which is actually a fork of mod_remoteip, and it uses part of the Apache mod_cloudflare module.
So to bring this back to point, I have a strong feeling that if I was only using Varnish, then the problem would have been solved by using the native Apache mod_remoteip.
That’s it from my side for now, I think. I have solved the problem, and it was really quite a weird case.
I should make a couple of last important points though. Mainly, that incorrectly setting X Forwarded For headers can actually be a major security risk, so it is very important to set up trusted IP addresses (meaning your server IP address(es) in the Apache/Nginx/Varnish configuration files, that will used for the forwarding headers.
If anyone else just happens to be using this Apachebooster cPanel plugin, then you cannot use the custom “mod_reverse_proxy” module at the same time as the more traditional “mod_remoteip” module. It will crash your server.
Finally, you also cannot set “HTTP_X_FORWARDED_FOR” headers in your WP config in combination with either of these modules. This won’t break anything, but it simply won’t work.
