Obtaining the client IP address with Apache

For an HTTP(S) reverse proxy, X4B sends the client address to your backend in an HTTP header. The default header is X-Real-IP. Apache 2.4 and later can use mod_remoteip to use that value for request handling, access logs, and modules that read the client address.

Only trust this header when the connection itself came from a known X4B backend communication IP address. A client that can connect directly to Apache can send its own X-Real-IP header, so Apache must not accept the header from untrusted sources.

Apache 2.4 and later: mod_remoteip

Enable mod_remoteip using your operating system's Apache package and module-management process. The configuration may be placed in the server configuration or in the virtual host that serves the proxied site.

In the Dashboard, open the service and find Backend Communication IP Addresses. These are the immediate X4B connection sources for your backend. Add one RemoteIPTrustedProxy directive for every current address shown there:

RemoteIPHeader X-Real-IP
RemoteIPTrustedProxy <current X4B backend communication IP address>
RemoteIPTrustedProxy <another current X4B backend communication IP address>

Replace the placeholders with the current addresses for this service only. They are not client addresses and should not be replaced with the IP addresses of visitors. If the port's Backend Real IP Header has been changed in HTTP Options, replace X-Real-IP with that configured header name.

RemoteIPTrustedProxy is intentional here. RemoteIPHeader without a trusted proxy restriction can accept a claimed client address from any host that presents the header. Do not use RemoteIPInternalProxy unless X4B has explicitly confirmed that it is appropriate for your service.

Verify the configuration

  1. Confirm that the module is loaded, for example with apachectl -M.
  2. Check the Apache configuration syntax with apachectl -t, then reload Apache using your operating system's normal service-management method.
  3. Make a non-sensitive request through the protected public hostname and confirm that the application and access log show the client address expected for that request.
  4. If you use a custom log format, %a records the client address after mod_remoteip processing and %{c}a records the underlying connection source. A temporary format can make the distinction visible:
LogFormat "%a connection=%{c}a %r" realip_check
CustomLog logs/realip_check.log realip_check

Do not leave test logging enabled longer than necessary, and do not include customer requests or credentials in a support ticket.

Installation of mod_remoteip on Debian

  1. Install the libapache2-mod-remoteip package using your favorite package manager:

    apt-get install libapache2-mod-remoteip

  2. Enable mod_remoteip by executing:

    a2enmod remoteip

  3. Restart Apache to activate these changes:

    /etc/init.d/apache2 restart

  4. Edit the RPAF configuration file at /etc/apache2/mods-available/remoteip.conf with your favorite text editor.

    nano /etc/apache2/mods-available/remoteip.conf

  5. Your configuration should be similar to:

    RemoteIPTrustedProxy A.B.C.D
RemoteIPTrustedProxy E.F.G.H
RemoteIPHeader X-Real-IP

Where "A.B.C.D" is, add your backend communication addresses, you will need one RemoteIPTrustedProxy for each backend communication address. This will tell mod_remoteip which hosts to get X-Real-IP headers from.

Troubleshooting

  • Confirm that the configured header matches the current Backend Real IP Header for the port. The default is X-Real-IP.
  • Confirm that every current Dashboard backend communication address is present as a RemoteIPTrustedProxy. Review this after a backend-address migration.
  • Confirm that the directives apply to the virtual host receiving the proxied traffic, not only to an unrelated site.
  • If Apache still logs the X4B connection source, check that mod_remoteip is loaded and that the configuration test and reload both completed successfully.
  • If an unexpected client address is logged, remove the temporary log format after collecting non-sensitive evidence and review the trusted-proxy entries before treating the header as authoritative.

Legacy Apache 2.2 and mod_rpaf

Legacy software: Apache 2.2 and mod_rpaf are not the recommended path for new or maintained services. Upgrade to Apache 2.4 or later and use mod_remoteip where possible.

If an existing Apache 2.2 installation cannot yet be upgraded, keep any mod_rpaf configuration limited to the current X4B backend communication addresses and plan an upgrade. This article no longer provides installation or source-build instructions for mod_rpaf.

More information

Read the Real IP overview for the X4B header model and the Reverse Proxy overview for backend exposure checks. For Apache directive details, see the stable Apache 2.4 mod_remoteip documentation.