IP Address

SafeLine Fails to Retrieve Correct Source IP

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

However, if there are other devices such as CDNs, ADs, or LBs between SafeLine and the client, these may prevent SafeLine from obtaining the correct source IP.

Typically, proxy devices will include the real source IP in the HTTP header when forwarding 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, navigate to the "General Configuration" page, change the "Source IP Retrieval Method" to "Retrieve from HTTP Header," and enter the appropriate header name in the corresponding input field.

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. To obtain the real source IP in this scenario:

By default, SafeLine passes through the source IP 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.

Attack Addresses in SafeLine Logs Show as Internal IPs

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

For common HTTP protocols like HTTP/1.1 and HTTP/2.0, the attack address is 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 displayed correctly. In such cases, SafeLine will use its own IP address instead of the host to display the attack address.

Traffic Statistics

Mismatch Between "Interception Count" and Attack Log Entries

Attack events record instances of attacks (including blacklist entries). High-frequency restrictions or bot detections do not log attack events.

"Interceptions" can occur for various reasons, not just attacks. Specific reasons that might cause an interception include:

1. Detected a web attack, intercepted by SafeLine
2. Access frequency too high, intercepted by SafeLine
3. Failed bot verification, intercepted by SafeLine
4. Failed authentication, intercepted by SafeLine
5. Detected malformed HTTP traffic, intercepted by SafeLine
6. Requested domain does not match the domain configured in SafeLine, intercepted by SafeLine