Guide CyberPanel Behind Cloudflare: Real Visitor IPs and the Setting That Allows Fake IPs

**JAY** · (This post was last modified: 10-28-2026, 04:59 AM by JAY.)

CyberPanel Behind Cloudflare: Real Visitor IPs and the Setting That Allows Fake IPs

When you switch on Cloudflare's orange cloud, visitors no longer connect to your server. They connect to Cloudflare, and Cloudflare connects to you. If the web server doesn't know that, every visitor looks like a Cloudflare IP: in the access logs, in PHP (

Code:

REMOTE_ADDR

), in WordPress comments, in login limiters and in anything that blocks by IP. Many tutorials fix this by switching OpenLiteSpeed's Use Client IP in Header to Yes. We tested on CyberPanel 3.0 (OpenLiteSpeed 2.5.5) and found two things: real IPs already worked without any change, and Yes is the one setting that lets anyone fake their IP.

Step 1: Proxy the site through Cloudflare
In the Cloudflare dashboard, DNS > Records, we switched the A record of our test site

Code:

cyber.adminslab.com

from DNS only (grey cloud) to Proxied (orange cloud):
[Image: attachment.php?aid=582]

Cloudflare then shows Your origin IP address is partially exposed. That's because other records (the

Code:

mail.

record and some test subdomains) still point straight at the same server. You can't proxy mail through Cloudflare, so on a one-server setup with mail the server IP is never fully hidden. Keep that in mind for Step 4: anyone can find your server IP and talk to it directly, without Cloudflare.

The two-level subdomain trap. Cloudflare's free certificate (Universal SSL) covers

Code:

example.com

and

Code:

*.example.com

, one level deep only. Our test site is itself a subdomain, so

Code:

blog.cyber.adminslab.com

is two levels deep.
This is what our server got back when we tried it with a two-level name:
[Image: attachment.php?aid=583]

Code:

curl: (35) ... sslv3 alert handshake failure

: the site was simply dead over HTTPS as soon as it was proxied. Your options: leave such names on DNS only, use a one-level name (

Code:

blog.example.com

), or buy Cloudflare's Advanced Certificate. We set it back to DNS only.

Step 2: Check which IP your site really sees
Put a small test file in the site's folder, for example

Code:

/home/yourdomain.com/public_html/ip.php

:

Code:

<?php $s=$_SERVER;
echo "REMOTE_ADDR=".$s["REMOTE_ADDR"]."\n";
echo "CF=".($s["HTTP_CF_CONNECTING_IP"]??"-")."\n";
echo "XFF=".($s["HTTP_X_FORWARDED_FOR"]??"-")."\n";

Code:
REMOTE_ADDR
is what PHP, WordPress and your logs use as the visitor IP.
Code:
CF
is the
Code:
CF-Connecting-IP
header Cloudflare adds: the real visitor IP.

Open

Code:

https://yourdomain.com/ip.php

in your browser and compare

Code:

REMOTE_ADDR

with your own IP (search "what is my ip"). We tested from the server itself with curl. The request goes out to Cloudflare and comes back, so the "visitor" is our server:

Code:

grep -c useIpInProxyHeader /usr/local/lsws/conf/httpd_config.conf
curl -4 -s -o /dev/null -w 'connected to: %{remote_ip}\n' https://yourdomain.com/ip.php
curl -4 -s https://yourdomain.com/ip.php
tail -1 /home/yourdomain.com/logs/yourdomain.com.access_log

Our results, with the site proxied and nothing changed on the server:
[Image: attachment.php?aid=584]

The request really went through Cloudflare (
Code:
connected to: 188.114.96.12
, a Cloudflare address).
Code:
REMOTE_ADDR
and the access log both show the real visitor (our server's IP), not Cloudflare.
Code:
useIpInProxyHeader
appears 0 times in the config. Nothing was set up for this.

So on our CyberPanel 3.0 install, OpenLiteSpeed 2.5.5 recognised Cloudflare by itself. Check your own server the same way before you change anything. Older OpenLiteSpeed versions, or a config someone already edited, can behave differently.

Step 3: What it looks like when it's wrong
To see what a wrong setup looks like, we set the option to off on purpose (

Code:

useIpInProxyHeader 0

) and ran the same test:
[Image: attachment.php?aid=585]

Code:

REMOTE_ADDR=104.22.177.25

: a Cloudflare server, and the same in the access log, although the

Code:

CF

header still holds the real IP. That's the classic problem: every visitor in your logs is Cloudflare, and a "limit login attempts" plugin would lock out Cloudflare itself, which means all your visitors. If your test in Step 2 shows a Cloudflare IP, go to Step 5. (We removed the line again afterwards.)

Step 4: The spoof test (why "Yes" is dangerous)

Code:

X-Forwarded-For

and

Code:

CF-Connecting-IP

are just request headers. Cloudflare sets them, but anyone who connects to your server IP directly can send them too, with any value. The server should only believe them when the request comes from Cloudflare.
We ran the same three requests from a browser on another network, directly to the server (a DNS-only subdomain on the same server), once for each setting:
[Image: attachment.php?aid=586]

Not set (CyberPanel default): the fake headers were ignored. PHP saw the real IP every time.
useIpInProxyHeader 1 ("Yes"): the fake IP 1.2.3.4 was accepted from a normal visitor on the internet. Anyone could pick any IP: get around login limiters and per-IP limits by sending a new fake IP with every attempt, or put somebody else's IP in your logs. (The fake
Code:
CF-Connecting-IP
was not used in this mode;
Code:
X-Forwarded-For
was enough.)
useIpInProxyHeader 2 ("Trusted IP Only") with Cloudflare's ranges marked as trusted: fake headers ignored, real IPs through Cloudflare still correct.

Test your own server from your computer, not from the server. It sends the request straight to your server IP with a fake header:

Code:

curl -s --resolve yourdomain.com:443:YOUR-SERVER-IP -H 'X-Forwarded-For: 1.2.3.4' https://yourdomain.com/ip.php

Code:

REMOTE_ADDR=1.2.3.4

means your server can be fooled. Why not from the server: in our tests OpenLiteSpeed always trusted requests from the server's own IP, even in mode 2. A test run on the server shows 1.2.3.4 whatever the setting, and proves nothing.

Step 5: If you need to set it, use "Trusted IP Only"
Only needed if Step 2 shows a Cloudflare IP. Back up the config first, then download Cloudflare's current IP list (they publish it at

Code:

https://www.cloudflare.com/ips-v4

and

Code:

ips-v6

):

Code:

cd /usr/local/lsws/conf
cp -a httpd_config.conf /root/httpd_config.bak
U=https://www.cloudflare.com/ips-v
{ curl -s ${U}4; echo; curl -s ${U}6; } | grep . > /root/cf.txt
sed 's/$/T/' /root/cf.txt | paste -sd, - | sed 's/,/, /g'

We got 22 ranges (15 IPv4, 7 IPv6). The

Code:

T

at the end of each range means "trusted proxy" in OpenLiteSpeed. Then edit

Code:

httpd_config.conf

: add the setting above the

Code:

accessControl

block and the ranges to its

Code:

allow

line (shortened here):

Code:

useIpInProxyHeader        2

accessControl{
  allow                   ALL, 173.245.48.0/20T, 103.21.244.0/22T, ... , 2a06:98c0::/29T, 2c0f:f248::/32T
  deny
}

Keep

Code:

ALL

at the start, or nobody can reach your sites. In the OpenLiteSpeed WebAdmin (port 7080) it's the same: Server Configuration > General > Use Client IP in Header = Trusted IP Only, and the ranges with

Code:

T

in Server Configuration > Security > Access Control > Allowed List. Restart and test again (Step 2 and Step 4):

Code:

/usr/local/lsws/bin/lswsctrl restart

Never use Yes. Cloudflare adds new ranges rarely, but check the list once in a while, and after a CyberPanel upgrade check that your lines are still in the file.

Good to know with Cloudflare in front

Delete the test file when you're done:
Code:
rm /home/yourdomain.com/public_html/ip.php
. We removed ours.
Fail2ban and the firewall: a firewall ban only blocks direct connections. Proxied visitors reach your server from Cloudflare's IPs, so banning a visitor's real IP in the server firewall doesn't stop them. Block web visitors in Cloudflare (Security rules or IP Access rules) instead. Fail2ban for SSH and mail is not affected, because those don't go through Cloudflare.
SSL mode: CyberPanel gives the site a real Let's Encrypt certificate (SSL guide), so use Full (strict) in Cloudflare's SSL/TLS settings. "Flexible" talks plain HTTP to your server and fights with a force-HTTPS rule (redirect loop).
The panel and mail stay DNS only. Cloudflare doesn't proxy port 8090 or mail ports. Open the panel by server IP or a grey-cloud name, and keep
Code:
mail.
on DNS only.

Checklist

Site record proxied, no two-level subdomains proxied on the free plan.
Code:
ip.php
through Cloudflare shows your real IP, not a Cloudflare IP.
Fake-header test from your own computer does not show 1.2.3.4.
If you had to set it:
Code:
useIpInProxyHeader 2
plus Cloudflare ranges with
Code:
T
, never
Code:
1
.
Test file deleted.

More CyberPanel guides

Tested on CyberPanel 3.0 (build 8) with OpenLiteSpeed 2.5.5 on Ubuntu 24.04, Cloudflare free plan, October 2026. Other OpenLiteSpeed versions may behave differently; run the tests in Step 2 and Step 4 on yours.

Possibly Related Threads…matched by title
Guide Switch CyberPanel to LiteSpeed Enterprise: Free Trial, Results and What Breaks JAY	Replies:0Views:7	23 minutes agoJAY
Guide How to Change a Website's Domain in CyberPanel (Files, WordPress, 301) JAY	Replies:0Views:13	1 hour agoJAY
Guide CyberPanel Website Logs: Why PHP Errors Are Missing and How to See Them (Tested) JAY	Replies:0Views:18	8 hours agoJAY
Guide CyberPanel LiteSpeed and PHP Tuning: What Each Setting Does (and a Bug) JAY	Replies:0Views:15	Today, 07:05 AMJAY
Guide CyberPanel Git Deployment: Deploy from GitHub (and the Option That Deleted Our Site) JAY	Replies:0Views:104	10-26-2026, 04:31 PMJAY

Guide CyberPanel Behind Cloudflare: Real Visitor IPs and the Setting That Allows Fake IPs

Attached Files