Introduction

Connecting RabbitMQ "through Nginx" can mean two very different things. You might want to proxy the RabbitMQ management UI and HTTP API, which are ordinary HTTP traffic, or you might want to proxy AMQP traffic on port 5672, which is raw TCP and cannot be handled by a normal Nginx location block. The setup only works cleanly once you separate those cases.

Decide What You Are Proxying

RabbitMQ exposes multiple interfaces:

• management UI and HTTP API, usually on port 15672
• AMQP 0-9-1, usually on port 5672
• AMQP over TLS, often on port 5671
• optional Web STOMP, Web MQTT, or AMQP-over-WebSocket plugins

The management UI is HTTP, so standard Nginx reverse proxying works well. AMQP is not HTTP, so this configuration does not work:

1server {
2    listen 5672;
3
4    location / {
5        proxy_pass http://127.0.0.1:5672;
6    }
7}

That looks plausible, but it is conceptually wrong. A location block speaks HTTP, while AMQP clients speak a binary messaging protocol over TCP.

Reverse Proxy the Management UI and HTTP API

If your goal is to expose the RabbitMQ UI safely behind Nginx, proxy the management port instead.

1server {
2    listen 443 ssl;
3    server_name rabbitmq.example.com;
4
5    ssl_certificate     /etc/ssl/certs/fullchain.pem;
6    ssl_certificate_key /etc/ssl/private/privkey.pem;
7
8    location / {
9        proxy_pass http://127.0.0.1:15672;
10        proxy_set_header Host $host;
11        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
12        proxy_set_header X-Forwarded-Proto https;
13        proxy_http_version 1.1;
14    }
15}

This is a good pattern when you want:

• TLS termination at Nginx
• a public hostname such as rabbitmq.example.com
• centralized access controls or logging

RabbitMQ’s management plugin supports being placed behind a reverse proxy. If you want the UI under a subpath such as /rabbitmq, configure a matching path prefix on the RabbitMQ side as well instead of rewriting URLs blindly.

Proxy AMQP with Nginx Stream, Not HTTP

If you really need Nginx in front of RabbitMQ’s AMQP port, use the Nginx stream module, which proxies raw TCP.

1stream {
2    upstream rabbitmq_amqp {
3        server 127.0.0.1:5672;
4    }
5
6    server {
7        listen 5672;
8        proxy_pass rabbitmq_amqp;
9    }
10}

This forwards TCP bytes without pretending the traffic is HTTP. It is much closer to what an AMQP client expects.

That said, many deployments do not need Nginx here at all. Exposing RabbitMQ directly on 5671 with TLS, or placing it behind a TCP-capable load balancer, is often simpler and easier to reason about.

Browser Clients Need a Web-Friendly Protocol

If the client runs in a browser, raw AMQP on port 5672 is usually not an option because browsers do not open arbitrary TCP sockets. In that case you usually need one of these:

• RabbitMQ management HTTP API for admin-style operations
• Web STOMP
• Web MQTT
• AMQP over WebSocket if that plugin is available in your environment

Nginx can proxy WebSocket traffic, but that is different from proxying ordinary AMQP.

A Practical Setup Pattern

A common production arrangement looks like this:

1. RabbitMQ listens privately on 15672 for management and 5672 or 5671 for messaging.
2. Nginx proxies only the management UI on a public HTTPS endpoint.
3. Application services connect to RabbitMQ directly over AMQP or AMQPS.

That keeps the administrative surface and messaging surface separate, which is usually easier to secure and operate.

Common Pitfalls

The biggest mistake is trying to send AMQP through an Nginx HTTP reverse proxy block. It fails because AMQP is not HTTP.

Another common confusion is mixing up ports. 15672 is for the management UI and HTTP API. 5672 is AMQP. A successful browser visit to the UI does not mean your AMQP clients are correctly routed.

If you terminate TLS at Nginx for the management UI, do not forget headers such as X-Forwarded-Proto. Missing proxy headers can produce incorrect redirects or URL generation.

Subpath deployments are another source of trouble. If you publish the UI under a prefix, make sure RabbitMQ is configured to understand that prefix instead of relying on partial rewrites.

Finally, do not add Nginx in front of AMQP unless you have a concrete reason. Every extra layer complicates connection handling, TLS, troubleshooting, and observability.

Summary

• RabbitMQ management traffic on port 15672 can be reverse proxied through ordinary Nginx HTTP configuration.
• Raw AMQP traffic on port 5672 cannot be proxied with an HTTP location block.
• If you need to proxy AMQP through Nginx, use the stream module for TCP forwarding.
• Browser clients usually need HTTP or WebSocket-based plugins rather than raw AMQP.
• In many deployments, proxying only the management UI and connecting services directly to RabbitMQ is the cleanest design.