Fix: RabbitMQ Connection Refused Error

The Error

You try to connect to RabbitMQ from your application and get:

AMQPConnectionError: Connection refused (111)

Or in Python with Pika:

pika.exceptions.AMQPConnectionError: Connection to 127.0.0.1:5672 failed

Or in Node.js with amqplib:

Error: connect ECONNREFUSED 127.0.0.1:5672

The application can’t establish a TCP connection to the RabbitMQ server.

Why This Happens

The kernel returns ECONNREFUSED (errno 111 on Linux) when a TCP SYN reaches the destination but no process is listening on that port for the interface the packet arrived on. This is fundamentally different from a timeout: refused means the host is reachable, the packet got there, and the OS actively rejected the connection. The host is up — something is wrong with the listener, the bind address, or the port the client is hitting.

RabbitMQ exposes several ports and binding the wrong one is the most common root cause. The AMQP protocol listens on 5672 by default, but the management UI runs on 15672, the AMQP-over-TLS port is 5671, the Erlang clustering port is 25672, and the EPMD port mapper is 4369. Clients that target 15672 expecting AMQP, or 5672 expecting TLS, get refused immediately. Worse, if rabbitmq.conf sets listeners.tcp = none to enforce TLS-only mode, the plain port disappears and every non-TLS client breaks at once with no obvious change on the server.

There’s also a class of failures that succeeds at TCP but fails immediately after. The handshake completes, then RabbitMQ rejects the connection because the user can’t authenticate, the user lacks permission on the requested vhost, or the default guest user is being used from a non-localhost source. Client libraries report this in different ways — some surface it as ConnectionClosedByBroker, others as AccessRefused, and some libraries swallow the broker reason and just say “connection refused.” Treating these as the same problem is what makes the error so frustrating to diagnose.

Diagnostic Timeline

Use this order. Each step takes under a minute and isolates one cause.

• Minute 0 — Confirm whether you’re refused at TCP or rejected at AMQP. Run nc -zv <host> 5672. If nc reports “succeeded” the TCP listener is up and the problem is authentication, vhost, or TLS negotiation. If it reports “Connection refused” no process is listening at the address you targeted.
• Minute 1 — Check what RabbitMQ is actually listening on. On the server, run sudo rabbitmq-diagnostics listeners (or sudo rabbitmqctl status | grep -A20 Listeners). This prints every interface and port, including whether AMQP is on 127.0.0.1 only or on 0.0.0.0. A bind to 127.0.0.1 refuses every connection from another machine even though netstat shows the port open.
• Minute 2 — Compare client port and server port. The most common mistake is hitting 15672 (the management HTTP UI) with an AMQP client. AMQP is 5672; AMQPS is 5671. Management is not an AMQP endpoint and refuses any AMQP framing.
• Minute 3 — Test as guest from localhost. SSH to the RabbitMQ host and run rabbitmqadmin list connections. If management isn’t installed, rabbitmqctl list_connections. This confirms the broker accepts local connections and isolates the problem to the network or the credentials.
• Minute 4 — If TCP connects but the handshake fails, read the server log. sudo tail -100 /var/log/rabbitmq/rabbit@<hostname>.log. Look for access_refused, vhost_access_refused, or authentication_failure. These appear immediately after the failed handshake and tell you exactly which check rejected the connection.
• Minute 5 — Check firewall and security group rules. sudo iptables -L -n -v or your cloud security-group config. A new rule added after the broker came up will refuse new connections without restarting the broker, so this is invisible from RabbitMQ’s perspective.
• Minute 6 — Confirm the vhost exists. sudo rabbitmqctl list_vhosts. A connection to a missing vhost is refused at handshake with a generic “not found” message that many clients render as “connection refused.”

Fix 1: Verify the Service Is Running

Check if RabbitMQ is actually running:

# Linux (systemd)
sudo systemctl status rabbitmq-server

# Check if the process exists
ps aux | grep rabbitmq

# Check if the port is open
ss -tlnp | grep 5672

If it’s not running, start it:

sudo systemctl start rabbitmq-server
sudo systemctl enable rabbitmq-server

Check the RabbitMQ logs for startup errors:

sudo tail -50 /var/log/rabbitmq/[email protected]

Common startup failures include Erlang cookie mismatches, port conflicts, and insufficient file descriptor limits.

Pro Tip: RabbitMQ depends on the Erlang runtime. If you upgraded Erlang separately, version incompatibility can prevent RabbitMQ from starting. Check compatibility at the RabbitMQ Erlang version requirements page.

Fix 2: Fix Port Configuration

RabbitMQ uses multiple ports:

A common mistake is connecting to 15672 (the management HTTP API) instead of 5672 (the AMQP protocol port):

# Wrong - management UI port
connection = pika.BlockingConnection(
    pika.ConnectionParameters(host='localhost', port=15672)
)

# Correct - AMQP port
connection = pika.BlockingConnection(
    pika.ConnectionParameters(host='localhost', port=5672)
)

Verify which port RabbitMQ is listening on:

sudo rabbitmqctl status | grep -A5 "Listeners"

Fix 3: Fix Credentials

RabbitMQ ships with a default guest user, but since version 3.3.0, the guest user can only connect from localhost:

# This fails from a remote machine
credentials = pika.PlainCredentials('guest', 'guest')
connection = pika.BlockingConnection(
    pika.ConnectionParameters(host='remote-server', credentials=credentials)
)

Create a new user for remote connections:

# Create user
sudo rabbitmqctl add_user myapp mypassword

# Set permissions
sudo rabbitmqctl set_permissions -p / myapp ".*" ".*" ".*"

# Optionally grant admin tag for management UI
sudo rabbitmqctl set_user_tags myapp administrator

Then connect with the new credentials:

credentials = pika.PlainCredentials('myapp', 'mypassword')
connection = pika.BlockingConnection(
    pika.ConnectionParameters(host='remote-server', credentials=credentials)
)

Common Mistake: If you override the guest user restrictions with loopback_users = none in rabbitmq.conf, you’re exposing a well-known default credential to the network. Always create dedicated users instead.

Fix 4: Fix Virtual Host Permissions

RabbitMQ uses virtual hosts (vhosts) to isolate environments. Users must have permissions on the vhost they’re connecting to:

# List vhosts
sudo rabbitmqctl list_vhosts

# Check user permissions
sudo rabbitmqctl list_user_permissions myapp

If the user lacks permissions on the target vhost:

# Create a vhost
sudo rabbitmqctl add_vhost my-app-vhost

# Grant permissions
sudo rabbitmqctl set_permissions -p my-app-vhost myapp ".*" ".*" ".*"

In your connection string, specify the vhost:

connection = pika.BlockingConnection(
    pika.ConnectionParameters(
        host='localhost',
        virtual_host='my-app-vhost',
        credentials=pika.PlainCredentials('myapp', 'mypassword')
    )
)

The three ".*" patterns in set_permissions control configure, write, and read access. ".*" grants full access. Restrict in production:

# Only allow access to queues starting with "myapp."
sudo rabbitmqctl set_permissions -p my-app-vhost myapp "^myapp\..*" "^myapp\..*" "^myapp\..*"

Fix 5: Fix Firewall Rules

If RabbitMQ is on a remote server, the firewall must allow traffic on port 5672:

# UFW (Ubuntu)
sudo ufw allow 5672/tcp
sudo ufw allow 15672/tcp

# firewalld (CentOS/RHEL)
sudo firewall-cmd --permanent --add-port=5672/tcp
sudo firewall-cmd --permanent --add-port=15672/tcp
sudo firewall-cmd --reload

# iptables
sudo iptables -A INPUT -p tcp --dport 5672 -j ACCEPT

For cloud providers, also check security groups:

• AWS: Edit the security group’s inbound rules for the EC2 instance
• GCP: Create a firewall rule allowing TCP 5672
• Azure: Add an inbound port rule in the network security group

Verify external access from the client machine:

telnet rabbitmq-server 5672
# or
nc -zv rabbitmq-server 5672

Fix 6: Fix Docker Networking

Running RabbitMQ in Docker has specific networking considerations:

# Wrong - container only accessible from inside Docker
docker run -d rabbitmq

# Correct - expose port to host
docker run -d -p 5672:5672 -p 15672:15672 rabbitmq:management

For Docker Compose, services connect using the service name as hostname, not localhost:

services:
  rabbitmq:
    image: rabbitmq:management
    ports:
      - "5672:5672"
      - "15672:15672"
  app:
    build: .
    depends_on:
      - rabbitmq
    environment:
      - RABBITMQ_HOST=rabbitmq  # Not localhost!

From inside the app container, connect to rabbitmq:5672. From the host machine, connect to localhost:5672.

If the application starts before RabbitMQ is ready, add a health check and wait:

services:
  rabbitmq:
    image: rabbitmq:management
    healthcheck:
      test: rabbitmq-diagnostics -q ping
      interval: 10s
      timeout: 5s
      retries: 5
  app:
    depends_on:
      rabbitmq:
        condition: service_healthy

Fix 7: Configure TLS/SSL Connections

If RabbitMQ is configured for TLS-only connections, plain AMQP on port 5672 won’t work:

# rabbitmq.conf
listeners.tcp = none
listeners.ssl.default = 5671
ssl_options.cacertfile = /etc/rabbitmq/ca_certificate.pem
ssl_options.certfile = /etc/rabbitmq/server_certificate.pem
ssl_options.keyfile = /etc/rabbitmq/server_key.pem

Connect using AMQPS (port 5671):

import ssl

context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
context.verify_mode = ssl.CERT_REQUIRED
context.load_verify_locations('/path/to/ca_certificate.pem')

ssl_options = pika.SSLOptions(context, 'rabbitmq-server')
connection = pika.BlockingConnection(
    pika.ConnectionParameters(
        host='rabbitmq-server',
        port=5671,
        ssl_options=ssl_options,
        credentials=pika.PlainCredentials('myapp', 'mypassword')
    )
)

Verify TLS is working:

openssl s_client -connect rabbitmq-server:5671

Fix 8: Fix Connection Limits

RabbitMQ may refuse new connections if limits are reached:

# Check current connections
sudo rabbitmqctl list_connections name state | wc -l

# Check file descriptor limits
sudo rabbitmqctl status | grep -A3 "File Descriptors"

Increase file descriptor limits in /etc/systemd/system/rabbitmq-server.service.d/limits.conf:

[Service]
LimitNOFILE=65536

Then reload:

sudo systemctl daemon-reload
sudo systemctl restart rabbitmq-server

Also check for connection leaks in your application. Each connection and channel should be properly closed:

try:
    connection = pika.BlockingConnection(params)
    channel = connection.channel()
    # ... use channel
finally:
    connection.close()

Still Not Working?

• Check the Erlang cookie. Nodes in a cluster must share the same cookie at /var/lib/rabbitmq/.erlang.cookie. A mismatch prevents inter-node communication.

• Verify DNS resolution. If using hostnames, ensure they resolve correctly from both the client and server.

• Check for memory alarms. RabbitMQ blocks connections when memory exceeds the threshold. Run sudo rabbitmqctl status | grep alarms to check.

• Test with the management API. If the management plugin is enabled, curl -u guest:guest http://localhost:15672/api/overview shows cluster status without needing an AMQP client.

• Look for port conflicts. Another service might be using port 5672. Check with ss -tlnp | grep 5672.

• Review the connection string format. AMQP URLs follow the format amqp://user:pass@host:port/vhost. The vhost must be URL-encoded if it contains special characters.

• Confirm the listener is bound to 0.0.0.0, not 127.0.0.1. RabbitMQ binds to all interfaces by default, but listeners.tcp.local = 127.0.0.1:5672 in rabbitmq.conf restricts it to localhost. From outside the host you’ll get refused even though netstat on the server shows the port open. Change to listeners.tcp.default = 5672 for all-interface binding.

• Check the disk_free_limit alarm. RabbitMQ blocks publishers when free disk drops below the limit (default 50MB), and some client libraries report the block as a connection refusal because the channel never opens. Inspect with rabbitmqctl status | grep -i alarm. Free disk space or raise the limit to clear it.

• Verify the Erlang VM didn’t OOM at startup. A node can exit with status 137 mid-boot, leaving systemd “active” briefly before the next restart. Check with journalctl -u rabbitmq-server --since "10 minutes ago". If the VM is being killed, increase the host’s vm.overcommit_memory to 1 or raise LimitMEMLOCK in the unit file.

• Watch for definitions.json import failures. If the broker is configured to import definitions on boot (management.load_definitions = /etc/rabbitmq/definitions.json) and the file is malformed, the AMQP listener never starts. The log shows the import error; the symptom is “refused on 5672 even though the service is active.”

• Inspect for stale epmd state. If you stopped a node uncleanly and restarted it on a different IP, epmd (the Erlang port mapper) may still advertise the old binding. Stop the broker, run epmd -kill (you may need to also stop systemd-managed epmd.socket), and start RabbitMQ again. The new node will re-register with the correct address.

• Check inet_dist_listen_min / inet_dist_listen_max overlap. Clusters that pin the Erlang distribution port range can collide with the AMQP listener if the ranges overlap. The first listener to start wins and the second silently refuses. Confirm the ranges in rabbitmq.conf and the running ports with rabbitmq-diagnostics listeners.

• Validate the client AMQP URI scheme. amqp:// for plain, amqps:// for TLS. A typo (ampq://, amqp+ssl://) is parsed by some libraries as plain AMQP on the default port, which is then refused by a TLS-only listener.