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.

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 and Ubuntu

Apache 2.4 packages include mod_remoteip. Create or edit /etc/apache2/mods-available/remoteip.conf:

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

Use this configuration, replacing both example addresses with the current Backend Communication IP Addresses shown for your service:

RemoteIPTrustedProxy 192.0.2.10
RemoteIPTrustedProxy 198.51.100.20
RemoteIPHeader X-Real-IP

Add one RemoteIPTrustedProxy line for each backend communication address. These example addresses are reserved for documentation. If you changed the port's Backend Real IP Header, use that header name instead. A module-level configuration applies across virtual hosts; place the directives in the relevant virtual host if only one site uses X4B.

Enable the module after saving the configuration, then check and reload Apache:

a2enmod remoteip
apachectl -t
systemctl reload apache2

Reload only after the configuration check succeeds. Follow the verification steps above to confirm the client address in your application and access logs. Keep any firewall restriction against direct backend access enabled.

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

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.