Back to articles

How can I retrieve the actual IP addresses of users behind Fasterize?

Find out how to retrieve your users’ actual IP addresses when your site is hosted behind Fasterize. Learn how to use the X-Forwarded-For and True-Client-IP headers, configure your server (Apache, Nginx, Varnish, etc.), and ensure that your logs, security rules, and analytics work properly.

Introduction

When you use Fasterize, your web pages are served via a proxy-style setup. In practical terms, this means that the requests received by your origin server come from the Fasterize platform’s IP addresses, not directly from your users’ IP addresses.

In your server logs, you will therefore see the IP addresses of the Fasterize servers instead of the actual client IP addresses.

This can be a problem in several cases:

Fortunately, Fasterize transmits the user’s actual IP address via specific HTTP headers.

💡 The goal is simple: configure your server or application to use these headers instead of relying on the default visible source IP address.

Which headers should I use to retrieve the client's IP address?

To forward the user's actual IP address to your origin server, Fasterize adds two HTTP headers:

X-Forwarded-For contains a list of the IP addresses that relayed the request. The first address on the list is the browser's IP address.

Example:

X-Forwarded-For: client, proxy1, proxy2

True-Client-IP contains the client's IP address directly:

True-Client-IP: client

💡 In most cases, True-Client-IP is the easiest to use.

X-Forwarded-For is still useful if your infrastructure already handles this address string.

Why doesn't the client IP address appear in your logs anymore?

With Fasterize, the request path looks like this:

Your server therefore no longer sees the end user directly. It sees Fasterize as the final network intermediary.

⚠️ Without the proper configuration, your logs, security rules, and anti-abuse mechanisms will rely on Fasterize IP addresses, which will cause them to function incorrectly.

How do you configure your server to retrieve the actual IP address?

Apache

For Apache, we recommend using the module RemoteIP.

You can compile and install the module using:

apxs-i-a-c mod_remoteip.c

Next, add this line to your Apache virtual host configuration:

RemoteIPHeader True-Client-IP

This directive tells Apache to use the value of the header True-Client-IP as the actual client IP address.

💡 This is the recommended solution if you want Apache to properly process the actual IP address, rather than just logging it.

Nginx

For Nginx, we recommend using RealIP.

The principle is the same: instruct Nginx to use the IP address in the header sent by the proxy rather than the source IP address of the network connection.

Varnish

If you're using Varnish, the logic of the vcl_recv must contain:

if (req.http.x-forwarded-for) {
   set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip;
} else {
   set req.http.X-Forwarded-For = client.ip;
}

This configuration ensures that the string is preserved and properly enriched X-Forwarded-For.

IIS

For IIS version 8.5 and later, you can use the Enhanced Logging features.

For older versions, the Advanced Logging add-on must be installed. Once installed, you will see an additional option called Advanced Logging in IIS, which allows you to add and use the HTTP headers passed by the proxy.

⚠️ On IIS, retrieving the actual IP address often depends on how the logs are configured. It is therefore important to verify that the correct fields are being logged.

HAProxy

If you use HAProxy between Fasterize and your web server, you need to account for an additional proxy in the chain.

In that case, add the screenshot of the header True-Client-IP in HAProxy.

The idea is to use:

capture request header True-Client-IP len ...

This directive retrieves the client's IP address from the field captured_request_headers of the default HTTP log format.

💡 Note: forwardfor option is used solely to pass the client's IP address to the web server. This can be useful for Apache logs, for example, but it is not the same as capturing the header True-Client-IP in the HAProxy logs.

How do you update your server logs?

If you don't want to add a module to Apache or Nginx, you can simply log the client's IP address in your logs.

For Apache, open the file /etc/httpd/conf/httpd.conf and replace the line with CustomLog by the following configuration:

LogFormat "%{True-Client-IP}i %l %u %t \\"%r\\" %>s %b \\"%{Referer}i\\" \\"%{User-Agent}i\\"" proxy

SetEnvIf True-Client-IP "^.*\\..*\\..*\\..*" forwarded

CustomLog "/usr/local/apache/domlogs/mydomain.com" combined env=!forwarded
CustomLog "/usr/local/apache/domlogs/mydomain.com" proxy env=forwarded

Apache will then automatically select the correct log format based on the presence of the header True-Client-IP.

💡 This approach is useful if you want to keep the actual IP address in your logs without making more significant changes to the server's behavior.

What should you do if you can't change the server?

If you can't modify the server configuration, you can sometimes adapt your CMS or application to use the correct headers.

WordPress

You can use a plugin such as:

These extensions allow WordPress to correctly identify a user’s actual IP address when a proxy is being used.

Magento 1 and Magento 2

You must add the following section to local.xml, within the tag <global> :

<remote_addr_headers>
<!-- list headers that contain real client IP if webserver is behind a reverse proxy -->
<header1>HTTP_TRUE_CLIENT_IP</header1>
<header2>HTTP_X_FORWARDED_FOR</header2>
</remote_addr_headers>

This allows Magento to interpret the headers correctly True-Client-IP and X-Forwarded-For.

PHP

If your application is developed in PHP, you can retrieve the actual IP address using the server variable:

$_SERVER['HTTP_X_FORWARDED_FOR']

⚠️ This method assumes that your application can correctly interpret the content of X-Forwarded-For, especially when it contains multiple IP addresses.

How do I configure an IP block in .htaccess?

If you are currently using IP address blocking on a folder of your website, you need to update it to account for the header X-Forwarded-For.

Initial setup:

Order Deny,Allow
Deny from all
Allow from 172.135.135.234
Allow from 172.135.135.235

Recommended configuration:

Order Deny,Allow
Deny from all
SetEnvIf X-Forwarded-For "^172.135.1135.234" AllowAccess_1
SetEnvIf X-Forwarded-For "^172\\.135\\.1135\\.235" AllowAccess_2
Allow from env=AllowAccess_1
Allow from env=AllowAccess_2

⚠️ Without this adjustment, your rules may block Fasterize IPs instead of user IPs.

In what situations do you need to retrieve the client's IP address?

Here are a few common scenarios where the real IP address is useful on the origin side:

If your site falls into any of these categories, we strongly recommend that you take advantage of X-Forwarded-For or True-Client-IP.

Even if it isn't an immediate need yet, it's best to plan for this setup now.

💡 These changes don't pose any particular risk if you aren't currently using the client IP. However, they will prevent future issues when the need arises.

Conclusion

When Fasterize is placed in front of your website, your origin server no longer sees users’ actual IP addresses directly. To continue using this information, you must rely on the headers sent by Fasterize, specifically True-Client-IP and X-Forwarded-For.

Depending on your environment, there are several possible approaches:

Best practice is to make this adjustment as soon as Fasterize is implemented, to ensure that your logs, analytics tools, and security mechanisms continue to function consistently.

‍