Port 8883 MQTT over TLS – Free, Online, Private

What listens on 8883

Port 8883 is secure MQTT. The IANA name is secure-mqtt, Secure MQTT, from OASIS. The client performs a TLS handshake and then sends the same MQTT CONNECT it would have sent on 1883. A broker can listen on both. They are different sockets. A load balancer that terminates TLS and forwards to 1883 is a valid design, and then the public port is 8883 and the process inside is bound to 1883. Checking only the inside host will not show 8883. UDP is registered and is not how brokers accept MQTT sessions. WebSocket MQTT over TLS usually stays on 443.

The IANA service name is secure-mqtt: Secure MQTT. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 8883. 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 8883

Service notes for port 8883: the IANA name is secure-mqtt (Secure MQTT), and the program people mean is MQTT over TLS. TCP 8883 is the IANA secure-mqtt port, MQTT over TLS. Cleartext MQTT is 1883. The first packet on 8883 is a ClientHello, not an MQTT CONNECT. Verify the broker certificate in the device. A device that skips verification has moved the cleartext problem into an encrypted channel to an attacker. Use credentials or client certificates. Topic ACLs still matter, because TLS does not decide who may publish to a command topic. Keep 1883 off the public network if every device can do 8883. A broker that offers both and allows anonymous clients on 1883 has not finished the migration. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 8883, you are on the wrong page.

Devices with port 8883 and TLS disabled send CONNECT to a TLS port and get a handshake failure that the firmware reports as 'network error'. Devices with TLS enabled and port 1883 do the reverse. Another trap is a certificate for a private name and a device that connects to a public name. Another is an idle timeout on a middlebox. MQTT keepalive has to be shorter than that timeout, or the session drops. Another is SNI. Several brokers on one address need a certificate that matches the name the device dials.

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 8883 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. TCP 8883 should complete TLS and present the broker certificate. There is no cleartext MQTT banner. A listener on 1883 is the other mode. Test the mode the devices use.

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.

• 8883 is TLS, then MQTT. 1883 is MQTT immediately.
• A missing banner is normal. Do not treat it as a dead broker.
• UDP 8883 is not the session transport.
• Terminating TLS at a proxy means 8883 is on the proxy, not on the broker process.

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

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

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

Remotenc -vz host 8883