RabbitMQ: Unable to Observe Original Client IP Behind Network Proxy or Load Balancer
Article ID: 441164
Updated On:
Products
Issue/Introduction
When RabbitMQ is deployed behind a load balancer, reverse proxy, firewall, or other network intermediary, the original client source IP address may not be visible in broker logs or connection metrics.
This limitation typically appears in two scenarios:
- AMQP connections: RabbitMQ logs show the IP address of the intermediary device instead of the actual client.
- HTTP / Management API requests: For stateless authentication failures, such as OAuth 2.0 or JWT failures, standard broker logs may not include the original client IP.
Environment
All supported RabbitMQ versions
Cause
It is due to upstream network devices utilizing NAT/SNAT features, which replace the actual client IP with the device's own pool IP.
- For AMQP traffic: The network device may perform NAT/SNAT or terminate the incoming TCP session. In this scenario, RabbitMQ only sees the proxy’s intermediate IP address unless Proxy Protocol is enabled end-to-end.
- For HTTP / Management API traffic: RabbitMQ can track authentication attempts and, when configured, record source details such as the remote IP address, username, and protocol. Standard logs alone may not provide the client IP for inline authentication failures.
Resolution
1. Preserve the client IP for AMQP traffic
Configure the upstream load balancer or reverse proxy to send a Proxy Protocol header, and enable Proxy Protocol on RabbitMQ.
Add the following to rabbitmq.conf:
proxy_protocol = true
Proxy Protocol must be enabled on both the proxy and RabbitMQ. If the proxy sends Proxy Protocol but RabbitMQ is not configured to accept it, connections will fail.
2. Identify client IPs for HTTP / Management API authentication failures
For HTTP-based authentication failures, use RabbitMQ’s authentication-attempt tracking. RabbitMQ can record the source of authentication attempts, including the remote IP address, when source tracking is enabled.
After enabling source tracking, review authentication-attempt data through the management API or Prometheus metrics to identify the source address.
3. Use packet capture only for low-level verification
If needed during troubleshooting, capture traffic on the management port and inspect the Proxy Protocol header:
sudo tcpdump -i any -nn -As0 port 15672 | grep -B 3 -A 1 "YOUR_CLIENT_OR_APP_ID"
Note: Use this method as a verification aid rather than the primary operational approach.
Additional Information
Feedback
