Port 1883 MQTT – Free, Online, Private

What listens on 1883

Port 1883 is MQTT without TLS. The IANA name is mqtt, Message Queuing Telemetry, from OASIS. A client opens TCP, sends a CONNECT packet, and then publishes or subscribes. The protocol is binary, not HTTP, so a browser request to http://host:1883 does not test it. Port 8883 is the same protocol after a TLS handshake. WebSocket MQTT is a different listener, often on 80 or 443, and it is not assigned this number. The registry lists UDP 1883. Brokers use TCP. A load balancer in front of a broker has to speak TCP, with a long idle timeout, because MQTT sessions sit quiet.

The IANA service name is mqtt: Message Queuing Telemetry Transport Protocol. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 1883. The service described here is the TCP one. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 1883

Service notes for port 1883: the IANA name is mqtt (Message Queuing Telemetry Transport Protocol), and the program people mean is MQTT. TCP 1883 is the IANA mqtt port, cleartext MQTT. MQTT over TLS is 8883, secure-mqtt. Brokers do not speak MQTT on UDP. Cleartext 1883 on a public address leaks topic names and payloads and accepts anonymous clients if you left anonymous enabled. Disable anonymous access, or bind the cleartext port to the device VLAN and use 8883 everywhere else. ACL the topics. A client that can subscribe to # will read every message. A client that can publish to a command topic will drive whatever is listening. TLS on 8883 does not replace those ACLs. It only protects the path. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 1883, you are on the wrong page.

Devices configured with port 1883 and a TLS flag set will fail the first packet, and devices with 8883 and TLS off will send a CONNECT into a TLS listener. Match them. Another trap is a broker bound to localhost inside a container while the compose file publishes nothing. Another is a firewall timeout shorter than the keepalive, so the session drops and the device reconnects in a loop. Another is testing with nc and not knowing what a CONNECT looks like. Use a real client. Shared subscriptions and persistent sessions survive a broker restart only if you configured them.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 1883 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. A public broker should show 8883, not a world-reachable 1883. On a lab machine, 1883 on localhost is reasonable. mosquitto or the broker process name should own the socket.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• 1883 is cleartext. 8883 is TLS. They are different listeners.
• MQTT is not HTTP. A browser is the wrong probe.
• UDP 1883 is in the registry and is not the broker transport.
• Anonymous access on a reachable 1883 will be used.

Linuxsudo ss -lptn 'sport = :1883'
sudo lsof -nP -iTCP:1883 -sTCP:LISTEN

macOSsudo lsof -nP -iTCP:1883 -sTCP:LISTEN
netstat -anv -p tcp | grep '\.1883[^0-9]'

Windowsnetstat -ano | findstr :1883
Get-NetTCPConnection -LocalPort 1883

Remotenc -vz host 1883