Latest EasyApache update and cloudflare config - IP Visitor Lost
Hello,
The latest EasyApache update for mod_remoteip adds a configuration file for Cloudflare that sets the "RemoteIPHeader CF-Connecting-IP" (/etc/apache2/conf.d/includes/cloudflare.conf).
This has caused Apache to stop recording the correct IP when using a local proxy (I use Engintron, for example).
I've always used "RemoteIPHeader X-Forwarded-For" ... as indicated even in the cPanel documentation:
I think this change will cause problems for more than one server administrator who has a proxy in front of Apache.
-
Hey there! You're correct that we did make an adjustment to how that configuration works as part of case ZC-12573.
In general, Cloudflare doesn't use the x-forwarded-for, but if you're using that for the internal IPs that should work properly for any external connection.
If that isn't working as expected, it would likely be best to create a ticket so this can be investigated directly on the server.
0 -
Hello cPRex
The problem, as I see it, originates from the latest update:
ea-apache24-config ZC-12837: Create Cloudflare mod_remoteip configuration.
On our servers we use nginx in front of Apache, so there is no direct connection from Cloudflare. Nginx receives that, and Nginx passes the correct IP to Apache using "X-Forwarded-For." (We use Engintron's nginx implementation, which, by the way, hasn't worked very well for many years.)For now, what we've done is modify the post_virtualhost_global.conf file adding:<IfModule remoteip_module>RemoteIPHeader X-Forwarded-For</IfModule>1 -
David, thanks so much for your last post and knowing what you're talking about and mentioning your quick fix for the broken recent update from cPanel wherein they ZC-12837:"Create Cloudflare mod_remoteip configuration", I agree that is THE source of the problem. Specifically the new always generated file `/usr/local/apache/conf/includes/cloudflare.conf` overrides whatever is currently in `/etc/apache2/conf.modules.d/370_mod_remoteip.conf`. Amazing. And I can't find where to disable this auto generated cloudflare configuration file in the WHM web interface, nor does documentation mention anything - I'm pretty sure there is no place to turn it off currently.
For me I noticed it hit a WHM server minutes after 2025-06-04T22:10:00+00:00. That sounds like the best hack at the moment to re-add contents of <IfModule remoteip_module> block in `/etc/apache2/conf.modules.d/370_mod_remoteip.conf` to `/usr/local/apache/conf/includes/post_virtualhost_global.conf` even though there'll be cloudflare ips still trusted. I for now am taking a gamble that they'll resolve this quickly (so I don't have to come back in and reedit files to fix it back) and emptied the contents of `/usr/local/apache/conf/includes/cloudflare.conf` and then ran `sudo /scripts/restartsrv_httpd` (I know that it's annoyingly auto generated and this is not a long term stable fix, anyone reading is recommended to do what David suggested).
cPanel, no thanks for lost hours AND messing up server function that was based off of REMOTE_ADDR for security among other things. FYI, mod_remoteip has more use than just with cloudflare only. Please administer fix with next update and/or update documentation where to turn off cloudflare remoteip bug.
0 -
The steps outlined in this guide here: https://support.cpanel.net/hc/en-us/articles/360051107513-How-to-restore-visitors-IP-with-mod-remoteip are now totally irrelevant after ea-apache24-config ZC-12837 (which doesn't seem like a wise implementation the way it was done - why not just the option to manually include `/usr/local/apache/conf/includes/cloudflare.conf` in `/etc/apache2/conf.modules.d/370_mod_remoteip.conf` - a very readable/maintainable straightforward approach). If someone followed said guide to setup for cloudflare, then it would "appear" that things are working as expected because the cloudflare.conf would override with pretty similar values.
cPRex, can you please elevate this security issue? This is a security issue. Servers that are depending on the remote IP to be in REMOTE_ADDR will instead find a proxy address - this is the security issue. The servers setup according to this guide will have logs that aren't recording the actual remote IP among other things.
0 -
The changes we made actually fixes the log problem and the env problem:
- The logged IP will be the client w/or without a frontend like cloudflare.
- If a request comes from a client behind a proxy, with the client's IP being 192.168.1.100 and the proxy's IP being 10.0.0.1, mod_remoteip will change REMOTE_ADDR from 10.0.0.1 to 192.168.1.100.
If you believe there is a security issue it would be best to create a ticket as out team is not seeing any security problems after double-checking this today.
0 -
Hi cPRex,
Perhaps I have some misconception about how the RemoteIPHeader parameter works, but the way I see it, you've globally implemented a RemoteIPHeader that's only useful for connections coming from Cloudflare (CF-Connecting-IP is a Cloudflare-specific header), as if they were the only reverse proxy available. For example, what will happen when the connection comes from Akamai, Amazon CloudFront, KeyCDN, or another existing one?Or is it possible to configure more than one RemoteIPHeader depending on who is the RemoteIPTrustedProxy? I understand that no, please correct me if I'm wrong.
Adding a specific configuration for Cloudflare just because we added mod_remoteip in EasyApache seems incorrect to me. It should be an option that the administrator decides whether or not to include.
On the other hand, there is a security issue involved, or at least something that should be noted: With this implementation, if there is an attack/abuse against a website behind Cloudflare (obviously any attack/abuse that Cloudflare lets through), what mod_security will see is the client's IP. So, if we have the firewall configured to block these attacks, the block will have no effect because the connection the firewall will see is that of Cloudflare and not that of the "real" client.
0 -
At this point we'll need to see a ticket on this to examine your specific configuration and situation.
0 -
cPRex, thanks for checking on this and having security team look this security issue. The reported results are hard to believe. Please specify what value did they test with for RemoteIPHeader (that is what this whole thread revolves around). Please have them test with something like `RemoteIPHeader X-Forwarded-For` (i.e. AWS ALB environment). The test is invalid and worthless if done with `RemoteIPHeader CF-Connecting-IP` (i.e. CloudFlare environment).
What is 'the log problem and the env problem' you are referring to? Do you have a link to it? All that was experienced was this fix broke security on a WHM server (cPanel Version 128.0.11, `Apache/2.4.63 (cPanel)`). Also what is the base test environment that is being used: was it upgraded from previous cPanel versions, or fresh install of latest version? What version of Apache?
Do you have any documentation how to turn off `/usr/local/apache/conf/includes/cloudflare.conf` from being always included in `/etc/apache2/conf/httpd.conf`? Please stop this forced action. It is not compatible with https://support.cpanel.net/hc/en-us/articles/360051107513-How-to-restore-visitors-IP-with-mod-remoteip
I agree with David that this is a security issue. Also that it should be the admin's discretion to use `/usr/local/apache/conf/includes/cloudflare.conf`.
David I noticed the same, it seems that RemoteIPHeader overrides any previously set value. What I haven't tried or know is if it can take two values on the same line.
0 -
password1234 - I unfortunately don't have any of that information. It would be best to create a ticket so this can be investigated.
0 -
Hi, folks.
We've got the same problem, we've been using mod_remoteip for years, and suddenly two days ago it has stopped catching the header we've set in our configuration, it is simply ignoring the header parameter.
Now we've manually adjust our proxy to send the header as: CF-Connect-IP to fix the problem and it works, this means the update certainly has an issue and it must be fixed ASAP.
Sincerely,
Fred
1 -
Update - our team was able to identify this issue after a ticket was submitted and we have the following information available with a workaround:
Our team is working on that now and I'll pose an update here once it's officially resolved.
0 -
The developers have also added a way to completely disable Cloudflare integration with the following touchfile:
touch /var/cpanel/no_apache_cloudflare
/usr/local/cpanel/scripts/rebuildhttpdconf
/usr/local/cpanel/scripts/restartsrv_httpd0 -
Hi, folks.
Well this will help, but it was nice when we didn't had to unnecessarily end up doing this of course.
Sincerely,
Fred
1 -
Thanks cPRex for the update and for the support link.
Shocking it's opt-out (backwards breaking) instead of opt-in (backwards compatible, the route I would've expected). I don't understand how the cloudflare update gets so much precedence to force a breaking change to any one who followed https://support.cpanel.net/hc/en-us/articles/360051107513-How-to-restore-visitors-IP-with-mod-remoteip. How are sysadmins who followed this guide going to be notified of the backwards incompatible security hazard that requires immediately opt out action to continue expected behavior?
Likely an update to the guide with these breaking changes and mandatory opt-out actions will be made eventually, and also maybe a "you should've known better than to depend on this remoteip config with priority 370 to always work" haha. Wow non-cloudflare remoteip cPanel servers must be a way smaller group than I realized?
0 -
If you "follow" that guide you'll get notified when there are updates made to it through your email.
0 -
Someone help me get this fixed!
Our application and logs started setting all users as having the same IP (of the server).
After web searching I found this article which sounded exactly like my issue:
https://support.cpanel.net/hc/en-us/articles/360051107513-How-to-restore-visitors-IP-with-mod-remoteipI made the touch file and the custom log settings, nothing changed.
Then I found this thread and someone said that article is obsolete and a new article is addressing this issue now:
https://support.cpanel.net/hc/en-us/articles/32830560745495-mod-remoteip-does-not-show-client-IP-after-2025-June-4Well nothing changed in this article, it just said to make the touch file which is the same as the other article except it doesn't have me change the logging format.
I first went digging into the Nginx config to try and see if the headers are really being passed through and it seems to be the case, from /etc/nginx/conf.d/default.conf:
server {
listen x.x.x.x:80;
server_name $hostname;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://x.x.x.x:8080;
}
}There is another server{} block for :443 that also defines the headers at location /
But then I found this article:
https://docs.cpanel.net/knowledge-base/nginx/the-default-configuration-of-nginx-with-reverse-proxy/It talks about how a file /etc/nginx/conf.d/ea-nginx.conf will be created. I do not have this file at all.
Since this article is older than others, I thought maybe it's outdated info too? But my server doesn't show I'm running "ea-nginx", it just has normal "nginx" so I'm not sure about this issue.
By all accounts it seems like Nginx is going to be setting the header correctly, but I don't know how to test it either.
I have to assume Apache is the problem,
The first article I posted had me set the headers manually in the pre_virtual_host global settings. Since the 2nd article didn't repeat that, I went ahead and removed those custom values so that the only change is the touch file. Still didn't work.
So then I removed the custom logging which seems to only change "%h" to "%a". This didn't fix it either.
Now I'm back to only having the touch file change, which I've verified a hundred times, it's not spelled wrong or in the wrong folder or something.
Next I checked Apache config files. First the /etc/apache2/conf/httpd.conf main file. There is no mention of RemoteIPHeader in there.
I checked the new ea4_main.default config template and it does have this new section that the old default didn't:
[%#
#-------------------#
# CLOUDFLARE CONFIG #
#-------------------#
%]
[% IF !nginx_is_enabled && !file_test( 'f', '/var/cpanel/no_apache_cloudflare' ) -%]
[%
USE ApacheConfig;
SET generated = ApacheConfig.generate_cloudflare_config();
-%]
[% IF generated && file_test( 'f', paths.dir_conf_includes _ '/cloudflare.conf' ) -%]
Include [% paths.dir_conf_includes %]/cloudflare.conf
[% END -%]
[% END -%]This is where no_apache_cloudflare touchfile is being checked and presumably loading the cloudflare config is skipped.
Incidentally, I also see where the new default changes logging from %h to %a:LogFormat "[% IF main.exists('logformat_combined') %][% main.logformat_combined.item.logformat_combined %][% ELSE %]%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"[% END %]" combined
LogFormat "[% IF main.exists('logformat_common') %][% main.logformat_common.item.logformat_common %][% ELSE %]%a %l %u %t \"%r\" %>s %b[% END %]" commonMy old default file used %h here, so it's WHM that is still showing the default as %h:
Just above the cloudflare test is this block:
<IfModule remoteip_module>
RemoteIPHeader X-Forwarded-For-[% cpanel_localhost_value %]
RemoteIPInternalProxy [% wildcard_safe(main.servername.item.servername) %]
[% FOREACH ip IN ips_in_use -%]
[% ip = ip.remove( '^\[' ) -%]
[% ip = ip.remove( '\]$' ) -%]
RemoteIPInternalProxy [% ip %]
[% END -%]
RequestHeader unset X-Forwarded-For-[% cpanel_localhost_value %]
</IfModule>
[% END -%]I'm confused more. I don't really know what this ea4_main.default file does exactly, but whatever this block is doing, it is not making it down to any other config files.The RemoteIPHeader that appears to be set here, is not found in any other config file loaded, so what exactly is it doing? Is something broke or hidden somewhere else? Or does Apache just load this file first and then everything else?
If this logic is working and it really does skip the cloudflare config when the touchfile is present, what's the next step?
I'm confused because none of the /etc/apache2/conf.d/*.conf files are setting the IP header. And none of the additional conf files under /includes sets it either. And yet we're told not to set the header in the pre virtualhost settings! Regardless, with or without the header set there, it still doesn't work for me anyway.
I kept searching for exactly where I'm supposed to put this darn header, and it seems for some people the default is in the module conf itself, which is the 370_mode_remoteip.conf file. I checked a few other servers I run and none of them put the header set informatiion in this module conf. It doesn't seem right.
I've tried both:
RemoteIPHeader X-Real-IP
and
RemoteIPHeader X-Forwarded-ForI think the answer must be staring me in the face and I'm missing one little thing but I don't know what it is. 3 or 4 or 5 different cPanel articles all conflicting and nothing I do works.
Any ideas?
0 -
Hello Zacky
What I'm going to advise you now is what worked for me, after having to correct the configuration on 20 servers after cPanel arbitrarily decided to set "CF-Connect-IP" as the header to use to read the real IP.
Try this: In WHM go to: Service Configuration /Apache Configuration /Global Configuration
sets the log settings to "default"
the, go to: Service Configuration /Apache Configuration /Include Editor
Add this to Post VirtualHost Include
<IfModule remoteip_module>
RemoteIPHeader X-Forwarded-For
</IfModule>then save the changes and restart Apache.
0 -
Well that just pisses me off! haha. Yes, putting it in POST instead of PRE global seemed to do the trick.
cPanel has some answering to do.
1) WHY do we have to put this in the Apache includes if the touch file is suppose to lignore Cloudflare and load a standard configuration?
2) WHERE is this standard configuration loaded if the Cloudflare config is not loaded? Are we meant to add it ourselves manually?
3) WHY do all the (older) articles say to put the RemoteIPHeader in the PRE virtualhost global file if it only works from POST? What is causing PRE to not work? Some other override?
4) Is it the use of the <IfModule> block that makes it work? Cause no examples I found online uses the block for the most part, they just put the inner part alone.
5) WHO is going to pay me back for the 6 hours I wasted trying to figure this out?
0 -
Zacky - can you open a ticket with our team so we can look into all these concerns? These issues are quickly getting outside the scope of what I can do over the Forum, and with the recent changes to this tool I want to have an expert look at the exact values for your machine before I make any recommendations.
0 -
Where would I open a ticket? I don't buy cPanel directly, it just comes with the VPS hosting.
0 -
Zacky - you would contact your host/license provider for any issues and they would escalate the issue to us. However, I've been working with the team this morning to get more details and this is what I've got so far.
MAJOR UPDATE HERE
The recent change as part of ZC-12573 to how Cloudflare remote IPs are handled in cPanel has clearly caused confusion and frustration among users. The update introduced automatic configuration for Cloudflare IP translation, which has led to compatibility issues with existing configurations using mod_remoteip.
Core Issues Identified:
- Unexpected Behavior from Automation:
- The automatic inclusion of Cloudflare rules disrupted existing configurations.
- Users expected a "just works" solution but encountered issues due to assumptions about default Apache behavior.
- Documentation Confusion:
- Some users believed official setup guides were obsolete.
- Clarifications were made that the guides were updated post-feedback, but misunderstandings persisted.
- Technical Misunderstandings and miscommunications:
- Users questioned why configurations had to be added manually if automation was in place.
- There was confusion over the use of PRE vs. POST virtualhost includes—ultimately traced to a documentation typo.
- Backwards Compatibility Concerns:
- The change was opt-out rather than opt-in, breaking existing setups without warning, which is obviously not ideal.
Here's what we’re doing about it
- Fix the automation: Case CPANEL-48150 was filed to make Cloudflare rules opt-in by default, or at least provide a UI toggle to make this process easier.
- Fix the Documentation: Articles were updated to clarify the correct setup process and the role of the touch file to disable automation. At this time I’m not aware of any article that is incorrect so please let me know if you find anything odd at this point. Specifically, we have clarified that mod_remoteip is now installed by default on cPanel servers, which may resolve some user confusion.
- Fix the post_virtual_host confusion: I believe the issue here was just a typo in the documentation that said we should use pre_virtualhost_global when it was supposed to be post_
- Fix the LogFormat: Case CPANEL-48151 was filed to address a UI bug related to the default log format – “Apache configuration in WHM lists different default LogFormat option than the configured default in ea4_main.default template.”
What you should do now
At this point, if you run into anything that isn't working how you expect we really need to see a ticket about it so I can get it over the devs, but once those two cases are resolved I believe we'll have a much better user experience for everyone.
0
Please sign in to leave a comment.
Comments
21 comments