When reviewing attack logs in SafeLine WAF, you may notice that the source IPs sometimes seem incorrect. This guide explains why that happens—and how to ensure SafeLine captures the real client IP, especially when deployed behind proxies.
Don’t want the full explanation? Jump to the conclusion for a quick fix.
❓ Why IPs Might Look Wrong
By default, SafeLine reads the client IP from the socket of the incoming HTTP connection. This works perfectly if SafeLine is deployed as the outermost network device.
However, in many production setups, SafeLine sits behind one or more proxies, such as:
- Nginx
- CDN providers
- Load balancers
- API gateways
In these cases, the HTTP connection comes from the proxy, not the actual client. So SafeLine logs the proxy’s IP—not the attacker’s.
🌐 Understanding X-Forwarded-For
X-Forwarded-For (XFF) is a widely used HTTP header that proxies add to help identify the original client IP.
Let’s break it down with two examples:
🧪 Case 1: Single Proxy
GET / HTTP/1.1
Host: demo.waf-ce.chaitin.cn
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36
X-Forwarded-For: 1.2.3.4
In this case, the proxy tells the server that the real client IP is 1.2.3.4.
🧪 Case 2: Multiple Proxies
GET / HTTP/1.1
Host: demo.waf-ce.chaitin.cn
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36
X-Forwarded-For: 1.2.3.4, 11.12.13.14, 21.22.23.24
Here, the flow is:
-
1.2.3.4→ Original client -
11.12.13.14→ First proxy -
21.22.23.24→ Second proxy - Final proxy → Connected directly to SafeLine (can be retrieved from socket)
X-Forwarded-For is a chain. The first IP in the list is usually the real client IP.
⚠️ Security Tip: Never blindly trust XFF headers unless your proxy chain is trusted. Malicious users can spoof these headers.
🛠 Configuring SafeLine to Use the Right IP
To adjust how SafeLine handles client IPs, go to:
Applications → Advanced
Available options include:
- From network connection: Use when SafeLine directly faces external clients (no proxies).
- From X-Forwarded-For (1st): Use if SafeLine sits behind one proxy.
- From X-Forwarded-For (2nd): Use if there are two proxies.
- From X-Forwarded-For (3rd): Use if there are three proxies.
- From other HTTP header: Use if proxies insert IPs in custom headers.
This flexibility allows SafeLine to accurately identify client IPs across diverse network topologies.
🧾 What About IP-Forwarded-For?
Some non-standard proxies might use IP-Forwarded-For or other custom headers instead of X-Forwarded-For.
You can configure SafeLine to use those, but only when:
- You control all the proxy layers
- The headers are consistent
- You’ve ruled out spoofing risks
✅ Conclusion
If your SafeLine logs show strange or incorrect IP addresses:
- 🔍 Check whether SafeLine is deployed behind a proxy chain.
-
⚙️ In Global Settings, set the appropriate Client IP Source:
- Behind one proxy? Use X-Forwarded-For (1st)
- Two proxies? Use X-Forwarded-For (2nd)
- Three proxies? Use X-Forwarded-For (3rd)
🔐 Don’t trust forwarded headers blindly—always validate your proxy setup.
🛠 Using custom headers? Make sure they’re secure and well-formed.
🧑💻 Need help configuring SafeLine in complex environments? Join the SafeLine Community or our discord group and share your setup.
Top comments (1)
To ensure that SafeLine WAF (Web Application Firewall) logs the true source IP address of incoming requests, especially when traffic passes through proxies or load balancers, you need to properly configure both your WAF and any upstream services. Here's how to do it:
✅ 1. Ensure X-Forwarded-For Header Is Passed
If SafeLine WAF sits behind a reverse proxy (like Nginx, Apache, or a CDN), the client’s original IP is usually added to the X-Forwarded-For header. Confirm that:
The proxy is adding this header.
No internal service is overwriting it.
✅ 2. Configure SafeLine to Trust Proxy Headers
SafeLine needs to be told to trust the headers coming from known proxies or gateways:
Check SafeLine’s configuration options for "trusted proxies" or "real IP" settings.
Set it to extract the client IP from X-Forwarded-For or similar headers (e.g., X-Real-IP).
✅ 3. Whitelist Known Proxy IPs
To prevent spoofing, make sure only IP addresses of trusted proxies/load balancers are allowed to inject X-Forwarded-For headers. Any request not from these sources should be ignored or dropped.
✅ 4. Test Your Setup
Use tools like curl or inspect request logs to verify that SafeLine is capturing and logging the true client IP, not just the proxy IP.
Example with curl:
bash
Copy
Edit
curl -H "X-Forwarded-For: 1.2.3.4" your-site.com
Check your SafeLine logs to confirm that 1.2.3.4 appears as the source IP.
✅ 5. Log the Correct Field
Ensure your WAF logging system or SIEM is configured to log the field that represents the real IP (like remote_addr or X-Forwarded-For, depending on how SafeLine exposes it).