RabbitMQ ports: 5672, 15672, 25672 and more explained

December 11, 2025•9 min read•RabbitMQ tutorial

RabbitMQ ports: 5672, 15672, 25672 and more explained

RabbitMQ default ports

RabbitMQ's default AMQP port is 5672. The Management UI uses 15672.

PortPurposeWhen you need it
5672AMQPApplication connections (publish and consume)
5671AMQP over TLSSecure application connections
15672Management UI and HTTP APIBrowser access, monitoring, management API
15671Management UI and HTTP API over TLSSecure management access
25672Erlang distributionNode-to-node communication in a cluster, remote CLI tools
4369EPMDErlang node discovery in a cluster

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

RabbitMQ 5672 vs 15672

These two ports are the ones people mix up the most. They serve completely different clients:

  • 5672 is for applications. Your code connects here through a client library with an amqp:// URI to publish and consume messages. It speaks AMQP, not HTTP, so opening it in a browser shows nothing useful.
  • 15672 is for humans and HTTP tools. It serves the Management UI in the browser and the HTTP management API used by monitoring tools and clients like RabbitGUI. Your application never publishes messages through it.
567215672
ProtocolAMQP 0-9-1HTTP
Used byApplication client librariesBrowser, monitoring, management API
URLamqp://localhost:5672http://localhost:15672
Provided byRabbitMQ core, always onrabbitmq_management plugin

If your app can't connect, look at 5672. If the web UI doesn't load, look at 15672. The two fail independently: a broker can accept AMQP connections perfectly while the management UI is unreachable, and vice versa.

Which RabbitMQ ports do I need to expose?

It depends on who needs to reach the broker.

Single instance (local or Docker)

  • 5672 if applications running outside the container or host connect to RabbitMQ.
  • 15672 if you need the Management UI, the HTTP API, or a tool like RabbitGUI.
  • Nothing else. 25672 and 4369 are only used between cluster nodes.

Cluster

  • Everything above, plus 4369 (EPMD) and 25672 (inter-node communication) between the cluster nodes.
  • These must be open between nodes only, on a private network.

Production

  • 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: move traffic to 5671 and 15671 with proper certificates, and close the plain-text ports.
  • Keep 4369 and 25672 private. EPMD in particular must never face the internet.

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"

Each mapping reads "HOST_PORT:CONTAINER_PORT":

  • The right side is the port RabbitMQ listens on inside the container. Keep it at 5672 and 15672.
  • The left side is the port you use on your machine. It can be anything free.

So "5672:5672" makes the broker available at amqp://localhost:5672, and "15672:15672" makes the UI available at http://localhost:15672. With "8080:15672", the UI is at http://localhost:8080 instead, while RabbitMQ still listens on 15672 inside the container.

The same thing with docker run:

docker run -d --name rabbitmq \
  -p 5672:5672 \
  -p 15672:15672 \
  rabbitmq:4-management

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 container port (amqp://rabbitmq:5672), with no published port needed. Publishing is only for access from the host.

Full walkthrough, including volumes, health checks and clustering: How to set up RabbitMQ with Docker and Docker Compose.

Port 5672: default AMQP port

Port 5672 is where your applications publish and consume messages. It is used for:

  • Standard AMQP 0-9-1 connections
  • All RabbitMQ client libraries (Java, .NET, Python, Go, PHP, JavaScript…)
  • Plain, non-TLS connections
amqp://guest:guest@localhost:5672

If a client is configured with the amqp:// scheme and no explicit port, it falls back to 5672 automatically. If the username and password are omitted, most clients fall back to guest / guest.

The guest user only works over localhost. From a remote host it is rejected by design, and some client libraries report that as a generic connection error. This is the single most common "connection refused" that is really an authentication failure, see RabbitMQ default login.

The JavaScript, Python, Java, Go, and C# 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
  • 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.

Port 15672: Management UI and HTTP API

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

http://localhost:15672

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

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

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

See RabbitMQ default username and password for the details.

The same port serves the RabbitMQ monitoring API, which is what dashboards, alerting scripts and clients like RabbitGUI use to talk to the broker. RabbitGUI connects on 15672 with the same credentials as the built-in UI, and gives you a better RabbitMQ management UI for browsing queues, publishing messages, and inspecting bindings:

Rabbitgui connexion screen

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. Configure 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.

Port 25672 and 4369: clustering 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 CLI tools like rabbitmqctl talking to a node.

It is derived from the AMQP port (5672 + 20000), so changing the AMQP port shifts it too. Recent versions keep distribution on that single port by default; older setups or custom configs may use a range, which you can pin for firewall rules:

distribution.listener.port_range.min = 25672
distribution.listener.port_range.max = 25672

CLI tools such as rabbitmqctl also open short-lived connections from the 35672–35682 range when they talk to a node, so allow those between the machine running the tool and the node.

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 listening on, which is what makes peer discovery work.

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

In Docker, clustered nodes also need to share the same Erlang cookie. See RabbitMQ clustering with 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 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

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

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

Can't connect to RabbitMQ on port 5672

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 port isn't published. 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.

localhost:15672 isn't working

  • Management plugin isn't enabled. Run rabbitmq-plugins enable rabbitmq_management, or use a -management Docker image.
  • Port isn't published. Add -p 15672:15672 or the matching ports entry in Docker Compose.
  • Different host port. -p 8080:15672 means the UI is at http://localhost:8080, not 15672.
  • Port changed in config. If management.tcp.port was changed in rabbitmq.conf, the UI is on that port instead. Confirm with rabbitmq-diagnostics listeners.
  • Login rejected. If the page loads but shows Login failed, it's the credentials, not the port. guest only works over localhost.

FAQ

What port does RabbitMQ use?

RabbitMQ uses port 5672 for AMQP client connections and 15672 for the Management UI and HTTP API. TLS adds 5671 and 15671, and clusters use 25672 and 4369.

What is RabbitMQ port 15672?

It is the Management UI and HTTP management API port, provided by the rabbitmq_management plugin. Open http://localhost:15672 in a browser.

What is RabbitMQ port 25672?

It is the Erlang distribution port used for communication between cluster nodes and by CLI tools. It is 5672 + 20000 and should only be reachable on a private network.

Is RabbitMQ port 5672 TCP or UDP?

TCP. All RabbitMQ ports are TCP, including 5672, 15672, 25672 and 4369. No UDP ports need to be opened.

Why can't I connect to RabbitMQ on 5672?

Usually the port isn't published in Docker, a firewall blocks it, the hostname is wrong, or the guest user is rejected because you are connecting remotely. See the checklist above.

Why does localhost:15672 not work?

The management plugin is not enabled, port 15672 is not published in Docker, or it is mapped to a different host port. See the checklist above.

Can I change the default RabbitMQ port?

Yes. Set listeners.tcp.default for AMQP and management.tcp.port for the Management UI in rabbitmq.conf, then restart RabbitMQ. In Docker it is usually simpler to keep the container ports and change the host side of the mapping.

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.

Working with RabbitMQ?

See how RabbitGUI can make your everyday RabbitMQ workflows easier.
Available on Windows, Mac, and Linux.

Try RabbitGUIRabbitGUI screenshot

Read more RabbitMQ tutorials

What Is RabbitMQ?RabbitMQ tutorialWhat Is RabbitMQ?Learn what RabbitMQ is, how it works, and why it’s used in modern software architectures. Discover RabbitMQ’s benefits, key components, use cases, and how it enables reliable asynchronous communication.Setting up RabbitMQ with Docker and Docker ComposeRabbitMQ tutorialSetting up RabbitMQ with Docker and Docker ComposeA complete guide to running RabbitMQ in Docker containers, from quick start examples to advanced configuration options for production environmentsRabbitMQ Best PracticesRabbitMQ tutorialRabbitMQ Best PracticesA practical guide to RabbitMQ best practices covering queue design, message handling, connection management, monitoring, and production-readiness tips.RabbitMQ vs KafkaRabbitMQ tutorialRabbitMQ vs KafkaEverything you need to know about the differences between RabbitMQ and Kafka.RabbitMQ: maximum size of a messageRabbitMQ tutorialRabbitMQ: maximum size of a messageThe maximum size of a message in RabbitMQ is not defined by the protocol, but by the implementation. Unfortunately, this value is not well documented and has changed a lot over timeProperly setting up dead-letter queues in RabbitMQRabbitMQ tutorialProperly setting up dead-letter queues in RabbitMQLearn how to set up dead-letter queues in RabbitMQ, including creating a dead-letter exchange, binding it to a queue, and managing rejected messages via policies