Mosquitto: connection refused from other devices

Since version 2, Mosquitto only listens on localhost until you add a listener. Add one, and set how clients log in.

What the message means

Newer versions do not accept remote or anonymous connections by default. A robot on the network is refused until the configuration allows it.

Fix it in this order

Add a listener line for port 1883 to the configuration file.
Create a password file and set allow_anonymous to false, or knowingly allow anonymous access on a closed test network only.
Restart the broker after editing the configuration.
Open port 1883 in the firewall of the broker machine.
Test from another device with a simple client before you test the robot.
Check the broker log for the reason of each refusal.

Why it happens

Mosquitto’s own migration guide explains the behaviour. Started with no configuration, version 2.0 binds only to the loopback interface, so only connections from the same machine work, and anonymous access is allowed only in that mode.

Once a listener is defined in the configuration file, it binds to all interfaces and every listener defaults to allow_anonymous false unless you set it to true. A broker with a listener but no password file or allow_anonymous setting therefore refuses remote clients, and so does an old setup that worked before the upgrade.

If you see this, do this

You see	Do this
Works on the same machine only	Add a listener.
Refused with a not authorised code	Credentials or access rules.

PubSubClient state codes, MQTT on the ESP32.

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.

Why this happens

Mosquitto 2.0 changed how it decides who may connect. If it starts with no configuration file, it listens on the loopback interface only, so only programs on the same machine can reach it. When you add a listener to the configuration file, it binds to all network interfaces, but each listener then refuses anonymous clients unless allow_anonymous is set to true for that listener. A broker that works on the same machine and refuses a robot on the network is the default behaviour, not a fault.

Placement inside the file matters. Settings that belong to a listener, such as the password file and allow_anonymous, apply to the listener line above them. Putting them before the listener line makes them global in a way that may not do what you expect. Also check that the service reads the file you edited, and that it was restarted afterwards.

How to confirm the cause

On the broker machine, check what is listening on port 1883: netstat -an on Windows (look for 1883) or ss -ltn on Linux. 127.0.0.1:1883 means loopback only, and 0.0.0.0:1883 means all interfaces.
From another device, test the port with a tool such as nc -zv broker-ip 1883. A timeout points to a firewall or network, while an immediate refusal points to nothing listening on that interface.
Read the broker log. It states whether the client was refused for authorisation or never reached the broker.
Run mosquitto_sub on the broker machine itself. If that works and the remote one fails, the problem is binding, firewall or credentials.
Check that every client uses a different client ID. Two clients with the same ID keep disconnecting each other.

Worked example

A minimal configuration for a password-protected listener, followed by a test from another machine (names and addresses are examples):

listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd

# create the user:  mosquitto_passwd -c /etc/mosquitto/passwd robot
# restart the broker, then from another device:
# mosquitto_pub -h 192.168.1.20 -t test -m hello -u robot -P yourpassword

Common mistakes

Editing a configuration file that the running service does not use.
Forgetting to restart the broker after a change.
Putting allow_anonymous before the listener line, so it does not apply to that listener.
Opening port 1883 to the whole internet without authentication or encryption.
Running the broker in a container and forgetting to publish the port or mount the configuration.

If this did not fix it

Network: wrong IP address, a changing DHCP address, or a client on a separate network segment.
Protocol: check that the client’s MQTT version setting matches what the broker accepts.
Client IDs: two devices with the same ID cause a loop of disconnects that looks like refusals.

Mosquitto: connection refused from other devices: listener and anonymous access