🚨 RabbitMQ Error Guide: 'ECONNREFUSED' Connection Refused on 5672

Overview

A connection refused error means your client opened a TCP socket to the RabbitMQ AMQP port (5672 by default, 5671 for TLS) and the host actively rejected it. Nothing is listening on that address/port, so the kernel returns RST immediately. This is a transport-layer failure that happens before any AMQP handshake, so it is never an authentication or vhost problem.

You will see it in the client log:

Error: connect ECONNREFUSED 10.0.4.21:5672
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
  errno: -111, code: 'ECONNREFUSED', syscall: 'connect',
  address: '10.0.4.21', port: 5672
}

Or from a Python/pika client:

pika.exceptions.AMQPConnectionError: Connection to 10.0.4.21:5672 failed:
[Errno 111] Connection refused

The cause is almost always one of: the broker process is not running, the client is pointed at the wrong host/port, the listener is bound to a different interface, the broker only exposes TLS (5671), or a firewall/security group is rejecting (not dropping) the port.

Symptoms

• Client fails instantly with ECONNREFUSED / Connection refused — no timeout, no delay.
• All clients on a host fail identically, regardless of credentials or vhost.
• rabbitmqctl status may show the node up locally while remote clients are refused.

curl -v telnet://10.0.4.21:5672 --max-time 5

* Trying 10.0.4.21:5672...
* connect to 10.0.4.21 port 5672 failed: Connection refused
* Failed to connect to 10.0.4.21 port 5672 after 8 ms: Connection refused

A refused connection (instant RST) is distinct from a dropped one (hang then timeout); the latter points at a firewall DROP rather than a missing listener.

Common Root Causes

1. The broker is not running

If the RabbitMQ service is stopped or crashed, nothing binds 5672.

rabbitmqctl status | head -20

Error: unable to perform an operation on node 'rabbit@mq-01'.
Please see diagnostics information and suggestions below.

attempted to contact: [rabbit@mq-01]

rabbit@mq-01:
  connected to epmd (port 4369) on mq-01
  epmd reports: node 'rabbit' not running at all

The node is registered with epmd but the Erlang VM/RabbitMQ app is down. Start it and confirm.

sudo systemctl start rabbitmq-server
rabbitmqctl await_startup && rabbitmqctl status | grep -A2 'Listeners\|listeners'

2. The AMQP listener is not bound (or bound to the wrong interface)

The broker may be running but only listening on loopback, so remote clients are refused.

rabbitmqctl environment | grep -A6 'tcp_listeners'

{tcp_listeners,[{"127.0.0.1",5672}]},
{num_tcp_acceptors,10},

Bound to 127.0.0.1 only — a connection from another host is refused. It should be [5672] (all interfaces) or the specific reachable IP.

3. Client is pointed at the wrong host or port

A typo, stale DNS, or the wrong environment URL sends the client to a port nothing listens on.

getent hosts rabbitmq.internal

10.0.9.99   rabbitmq.internal

If the broker actually lives on 10.0.4.21, the client connects to a host with no broker and is refused.

4. The broker is TLS-only (5671), client uses 5672

Hardened deployments disable the plaintext 5672 listener and serve only AMQPS on 5671. A client using amqp:// on 5672 is refused.

rabbitmqctl environment | grep -A8 'ssl_listeners'

{ssl_listeners,[5671]},
{tcp_listeners,[]},

tcp_listeners is empty — only 5671 is open. The client must use amqps://host:5671.

5. Firewall or security group rejects the port

A firewall configured to REJECT (rather than DROP) sends an instant RST that looks identical to a missing listener.

sudo iptables -L INPUT -n --line-numbers | grep 5672

3    REJECT     tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:5672 reject-with icmp-port-unreachable

A REJECT ... icmp-port-unreachable rule produces Connection refused. Allow the port from the client subnet.

6. The node is up but the RabbitMQ application is stopped

The Erlang node can be running while the RabbitMQ app itself is stopped (e.g., after rabbitmqctl stop_app), leaving 5672 closed.

rabbitmqctl status | grep -iA3 'RabbitMQ version\|Alarms\|listeners'
rabbitmqctl list_connections 2>&1 | head -3

Error: unable to perform an operation on node 'rabbit@mq-01'.
 * the RabbitMQ application is not running on node rabbit@mq-01

Start the app to open the listeners.

rabbitmqctl start_app

Diagnostic Workflow

Step 1: Confirm whether the refusal is from the broker or the network path

curl -v telnet://<HOST>:5672 --max-time 5

Instant “Connection refused” = REJECT or no listener. A hang-then-timeout = DROP firewall — a different problem (treat as a blocked, not refused, port).

Step 2: Verify the broker process and app are running on the node

sudo systemctl status rabbitmq-server --no-pager | head -5
rabbitmqctl status | head -20

If you see “RabbitMQ application is not running”, run rabbitmqctl start_app. If the node is down entirely, sudo systemctl start rabbitmq-server.

Step 3: Inspect which listeners are actually bound

rabbitmqctl environment | grep -A6 'tcp_listeners\|ssl_listeners'
sudo ss -ltnp | grep -E ':5672|:5671'

Confirm 5672 (or 5671) is listening and on an interface the client can reach. 127.0.0.1:5672 only means remote clients are refused.

Step 4: Validate the client target matches reality

getent hosts <BROKER_HOSTNAME>

Check the resolved IP and port against the actual listener. Test from the client host itself, not the broker, to include the network path.

Step 5: Check firewalls between client and broker

sudo iptables -L INPUT -n | grep -E '5672|5671'
# cloud: confirm the security group / NSG allows the client CIDR to 5672/5671

Remove or fix any REJECT rule and allow the AMQP port from the client subnet, then retry the connection.

Example Root Cause Analysis

A worker fleet that ran fine for months suddenly logs ECONNREFUSED 10.0.4.21:5672 after a maintenance window. The broker host is reachable by SSH, and rabbitmqctl status on mq-01 reports the node healthy with listeners on [::]:5672.

Testing from a worker host shows an instant refusal, while testing from the broker host itself (curl telnet://127.0.0.1:5672) succeeds. That split — local works, remote refused — points at the network path or interface binding, not the broker.

Checking the firewall on the broker:

sudo iptables -L INPUT -n --line-numbers | grep 5672

2    REJECT     tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:5672 reject-with icmp-port-unreachable

The maintenance window reapplied a baseline iptables ruleset that no longer included the allow rule for the worker subnet, and a default REJECT now matched 5672. Fix:

sudo iptables -I INPUT 1 -p tcp -s 10.0.5.0/24 --dport 5672 -j ACCEPT
sudo netfilter-persistent save

Workers reconnect immediately. The fix was network policy, not RabbitMQ — the instant RST (not a timeout) was the tell.

Prevention Best Practices

• Make the listener binding explicit and intentional: set listeners.tcp.default = 5672 on a reachable interface, and never leave it accidentally on loopback in clustered deployments.
• Manage firewall rules through config management so a baseline reapply cannot silently drop the AMQP allow rule for client subnets.
• Use a stable DNS name or VIP for clients, not hardcoded IPs, so a broker move does not turn into a refused-connection incident.
• If you run TLS-only (5671), document it and fail loudly in client config validation rather than letting apps default to 5672.
• Add a synthetic check that opens a TCP socket to 5672/5671 from a client-network host and alerts on refusal, so you catch this before the app fleet does.
• For fast triage of a connection-refused page, the free incident assistant can turn the client error and rabbitmqctl status output into a likely cause. More patterns in the RabbitMQ guides.

Quick Command Reference

# Is the port refusing or dropping?
curl -v telnet://<HOST>:5672 --max-time 5

# Broker and app state
sudo systemctl status rabbitmq-server --no-pager | head -5
rabbitmqctl status | head -20
rabbitmqctl start_app

# What is actually listening, and where
rabbitmqctl environment | grep -A6 'tcp_listeners\|ssl_listeners'
sudo ss -ltnp | grep -E ':5672|:5671'

# Client target sanity
getent hosts <BROKER_HOSTNAME>

# Firewall rules for the AMQP port
sudo iptables -L INPUT -n | grep -E '5672|5671'

Conclusion

ECONNREFUSED on 5672 is a transport failure: the socket was actively rejected before any AMQP handshake. The usual root causes:

1. The RabbitMQ service is stopped or the node has crashed.
2. The RabbitMQ application is stopped on a running Erlang node (start_app needed).
3. The AMQP listener is bound to loopback or the wrong interface.
4. The client targets the wrong host/port via stale DNS or config.
5. The broker is TLS-only on 5671 while the client uses 5672.
6. A firewall or security group REJECTs the AMQP port.

Determine first whether the refusal comes instantly (broker/firewall reject) or as a timeout (DROP), then confirm the listener binding and the network path between client and broker.