Troubleshooting IP and Traffic Issues in SafeLine WAF Deployments

When deploying SafeLine WAF, one of the most common problems users face is:

"Why does SafeLine (or my backend server) show the wrong source IP?"

This guide breaks down common IP-related and traffic statistics issues, and how to fix them.

Problem 1: SafeLine Doesn’t Show the Real Client IP

By default, SafeLine uses the TCP connection to determine the client IP.

But if the request passes through a CDN, load balancer, or reverse proxy, this IP will likely be that of the proxy — not the actual user.

The Standard Fix

Most proxy systems (like NGINX, Cloudflare, etc.) include the original client IP in request headers such as:

GET /path HTTP/1.1
Host: waf.chaitin.com
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 there are multiple proxies, each IP is appended in order.

If no such header is present, configure your frontend CDN/proxy to inject the real IP into the HTTP request.

Then in SafeLine:

1. Go to the Web Console
2. Navigate to General Configuration
3. Set "Source IP Retrieval Method" to "From HTTP Header"
4. Enter the header name (X-Forwarded-For or similar)

Problem 2: Backend Server Sees SafeLine’s IP Instead of Client IP

Once SafeLine is in front of your application server, the upstream may now see SafeLine’s IP instead of the client’s.

SafeLine already preserves the real IP in the X-Forwarded-For header.

If your backend is NGINX, fix this by adding:

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

⚠️ Note: This requires the ngx_http_realip_module, which must be enabled at compile time using --with-http_realip_module.

If you’re using another web server, make sure it can parse the X-Forwarded-For or similar header.

Problem 3: Attack Logs Show Internal IPs Instead of Real Ones

SafeLine builds the attack address using:

{protocol}://{host}:{port}{path}

For most modern protocols (HTTP/1.1, HTTP/2.0), this works fine.

But if requests use legacy protocols like HTTP/1.0 or 0.9 (which don’t include a Host header), SafeLine can’t reconstruct the real domain and will default to its own IP address.

Traffic Statistics Issues

Why Do "Interception Count" and Attack Logs Not Match?

This is expected.

Attack logs record specific detected attack events, including blacklist matches.

But the interception counter includes all blocked requests — not just attacks.

Examples of blocked (but not logged) events:

• Rate limiting triggered
• Bot/human verification failed
• Authentication failed
• Malformed HTTP traffic
• Domain mismatch (request doesn’t match configured domain)

Final Notes

• Always ensure your proxy devices pass along the real client IP
• SafeLine can be configured to trust the appropriate header
• Backend servers should be configured to parse these headers correctly
• Don't rely solely on logs for traffic analysis — use the full dashboard metrics

Join the SafeLine Community

• GitHub Repository
• Official Docs
• Discord Community