MQTT ports decide how your devices reach a broker, whether traffic is encrypted, and whether a corporate firewall lets it through at all. This guide explains the four ports you will meet in practice (1883, 8883, 8083 and 8084), when to use each, and how to test every one of them in a few minutes against a live broker.
The Short Answer: Four Common MQTT Ports
MQTT itself is an application protocol that runs over a reliable byte stream. How that stream is carried determines the port (if you are unsure why it is always TCP, read is MQTT TCP or UDP). IANA has registered 1883 for MQTT and 8883 for MQTT over TLS. WebSocket ports are a convention rather than a registration, and brokers vary; ConnectMQ uses 8083 and 8084.
| Port | Transport | Encrypted | Typical clients | Use in production? |
|---|---|---|---|---|
| 1883 | MQTT over TCP | No | CLI tools, lab devices, local networks | Only on trusted, isolated networks |
| 8883 | MQTT over TLS over TCP | Yes | Devices, gateways, backend services | Yes, the default choice |
| 8083 | MQTT over WebSocket (ws://) |
No | Browser demos, local tests | Rarely |
| 8084 | MQTT over secure WebSocket (wss://) |
Yes | Browsers, mobile web apps, restrictive networks | Yes, for web clients |
On ConnectMQ, both WebSocket endpoints use the path /mqtt, so the full browser URL is wss://broker.connectmq.com:8084/mqtt. The TLS ports present a Let's Encrypt certificate, which is trusted by default on almost every operating system and browser.
Port 1883: Plain MQTT over TCP
Port 1883 carries raw MQTT packets with no encryption. Usernames, passwords and payloads cross the network in clear text, readable by anyone who can capture traffic along the path. That makes 1883 fine for:
- Learning and quick experiments on a public MQTT test broker.
- A local broker inside an isolated lab network.
- Very constrained devices talking to a nearby gateway on a segment you control.
It is not fine for credentials going over the internet. If you see a production fleet on 1883, treat it as a finding to fix.
Port 8883: MQTT over TLS
Port 8883 wraps the same MQTT packets in a TLS session. The client verifies the broker's certificate against a trusted certificate authority, negotiates keys, and only then sends the CONNECT packet with its credentials. This is the standard choice for devices, gateways and backend services.
What 8883 asks of the client:
- A TLS library (mbedTLS on ESP32, OpenSSL in most Linux tools, the platform stack in .NET and Java).
- A trusted CA bundle so the broker certificate can be verified. Never disable verification in production.
- A reasonably accurate clock, because certificate validity is time-based. Devices without a real-time clock should sync NTP before connecting.
- Server Name Indication (SNI) set to the broker hostname. Most libraries do this automatically when you connect by hostname.
The extra cost is a handshake on connect and slightly larger packets. Because MQTT keeps one long-lived connection, that handshake happens rarely, so the steady-state overhead is small. Our MQTT security best practices guide covers the rest of the hardening list.
Ports 8083 and 8084: MQTT over WebSocket
Browsers cannot open raw TCP sockets, so web apps tunnel MQTT inside WebSocket frames. The client first sends an HTTP upgrade request to a path (here /mqtt) and then exchanges binary MQTT packets over the upgraded connection.
- 8083 (
ws://) is unencrypted. Modern browsers block it from pages served over HTTPS (mixed content), so it is mostly useful for local tests. - 8084 (
wss://) is WebSocket over TLS, the only realistic option for a production web dashboard.
WebSocket has a second benefit: it looks like ordinary HTTPS traffic to many proxies and firewalls. When a factory or hotel network blocks 8883, wss:// on 8084 sometimes gets through where raw TLS does not. See MQTT over WebSocket for browser code and proxy caveats.
Firewall Implications
MQTT clients always initiate the connection outbound to the broker, and the broker pushes data back over that same connection. That simplifies firewall rules a lot:
- Allow outbound TCP from device networks to the broker hostname on 8883 (and 8084 if you have web clients).
- No inbound rules are needed on the device side. Devices do not listen on any MQTT port.
- Allow long-lived connections. Some firewalls and NAT gateways silently drop idle TCP sessions after a few minutes. Set the MQTT keep-alive interval shorter than that timeout (60 seconds is a common choice) so PINGREQ packets keep the mapping alive.
- Avoid TLS interception for MQTT. Middleboxes that re-sign certificates break certificate verification on devices. Whitelist the broker hostname from inspection.
- Prefer hostnames over IP allowlists where your firewall supports it, because cloud endpoints can change addresses.
If you only get one port opened, ask for 8883. If even that is impossible, ask for 8084 and run your clients over secure WebSocket.
Test Every MQTT Port in Five Minutes
The commands below use the anonymous public endpoint at broker.connectmq.com. Use a unique client ID and topic prefix, and remember that public topics are visible to everyone.
Check TCP reachability
# Linux / macOS
nc -vz broker.connectmq.com 1883
nc -vz broker.connectmq.com 8883
nc -vz broker.connectmq.com 8084
On Windows PowerShell, use Test-NetConnection broker.connectmq.com -Port 8883 and look for TcpTestSucceeded : True.
Inspect the TLS certificate on 8883
openssl s_client -connect broker.connectmq.com:8883 \
-servername broker.connectmq.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
You should see a Let's Encrypt issuer and valid dates. If the issuer is your company's proxy instead, TLS interception is in the way.
Publish and subscribe on 1883 and 8883
# Terminal A: subscribe over TLS (mosquitto enables TLS when a CA path is given)
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i ports-sub-91c2 -t "connectmq/demo/91c2/#" -v
# Terminal B: publish over plain TCP
mosquitto_pub -h broker.connectmq.com -p 1883 -i ports-pub-91c2 \
-t "connectmq/demo/91c2/hello" -m "sent on 1883, received on 8883"
The message crosses from one port to the other, which shows that ports are just entry points to the same broker.
Test secure WebSocket on 8084 with Node.js
// npm install mqtt
const mqtt = require("mqtt");
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId: "ports-wss-91c2",
protocolVersion: 5,
});
client.on("connect", () => {
console.log("Connected over wss on 8084");
client.subscribe("connectmq/demo/91c2/#", () => {
client.publish("connectmq/demo/91c2/wss", "hello from WebSocket");
});
});
client.on("message", (topic, payload) => {
console.log(topic, payload.toString());
client.end();
});
client.on("error", (err) => console.error("Error:", err.message));
For raw TLS from Node, swap the URL for mqtts://broker.connectmq.com:8883.
Troubleshooting Port Problems
| Symptom | Likely cause | Fix |
|---|---|---|
| Connection timeout on 8883, 1883 works | Firewall allows only common ports | Request outbound 8883 or use 8084 |
| TLS handshake fails, certificate unknown | Missing CA bundle or TLS inspection | Install CA certificates, bypass inspection for the broker host |
| Certificate not yet valid | Device clock is wrong | Sync NTP before connecting |
| WebSocket returns 404 | Wrong path | Use /mqtt |
Browser refuses ws:// |
Mixed content on an HTTPS page | Use wss:// on 8084 |
| Disconnects every few minutes | NAT idle timeout | Lower keep-alive below the timeout |
Moving from Test Ports to Production
On the public broker you connect anonymously; on a private broker you add credentials. When you create a broker in the ConnectMQ portal you receive a username, password and client ID bound to those credentials, and the same four ports apply. A typical production setup uses 8883 for devices and gateways and 8084 for the web dashboard, with 1883 and 8083 left for local debugging. Because ConnectMQ is a hosted MQTT broker, certificates are renewed for you and there is no listener configuration to maintain. The cloud MQTT broker guide compares hosting options in more depth, and the MQTT tutorial for beginners walks through your first connection end to end.
Get Started with ConnectMQ
Create a free Serverless broker at app.connectmq.com, no credit card needed, and connect on 8883 or 8084 with the credentials the portal generates. ConnectMQ's in-browser client lets you confirm the connection before you touch any firmware.
Frequently Asked Questions
What is the default MQTT port?
The default MQTT port is 1883 for unencrypted TCP and 8883 for MQTT over TLS. Both are registered with IANA.
Which MQTT port should I use in production?
Use 8883 for devices and services and 8084 (secure WebSocket) for browsers. Avoid 1883 over the internet because credentials travel in clear text.
Can I run MQTT on port 443?
Some brokers offer MQTT over WebSocket or TLS on 443 to pass strict firewalls. broker.connectmq.com uses 8883 and 8084, so ask your network team to allow outbound traffic to those ports.
Why does my WebSocket connection fail when TCP works?
The most common causes are a missing /mqtt path, using ws:// from an HTTPS page, or a proxy that does not support WebSocket upgrades.
