MQTT Ports Explained: 1883, 8883, 8083, 8084 and 443

When an MQTT connection fails, the port is the first thing to check. MQTT can run over plain TCP, over TLS, over WebSockets and over secure WebSockets — and each transport usually lives on a different port. Picking the wrong one is the single most common reason a client hangs on Connecting…. This guide explains every common MQTT port, when to use it, and the exact ports of the public brokers you can test against.

MQTT ports at a glance

Only 1883 and 8883 are registered with IANA (as mqtt and secure-mqtt). WebSocket ports are a convention that differs from broker to broker, which is why you should always check the broker's documentation — or our public broker list — before connecting.

MQTT port 1883: plain TCP

MQTT port 1883 is the original, unencrypted transport. The client opens a TCP connection and sends the binary CONNECT packet directly. It has the lowest overhead and is what most embedded devices, command-line tools such as mosquitto_pub and server-side libraries use by default.

The catch: everything — including the username and password inside CONNECT — travels in clear text. Use 1883 on a trusted local network or for throwaway tests, never for credentials or production data crossing the internet.

MQTT port 8883: MQTT over TLS

MQTT port 8883 is the same MQTT protocol wrapped in TLS. The client performs a TLS handshake first, verifies the broker certificate, and only then sends CONNECT. This is the default choice for devices and backend services talking to a broker over the internet.

• The client needs a trusted CA bundle (the system store works for public CAs; self-signed setups need a cafile).
• The hostname you connect to must match the certificate, so connect by name, not by IP address.
• Brokers can additionally require client certificates (mutual TLS) on this or a separate port.

MQTT WebSocket ports: 8083, 8084 and friends

Browsers cannot open raw TCP sockets, so web apps tunnel MQTT through a WebSocket. The client makes an HTTP upgrade request to a path (commonly /mqtt) with the mqtt subprotocol, and from then on MQTT packets flow inside WebSocket frames. There is no single standard MQTT WebSocket port:

• EMQX defaults to 8083 (ws) and 8084 (wss).
• HiveMQ's public broker uses 8000 (ws) and 8884 (wss).
• test.mosquitto.org uses 8080 (ws) and 8081 (wss).
• Many production deployments put WebSockets behind a reverse proxy on 80 / 443.

Port 443: getting through firewalls

Corporate networks, hotel Wi-Fi and mobile carriers often block everything except web ports. Running MQTT over secure WebSockets on 443 makes the traffic look like ordinary HTTPS, so it passes almost anywhere. The Eclipse sandbox at mqtt.eclipseprojects.io does exactly this. Some cloud IoT platforms also accept native MQTT over TLS on 443 and use the TLS ALPN extension to tell it apart from HTTPS on the same port.

Ports of popular public MQTT brokers

test.mosquitto.org also runs extra listeners for specific tests, such as an authenticated listener on 1884 (username rw, password readwrite).

Connect to EMQX on wss port 8084

Putting the port into a connection URL

Most client libraries take a single URL that combines scheme, host, port and (for WebSockets) path:

import mqtt from 'mqtt';

// Node.js only — raw TCP and TLS
mqtt.connect('mqtt://broker.emqx.io:1883');
mqtt.connect('mqtts://broker.emqx.io:8883');

// Browser or Node.js — WebSockets (note the /mqtt path)
mqtt.connect('ws://broker.emqx.io:8083/mqtt');
mqtt.connect('wss://broker.emqx.io:8084/mqtt');

Common port mistakes

• Using mqtt:// on a WebSocket port (or ws:// on 1883). The scheme decides the protocol the client speaks; the port must match it.
• Forgetting the WebSocket path. Many brokers only accept the upgrade on /mqtt; without it you get a 404 or a silent failure.
• Using TLS on a plain port. mqtts:// on 1883 fails with a TLS handshake error such as wrong version number.
• Testing only from your own network. A port that works in the office may be blocked on cellular or guest Wi-Fi. Test from the network your devices will actually use.
• Exposing 1883 to the internet with anonymous access. Internet-wide scanners find open MQTT brokers quickly. If a broker must be reachable, require credentials and prefer TLS.

How to check whether an MQTT port is open

Before blaming your code, confirm the port is reachable from your network:

# Is the TCP port open?
nc -vz broker.hivemq.com 1883

# Does the TLS port complete a handshake with a valid certificate?
openssl s_client -connect broker.hivemq.com:8883 -servername broker.hivemq.com </dev/null

# Full MQTT round trip over TLS
mosquitto_sub -h broker.hivemq.com -p 8883 --capath /etc/ssl/certs -t 'testmqtt/port-check' -v

A timeout usually means a firewall drops the traffic; connection refused means nothing is listening on that port. Our MQTT connection errors guide covers both.

Opening ports on your own broker

If you run Mosquitto yourself, each port is a separate listener. A typical setup keeps 1883 bound to localhost and exposes only encrypted listeners publicly:

# Plain MQTT, local clients only
listener 1883 127.0.0.1

# MQTT over TLS
listener 8883
certfile /etc/mosquitto/certs/server.crt
keyfile  /etc/mosquitto/certs/server.key

# Secure WebSockets for browsers
listener 8084
protocol websockets
certfile /etc/mosquitto/certs/server.crt
keyfile  /etc/mosquitto/certs/server.key

allow_anonymous false
password_file /etc/mosquitto/passwd

Remember to open the same ports in your cloud firewall or security group.

Which MQTT port should you use?

• Device or backend over the internet: 8883 (TLS).
• Browser app: the broker's wss:// port, ideally 443.
• Restrictive network: wss:// on 443.
• Local development or a quick public-broker test: 1883 is fine.

Ready to try one? Open the online MQTT client, choose a broker and the secure WebSocket port is filled in for you.

Frequently asked questions