Introduction

ACCESS_REFUSED - Login was refused is one of the most common RabbitMQ connection errors, and it almost always points to an authentication or virtual-host problem rather than a networking failure. The broker is reachable, but it is rejecting the login details or refusing access to the requested vhost. The fastest way to solve it is to check credentials, vhost, permissions, and special RabbitMQ defaults such as the restricted guest user.

Start with the Connection Details

A RabbitMQ client usually connects with a URI or a set of host parameters.

Example URI:

amqp://appuser:[email protected]:5672/%2F

Important parts:

• 'appuser is the username'
• 'secret is the password'
• '%2F is the default vhost /'

That last part trips people up. In URI form, the default vhost / must be URL-encoded as %2F.

If you are using a library with separate parameters instead of a URI, make sure the vhost value is also correct there.

The guest User Is Special

RabbitMQ ships with a guest user by default, and by default that user is restricted to localhost connections only.

That means this may work on the RabbitMQ server itself:

amqp://guest:guest@localhost:5672/%2F

but the same credentials can fail from another machine with ACCESS_REFUSED.

If your application connects remotely, create a dedicated user instead:

rabbitmqctl add_user appuser secret
rabbitmqctl set_permissions -p / appuser ".*" ".*" ".*"

That is usually the right fix instead of trying to rely on guest.

Verify Users, Vhosts, and Permissions

From the broker host, check the current setup.

List users:

rabbitmqctl list_users

List virtual hosts:

rabbitmqctl list_vhosts

List permissions for one vhost:

rabbitmqctl list_permissions -p /

Create a vhost and grant access:

rabbitmqctl add_vhost app-vhost
rabbitmqctl set_permissions -p app-vhost appuser ".*" ".*" ".*"

The user must exist, the vhost must exist, and the user must have permissions on that vhost. Missing any one of those can produce the same login-refused error.

Confirm the Client and Broker Agree

Sometimes the credentials are correct but the client still points at the wrong vhost or wrong username because of configuration layering.

A Python example with explicit parameters:

1import pika
2
3credentials = pika.PlainCredentials("appuser", "secret")
4params = pika.ConnectionParameters(
5    host="rabbitmq.example.com",
6    port=5672,
7    virtual_host="/",
8    credentials=credentials,
9)
10
11connection = pika.BlockingConnection(params)
12print("connected")
13connection.close()

This is easier to debug than a large framework config because each connection field is visible directly.

Less Common Causes

Most cases are credentials or permissions, but a few other issues show up too:

• the user was created in one broker node but the client is hitting a different environment
• the password contains characters that were not escaped properly in a URI
• TLS is required, but the client is trying plain AMQP on the TLS listener or vice versa
• an authentication backend or plugin is configured differently than expected

Those are less common than the basic user-vhost mismatch, but they do happen in production systems.

Common Pitfalls

The most common mistake is using guest from a remote host. RabbitMQ blocks that by default.

Another frequent problem is forgetting that the default vhost / is encoded as %2F in connection URIs. A malformed URI can make valid credentials look wrong.

Some developers also create the user and forget to grant permissions on the target vhost. Authentication may succeed, but authorization fails immediately.

Finally, be careful with configuration duplication. A wrong username in an environment variable can silently override the value you think the application is using.

Summary

• 'ACCESS_REFUSED - Login was refused usually means bad credentials, wrong vhost, or missing permissions.'
• Do not use the default guest user for remote connections.
• Verify users, vhosts, and permissions with rabbitmqctl.
• Encode the default vhost / as %2F in AMQP URIs.
• When in doubt, test with explicit connection parameters to isolate configuration mistakes.