How to Fix Incorrect Client IP Detection in SafeLine WAF

When deploying SafeLine WAF behind CDNs or reverse proxies, it’s common to run into source IP address issues. If your logs show internal or incorrect IPs instead of real client IPs, this guide will help you identify and fix the problem step by step.

1. SafeLine Fails to Retrieve Correct Source IP

Under normal conditions, SafeLine retrieves the client's source IP using a TCP socket connection.

However, if there are other devices such as CDN, AD, or LB between SafeLine and the client, these can prevent SafeLine from obtaining the correct source IP information.

Typically, proxy devices will include the real source IP in the HTTP Header when passing the request to the next device.

For example, in the HTTP request below, the source IP is included in both the X-Forwarded-For and X-Real-IP headers:

GET /path HTTP/1.1
Host: waf.chaitin.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
X-Forwarded-For: 110.123.66.233, 10.10.3.15
X-Real-IP: 110.123.66.233

The X-Forwarded-For header uses a chain structure. If the request passes through multiple proxies, it records each client's IP in sequence.
{.is-warning}

If the request does not contain headers with the source IP, you need to configure the front-end devices to pass the source IP to SafeLine via HTTP headers.

To address this, open the SafeLine console, go to Web Services page -> Global Settings -> Get Attack IP From and enter the appropriate header name in the corresponding input field.

2. Upstream Server Fails to Retrieve Correct Source IP

After SafeLine is deployed to protect the upstream server, the upstream server might retrieve SafeLine's IP instead of the client's source IP. How can you obtain the real source IP in this scenario?

SafeLine passes through the source IP by default and places it in the X-Forwarded-For HTTP header.

If the upstream server is NGINX, add the following configuration:

set_real_ip_from 0.0.0.0/0;
real_ip_header X-Forwarded-For;

Note: The ngx_http_realip_module module is used to change the client address and optional port to those sent in the specified header fields. This module is not built by default. Enable it during the build process using the --with-http_realip_module configuration parameter.
{.is-warning}

If the upstream server is not NGINX, you will need to configure it to parse the relevant headers accordingly.

3. Attack Addresses in SafeLine Logs Show as Internal IPs

The attack addresses displayed in the SafeLine logs are constructed using the {protocol}://{host}{:port}{path} fields from the HTTP request.

For common HTTP protocols such as HTTP/1.1 and HTTP/2.0, the attack address can be displayed correctly. However, very old HTTP protocols like HTTP/1.0 or HTTP/0.9 do not include the host field, so the attack address cannot be correctly displayed. In this case, SafeLine will use its own IP address instead of the host to display the attack address.

Final Thoughts

Handling real IP addresses correctly is essential for accurate logging, attack attribution, and reliable WAF protection. Whether you're using SafeLine behind a CDN or other proxy layers, a few small configurations can ensure your source IPs are properly passed and parsed. SafeLine WAF offers flexible support to handle these scenarios smoothly—just don’t forget to tune those headers!

🔗 Useful Links:

• 🌐 GitHub Repository
• 📚 Official Docs
• 💬 Discord Community