DEV Community

Sharon
Sharon

Posted on

How to Configure SafeLine WAF to Accurately Capture the Real Client IP

#waf #safeline #nginx #devops

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

Image description

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Image description

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 (0)