Introduction

If guest/guest stopped working in RabbitMQ 3.3.1, the usual explanation is not that the password is wrong. Since RabbitMQ 3.3.0, the built-in guest user is restricted to loopback connections by default, which means it can log in only from the same machine where RabbitMQ is running.

So the key question is where the login is coming from. Localhost access may still work, while the same credentials fail from another host or through the management UI over the network.

Why guest/guest Fails Remotely

RabbitMQ ships with a default guest user. For security reasons, that account is normally limited to loopback interfaces such as 127.0.0.1.

In the older Erlang-style configuration used around RabbitMQ 3.3.x, the relevant setting looks like this:

1[
2  {rabbit, [
3    {loopback_users, [<<"guest">>]}
4  ]}
5].

That setting means:

• 'guest can connect from the local machine'
• 'guest cannot connect from another machine on the network'

So if your application or browser is remote, guest/guest is expected to fail even when the credentials are technically correct.

The Recommended Fix: Create a Real User

The best fix is usually not to weaken the guest account. Instead, create a dedicated user and grant only the permissions that user needs.

Example:

rabbitmqctl add_user appuser strongpassword
rabbitmqctl set_permissions -p / appuser ".*" ".*" ".*"
rabbitmqctl set_user_tags appuser administrator

After that, log in with appuser instead of guest.

If you do not need management UI admin access, skip the administrator tag and assign a more limited role.

Testing the Localhost Rule

A quick way to confirm the cause is to test from the RabbitMQ host itself.

If guest/guest works locally but fails remotely, you are almost certainly hitting the loopback restriction rather than an authentication typo.

For example, a local management UI URL might work as expected:

http://localhost:15672/

But the same account can fail from:

http://server-name:15672/

That difference is exactly what the default security setting is designed to enforce.

If You Really Must Allow Remote guest

You can remove the loopback restriction, but this is usually a bad production idea. In older RabbitMQ versions, that means changing the configuration so the list is empty:

1[
2  {rabbit, [
3    {loopback_users, []}
4  ]}
5].

After changing the config, restart RabbitMQ.

This permits remote login for guest, but it also weakens a deliberate security default. In practice, using a dedicated named user is the safer and more maintainable approach.

Permissions Matter Too

Authentication and authorization are separate. Even if the user can log in, RabbitMQ permissions may still block access to exchanges, queues, or virtual hosts.

A common setup for a non-default virtual host looks like this:

rabbitmqctl add_vhost /myapp
rabbitmqctl add_user myappuser strongpassword
rabbitmqctl set_permissions -p /myapp myappuser ".*" ".*" ".*"

If a login succeeds but the application still cannot publish or consume, check permissions next.

Management UI and AMQP Clients

This same guest restriction affects both the management UI and AMQP clients. So a failure in a browser and a failure in application code can come from the same root cause.

For example, application connection code might look like this:

1import pika
2
3credentials = pika.PlainCredentials("appuser", "strongpassword")
4params = pika.ConnectionParameters("rabbitmq.example.com", 5672, "/", credentials)
5connection = pika.BlockingConnection(params)
6print("connected")

If you swap in guest/guest from a remote host and it fails, that is consistent with the default loopback rule.

Common Pitfalls

The biggest mistake is assuming guest/guest is a normal remote default account. In RabbitMQ 3.3.1, it is intentionally restricted to localhost.

Another common issue is editing the config to allow remote guest instead of creating a proper application user. That may solve the immediate problem but creates an unnecessary security risk.

People also forget that permissions and login are separate concerns. A user may authenticate successfully and still be blocked from a virtual host or queue.

Finally, do not assume every guide uses the same configuration file format. RabbitMQ 3.3.1 used the older Erlang-style config, while newer versions often use rabbitmq.conf.

Summary

• In RabbitMQ 3.3.1, guest/guest is normally allowed only from localhost.
• Remote login failures with guest/guest are usually expected behavior, not a broken password.
• The recommended solution is to create a dedicated user and assign the right permissions.
• You can disable the loopback restriction, but that is usually a poor security tradeoff.
• If login works but messaging still fails, check virtual host permissions next.