RabbitMQ ports explained: default ports and their uses

TLDR;

RabbitMQ uses port 5672 by default for AMQP client connections. The RabbitMQ Management UI is typically available on port 15672.

RabbitMQ also uses several additional ports for TLS connections, clustering, Erlang distribution, and management. This guide explains the default RabbitMQ ports, what each one is used for, and when you need to expose or configure them.

RabbitMQ default ports at a glance

Most setups only need two of them: 5672 for your applications and 15672 for the management interface. The rest matter when you enable TLS or run a cluster.

What is the default RabbitMQ port?

The default RabbitMQ port is 5672.

It is used for:

• Standard AMQP 0-9-1 connections
• All RabbitMQ client libraries (Java, .NET, Python, Go, PHP, JavaScript…)
• Plain, non-TLS connections

A connection URI using the default port looks like this:

amqp://localhost:5672

If a client is configured with the amqp:// scheme and no explicit port, it falls back to 5672 automatically.

What port does the RabbitMQ Management UI use?

The RabbitMQ Management UI uses port 15672.

Open it in a browser at:

http://localhost:15672

The management interface exposes:

• The management dashboard (node health, message rates, memory usage)
• Queues (depth, consumers, message rates)
• Exchanges and bindings
• Connections and channels
• Users, permissions, and virtual hosts

The same port also serves the HTTP management API, which is what monitoring tools and clients like RabbitGUI use to talk to the broker.

To access the management interface, you will also need the correct RabbitMQ username and password. On a fresh install these are guest / guest, restricted to localhost. See RabbitMQ default login for the details.

RabbitMQ AMQP connection ports

Port 5672: AMQP

Port 5672 is where your applications publish and consume messages. Every standard client library connects here unless you tell it otherwise.

With explicit credentials:

amqp://guest:guest@localhost:5672

Without credentials:

amqp://localhost:5672

What happens in each case:

• Username and password omitted: most clients fall back to guest / guest, which is the default RabbitMQ account.
• Default credentials used: the guest user works out of the box, but only over a loopback connection.
• Connection is remote: guest is rejected by design. RabbitMQ refuses the guest user from any non-localhost address, so you must create a dedicated user. This is the single most common cause of a "connection refused" that is really an authentication failure, see RabbitMQ default login.

Ports are also part of the connection URI in every client library. The JavaScript, Python, Java, and Go cheat sheets all use 5672 in their connection examples.

Port 5671: AMQP over TLS

When TLS is enabled, RabbitMQ listens for encrypted AMQP connections on port 5671, using the amqps:// scheme:

amqps://your-host:5671

Notes on 5671:

• It is a separate listener, not an upgrade of 5672. Both can be open at the same time.
• It only exists once you configure a TLS listener and certificates in rabbitmq.conf.
• Managed providers (CloudAMQP, Amazon MQ, and similar) usually expose 5671 only and close 5672 entirely.

Pointing an amqp:// client at 5671, or an amqps:// client at 5672, produces a handshake failure rather than a clear error, so check the scheme and the port together.

RabbitMQ management ports

Port 15672: Management UI

Port 15672 is opened by the rabbitmq_management plugin. It serves both the web UI and the HTTP API.

URL

http://localhost:15672

How to access it

The plugin must be enabled first. The rabbitmq:3-management and rabbitmq:4-management Docker images ship with it on, a package install does not:

rabbitmq-plugins enable rabbitmq_management

Authentication

The UI requires a user with the management tag. The default guest user has it, but only over localhost. For any remote access, create a user and grant the tag:

rabbitmqctl add_user admin secure_password
rabbitmqctl set_user_tags admin administrator
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"

Docker considerations

Inside a container the plugin listens on 15672, but the port is unreachable from your machine until you publish it with -p 15672:15672. A missing mapping looks exactly like a broken management plugin from the outside.

You can also point RabbitGUI at this port instead of using the built-in UI:

RabbitGUI is a RabbitMQ IDE that connects over the same management port and gives you a far better interface for browsing queues, publishing messages, and inspecting bindings. Credentials are the same ones the UI uses, covered in RabbitMQ default login.

Port 15671: Management UI over HTTPS

Port 15671 serves the management UI and HTTP API over TLS:

https://your-host:15671

It is not enabled by default. You turn it on by configuring a TLS listener for the management plugin in rabbitmq.conf:

management.ssl.port       = 15671
management.ssl.cacertfile = /path/to/ca_certificate.pem
management.ssl.certfile   = /path/to/server_certificate.pem
management.ssl.keyfile    = /path/to/server_key.pem

Once 15671 is configured, close 15672 in production. The management API accepts credentials over HTTP basic auth, so plain HTTP sends them in the clear.

RabbitMQ cluster and Erlang ports

Single-node setups never touch these two ports. Clusters cannot work without them.

Port 25672: inter-node communication

Port 25672 carries Erlang distribution traffic: node-to-node replication, queue synchronization, and rabbitmqctl commands issued from another machine.

It is derived from the AMQP port (5672 + 20000), so changing the AMQP port shifts it too. Nodes also open a range of dynamic ports above it, by default 25672–25682, so a firewall rule for a single port is not enough.

Port 4369: EPMD

Port 4369 is the Erlang Port Mapper Daemon. It is the directory service that tells a joining node which port a named node is actually listening on, which is what makes peer discovery work.

EPMD must be reachable between all cluster members. It must never be exposed to the internet: it is unauthenticated and lists every Erlang node on the host.

Both ports should be restricted to the cluster's private network:

# Pin the distribution port range for firewall rules
distribution.listener.port_range.min = 25672
distribution.listener.port_range.max = 25672

RabbitMQ ports in Docker

In Docker, a port is only reachable from your machine if you publish it. This is the most common reason RabbitMQ "isn't listening" when it is running perfectly well.

services:
  rabbitmq:
    image: rabbitmq:4-management
    ports:
      - "5672:5672"
      - "15672:15672"

What each mapping does:

• 5672 → your applications connect here (amqp://guest:guest@localhost:5672)
• 15672 → the management UI and HTTP API (http://localhost:15672)

Two things to keep in mind:

• Use the -management image tag, or the management plugin is not enabled and 15672 stays closed no matter how you map it.
• Containers on the same Docker network reach each other by service name on the internal port (amqp://rabbitmq:5672), with no published port needed. Publishing is only for access from the host.

For clustering, add the Erlang ports as well, and make sure every node shares the same Erlang cookie. Full walkthrough: How to set up RabbitMQ with Docker and Docker Compose.

How to check which port RabbitMQ is using

Ask the broker directly. rabbitmq-diagnostics reports every active listener and its port:

rabbitmq-diagnostics listeners

Check the effective configuration. rabbitmqctl prints the values RabbitMQ actually loaded, which may differ from what you think is in rabbitmq.conf:

rabbitmqctl environment | grep -i port

Check the config file. Ports are set in rabbitmq.conf:

# AMQP port
listeners.tcp.default = 5672
 
# Management plugin port
management.tcp.port = 15672
 
# Inter-node communication
distribution.listener.port = 25672

Check what the OS has open. Useful when RabbitMQ starts but nothing can reach it:

# Linux
ss -tlnp | grep -E '5672|15672'
 
# macOS or Linux
lsof -i :5672
netstat -an | grep 5672

Check the Docker mapping. The container port and the host port are not the same thing:

docker ps
docker port rabbitmq

Check EPMD for cluster nodes. It lists every Erlang node and the distribution port it holds:

epmd -names

Common RabbitMQ port problems

RabbitMQ port 5672 is not accessible

Work through these in order:

• RabbitMQ isn't running. Confirm with rabbitmqctl status or docker ps. A crashed node refuses connections exactly like a firewall does.
• Docker ports aren't exposed. Without -p 5672:5672 the listener exists inside the container only.
• Firewall. Cloud security groups and host firewalls block 5672 by default on most images.
• Wrong hostname. localhost from inside another container is that container, not the broker. Use the service name on a shared Docker network.
• TLS/non-TLS mismatch. An amqps:// client on 5672, or amqp:// on 5671, fails at the handshake.
• It's actually authentication. A rejected guest login from a remote host often surfaces as a connection error. See RabbitMQ default login.

RabbitMQ Management UI on port 15672 isn't working

• Management plugin isn't enabled. Run rabbitmq-plugins enable rabbitmq_management, or use a -management Docker image.
• Port isn't exposed. Add -p 15672:15672 or the matching ports entry in Docker Compose.
• Wrong Docker mapping. Publishing 15672 to a different host port means the URL changes: -p 8080:15672 is served at http://localhost:8080.
• Firewall. 15672 should be closed to the internet, but it must be open to you.
• Login rejected. guest only works over localhost. Create a user with the management tag for remote access.
• Service configuration. If management.tcp.port was changed in rabbitmq.conf, the UI is on that port instead. Confirm with rabbitmq-diagnostics listeners.

Firewall and production checklist

• Never expose 15672 publicly. Put it behind a VPN, an SSH tunnel, or a reverse proxy with authentication.
• Restrict 5672 to the networks and applications that need it.
• Use TLS and move traffic to 5671 and 15671 with proper certificates.
• Keep 4369 and 25672 private. They belong on the cluster's internal network only, and EPMD in particular must never face the internet.

Summary

• 5672: default AMQP client connection port
• 5671: AMQP over TLS
• 15672: management UI and HTTP API
• 15671: management UI and API over HTTPS
• 4369: EPMD, Erlang peer discovery
• 25672: inter-node cluster communication (plus a dynamic range above it)

For a better RabbitMQ management experience, try RabbitGUI. It connects on the management port (15672) and gives you everything you need to browse queues, publish messages, and debug your broker.