MQTT-Ports entscheiden darüber, wie Ihre Geräte einen Broker erreichen, ob der Datenverkehr verschlüsselt ist und ob eine Firmen-Firewall ihn überhaupt durchlässt. Dieser Leitfaden erklärt die vier Ports, denen Sie in der Praxis begegnen (1883, 8883, 8083 und 8084), wann Sie welchen verwenden und wie Sie jeden davon in wenigen Minuten gegen einen laufenden Broker testen.
Die kurze Antwort: vier gängige MQTT-Ports
MQTT selbst ist ein Anwendungsprotokoll, das über einen zuverlässigen Bytestrom läuft. Wie dieser Strom transportiert wird, bestimmt den Port (wenn Sie unsicher sind, warum es immer TCP ist, lesen Sie nutzt MQTT TCP oder UDP). Die IANA hat 1883 für MQTT und 8883 für MQTT über TLS registriert. WebSocket-Ports sind eher eine Konvention als eine Registrierung und unterscheiden sich je nach Broker; ConnectMQ verwendet 8083 und 8084.
| Port | Transport | Verschlüsselt | Typische Clients | Im Produktivbetrieb? |
|---|---|---|---|---|
| 1883 | MQTT über TCP | Nein | CLI-Werkzeuge, Laborgeräte, lokale Netze | Nur in vertrauenswürdigen, isolierten Netzen |
| 8883 | MQTT über TLS über TCP | Ja | Geräte, Gateways, Backend-Services | Ja, die Standardwahl |
| 8083 | MQTT über WebSocket (ws://) |
Nein | Browser-Demos, lokale Tests | Selten |
| 8084 | MQTT über Secure WebSocket (wss://) |
Ja | Browser, mobile Web-Apps, restriktive Netze | Ja, für Web-Clients |
Bei ConnectMQ nutzen beide WebSocket-Endpunkte den Pfad /mqtt, die vollständige Browser-URL lautet also wss://broker.connectmq.com:8084/mqtt. Die TLS-Ports präsentieren ein Let's-Encrypt-Zertifikat, dem fast jedes Betriebssystem und jeder Browser standardmäßig vertraut.
Port 1883: unverschlüsseltes MQTT über TCP
Port 1883 überträgt rohe MQTT-Pakete ohne Verschlüsselung. Benutzernamen, Passwörter und Payloads gehen im Klartext über das Netz und sind für jeden lesbar, der den Datenverkehr auf dem Weg mitschneiden kann. Damit eignet sich 1883 für:
- Lernen und schnelle Experimente auf einem öffentlichen MQTT-Broker, der für Tests und Prototypen gedacht ist, nicht für Produktionsdaten.
- Einen lokalen Broker in einem isolierten Labornetz.
- Sehr eingeschränkte Geräte, die mit einem nahen Gateway in einem Segment unter Ihrer Kontrolle sprechen.
Für Zugangsdaten, die über das Internet gehen, eignet er sich nicht. Sehen Sie eine produktive Flotte auf 1883, behandeln Sie das als Befund, der behoben werden muss.
Port 8883: MQTT über TLS
Port 8883 verpackt dieselben MQTT-Pakete in eine TLS-Session. Der Client prüft das Zertifikat des Brokers gegen eine vertrauenswürdige Zertifizierungsstelle, handelt Schlüssel aus und sendet erst dann das CONNECT-Paket mit seinen Zugangsdaten. Das ist die Standardwahl für Geräte, Gateways und Backend-Services.
Was 8883 vom Client verlangt:
- Eine TLS-Bibliothek (mbedTLS auf dem ESP32, OpenSSL in den meisten Linux-Werkzeugen, den Plattform-Stack in .NET und Java).
- Ein vertrauenswürdiges CA-Bundle, damit das Broker-Zertifikat geprüft werden kann. Deaktivieren Sie die Prüfung im Produktivbetrieb niemals.
- Eine einigermaßen genaue Uhr, denn die Gültigkeit von Zertifikaten ist zeitabhängig. Geräte ohne Echtzeituhr sollten sich vor dem Verbinden per NTP synchronisieren.
- Server Name Indication (SNI), gesetzt auf den Hostnamen des Brokers. Die meisten Bibliotheken erledigen das automatisch, wenn Sie sich per Hostname verbinden.
Der Mehraufwand besteht aus einem Handshake beim Verbinden und etwas größeren Paketen. Da MQTT eine langlebige Verbindung hält, findet dieser Handshake selten statt, der laufende Overhead ist also gering. Unser Leitfaden zu Best Practices für MQTT-Sicherheit behandelt den Rest der Härtungsliste.
Ports 8083 und 8084: MQTT über WebSocket
Browser können keine rohen TCP-Sockets öffnen, daher tunneln Web-Apps MQTT in WebSocket-Frames. Der Client sendet zuerst eine HTTP-Upgrade-Anfrage an einen Pfad (hier /mqtt) und tauscht dann binäre MQTT-Pakete über die umgestellte Verbindung aus.
- 8083 (
ws://) ist unverschlüsselt. Moderne Browser blockieren es auf Seiten, die über HTTPS ausgeliefert werden (Mixed Content), daher ist es vor allem für lokale Tests nützlich. - 8084 (
wss://) ist WebSocket über TLS, die einzige realistische Option für ein produktives Web-Dashboard.
WebSocket hat einen zweiten Vorteil: Für viele Proxys und Firewalls sieht es wie normaler HTTPS-Verkehr aus. Wenn ein Fabrik- oder Hotelnetz 8883 sperrt, kommt wss:// auf 8084 manchmal durch, wo rohes TLS scheitert. Browser-Code und Hinweise zu Proxys finden Sie unter MQTT über WebSocket.
Auswirkungen auf die Firewall
MQTT-Clients bauen die Verbindung immer ausgehend zum Broker auf, und der Broker schickt Daten über dieselbe Verbindung zurück. Das vereinfacht Firewall-Regeln erheblich:
- Ausgehendes TCP erlauben aus Gerätenetzen zum Hostnamen des Brokers auf 8883 (und 8084, wenn Sie Web-Clients haben).
- Keine eingehenden Regeln auf Geräteseite nötig. Geräte lauschen auf keinem MQTT-Port.
- Langlebige Verbindungen zulassen. Manche Firewalls und NAT-Gateways verwerfen untätige TCP-Sessions stillschweigend nach einigen Minuten. Setzen Sie das MQTT-Keep-Alive-Intervall kürzer als diesen Timeout (60 Sekunden sind üblich), damit PINGREQ-Pakete die Zuordnung aufrechterhalten.
- Keine TLS-Inspektion für MQTT. Middleboxen, die Zertifikate neu signieren, brechen die Zertifikatsprüfung auf Geräten. Nehmen Sie den Hostnamen des Brokers von der Inspektion aus.
- Hostnamen statt IP-Allowlists bevorzugen, wo Ihre Firewall das unterstützt, denn Cloud-Endpunkte können ihre Adressen ändern.
In Industrienetzen kommt die Segmentierung nach IEC 62443 hinzu: SPS und Feldgeräte in der Zelle sprechen selten selbst mit der Cloud, sondern über ein Edge-Gateway in einer eigenen Zone, und nur dieses Gateway erhält über einen definierten Übergang (Conduit) ausgehend Zugriff auf 8883. Wie das mit einer MQTT-DMZ aussieht, beschreibt der verlinkte Artikel.
Wenn Sie nur einen Port freigeschaltet bekommen, bitten Sie um 8883. Ist selbst das unmöglich, bitten Sie um 8084 und betreiben Ihre Clients über Secure WebSocket.
Jeden MQTT-Port in fünf Minuten testen
Die folgenden Befehle nutzen den anonymen Zugang des öffentlichen MQTT-Brokers unter broker.connectmq.com, der nur für Tests gedacht ist. Verwenden Sie eine eindeutige Client ID und ein eindeutiges Topic-Präfix und denken Sie daran, dass öffentliche Topics für alle sichtbar sind.
TCP-Erreichbarkeit prüfen
# Linux / macOS
nc -vz broker.connectmq.com 1883
nc -vz broker.connectmq.com 8883
nc -vz broker.connectmq.com 8084
Unter Windows PowerShell verwenden Sie Test-NetConnection broker.connectmq.com -Port 8883 und achten auf TcpTestSucceeded : True.
Das TLS-Zertifikat auf 8883 prüfen
openssl s_client -connect broker.connectmq.com:8883 \
-servername broker.connectmq.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
Sie sollten einen Let's-Encrypt-Aussteller und gültige Daten sehen. Steht stattdessen der Proxy Ihres Unternehmens als Aussteller da, ist eine TLS-Inspektion im Weg.
Auf 1883 und 8883 publizieren und abonnieren
# Terminal A: per TLS abonnieren (mosquitto aktiviert TLS, wenn ein CA-Pfad angegeben ist)
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i ports-sub-91c2 -t "connectmq/demo/91c2/#" -v
# Terminal B: über unverschlüsseltes TCP publizieren
mosquitto_pub -h broker.connectmq.com -p 1883 -i ports-pub-91c2 \
-t "connectmq/demo/91c2/hello" -m "sent on 1883, received on 8883"
Die Nachricht wechselt von einem Port zum anderen, was zeigt, dass Ports nur Eingänge zum selben Broker sind.
Secure WebSocket auf 8084 mit Node.js testen
// 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));
Für rohes TLS aus Node ersetzen Sie die URL durch mqtts://broker.connectmq.com:8883.
Port-Probleme beheben
| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| Timeout auf 8883, 1883 funktioniert | Firewall erlaubt nur gängige Ports | Ausgehendes 8883 beantragen oder 8084 nutzen |
| TLS-Handshake schlägt fehl, Zertifikat unbekannt | Fehlendes CA-Bundle oder TLS-Inspektion | CA-Zertifikate installieren, Inspektion für den Broker-Host umgehen |
| Zertifikat noch nicht gültig | Geräteuhr falsch | Vor dem Verbinden per NTP synchronisieren |
| WebSocket liefert 404 | Falscher Pfad | /mqtt verwenden |
Browser lehnt ws:// ab |
Mixed Content auf einer HTTPS-Seite | wss:// auf 8084 verwenden |
| Trennungen alle paar Minuten | NAT-Leerlauf-Timeout | Keep Alive unter den Timeout senken |
Von Test-Ports zum Produktivbetrieb
Beim öffentlichen Broker verbinden Sie sich anonym, bei einem privaten Broker ergänzen Sie Zugangsdaten. Wenn Sie im ConnectMQ-Portal einen Broker anlegen, erhalten Sie Benutzernamen, Passwort und eine an diese Zugangsdaten gebundene Client ID, und es gelten dieselben vier Ports. Ein typisches Produktiv-Setup nutzt 8883 für Geräte und Gateways und 8084 für das Web-Dashboard, während 1883 und 8083 dem lokalen Debugging vorbehalten bleiben. Da ConnectMQ ein verwalteter MQTT-Broker ist, werden Zertifikate für Sie erneuert, und es gibt keine Listener-Konfiguration zu pflegen. Der Leitfaden zum Cloud-MQTT-Broker vergleicht Hosting-Optionen ausführlicher, und das MQTT-Tutorial für Einsteiger führt Sie durchgängig durch Ihre erste Verbindung.
Starten Sie mit ConnectMQ
Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless Broker, ohne Kreditkarte, und verbinden Sie sich auf 8883 oder 8084 mit den Zugangsdaten, die das Portal generiert. Mit dem Browser-Client von ConnectMQ prüfen Sie die Verbindung, bevor Sie irgendeine Firmware anfassen.
Häufig gestellte Fragen
Was ist der Standardport von MQTT?
Der Standardport von MQTT ist 1883 für unverschlüsseltes TCP und 8883 für MQTT über TLS. Beide sind bei der IANA registriert.
Welchen MQTT-Port sollte ich im Produktivbetrieb verwenden?
Verwenden Sie 8883 für Geräte und Services und 8084 (Secure WebSocket) für Browser. Vermeiden Sie 1883 über das Internet, weil Zugangsdaten dort im Klartext übertragen werden.
Kann ich MQTT auf Port 443 betreiben?
Manche Broker bieten MQTT über WebSocket oder TLS auf 443 an, um strenge Firewalls zu passieren. broker.connectmq.com nutzt 8883 und 8084, bitten Sie Ihr Netzwerkteam also, ausgehenden Verkehr zu diesen Ports zu erlauben.
Warum schlägt meine WebSocket-Verbindung fehl, obwohl TCP funktioniert?
Die häufigsten Ursachen sind ein fehlender Pfad /mqtt, die Verwendung von ws:// auf einer HTTPS-Seite oder ein Proxy, der keine WebSocket-Upgrades unterstützt.
