Hi everyone,
I’m running into a serious issue with brute-force protection on my AlmaLinux server after moving to an Nginx -> Apache -> PHP-FPM stack on CWP.
The problem is that all access requests to my panel subdomains (e.g., cpanel.some-domain.com) are logged in /usr/local/cwpsrv/logs/access_log as 127.0.0.1. Since Nginx acts as a reverse proxy, the backend (cwpsrv) sees the localhost IP instead of the client's real IP. Consequently, CSF/LFD cannot detect or block brute-force attacks, as it cannot see the actual source of the requests.
Key Technical Details:
Access Logs: Even with incorrect passwords, the requests return a 200 OK status, not a 401/403 error.
Example: 127.0.0.1 - - [09/Jun/2026:09:34:27 +0200] "POST /login/index.php?acc=validate HTTP/1.0" 200 70 ...
Missing Error Logs: I noticed that there are no entries in any error logs (including /var/log/secure or cwpsrv error logs) when a login fails. It seems cwpsrv handles authentication internally without triggering standard system-level auth logs.
Inconsistency: Regular websites hosted on the same server have their logs correctly populated with real client IPs (so Nginx is likely forwarding headers like X-Forwarded-For correctly).
My Questions:
How can I make cwpsrv log the real client IP (passed via X-Forwarded-For) so that LFD can parse it?
Since the failed login returns a 200 OK status, does LFD have a mechanism to parse the application-level response or "validate" string to trigger a block, even if the IP is hidden behind a proxy?
Is there a configuration in cwpsrv to enable "Real IP" support similar to how Apache/Nginx handle it?
Any insight on how to restore brute-force protection for the panel subdomains would be greatly appreciated!