MQTT-Broker testen (online, per CLI und im Code)

Einen MQTT-Broker zu testen läuft auf eine einzige Frage hinaus: Kann sich ein Client verbinden, eine Nachricht publishen und sie wieder empfangen? Alles andere – QoS, Retained Messages, Authentifizierung, Latenz – baut auf diesem Kreislauf auf. Diese Anleitung zeigt dir den Kreislauf auf drei Wegen: im Browser, auf der Kommandozeile und im Code.

Was du beim Testen eines Brokers prüfen solltest

1. Erreichbarkeit – der Hostname wird aufgelöst und der Port ist offen (TCP 1883, TLS 8883 oder ein WebSocket-Port). Siehe MQTT-Ports erklärt.
2. Handshake – der Broker beantwortet CONNECT mit einem erfolgreichen CONNACK. Falsche Zugangsdaten oder Client-IDs scheitern genau hier.
3. Round Trip – eine auf ein Topic gepublishte Nachricht wird an einen Subscriber desselben Topics zugestellt.
4. Features, auf die du angewiesen bist – QoS-1/2-Bestätigungen, Retained Messages, Last Will, MQTT-5-Properties.
5. Latenz und Stabilität – wie lange der Round Trip dauert und ob die Verbindung die Keep-Alive-Intervalle übersteht.

1. MQTT-Broker online testen

Am schnellsten geht es mit einem browserbasierten Client. Browser sprechen MQTT nur über WebSockets, du brauchst also den wss://-Endpunkt des Brokers – jeder Broker in unserer Liste öffentlicher Broker zeigt ihn an.

1. Öffne den Online-MQTT-Client und wähle einen Broker.
2. Klicke auf Connect. Ein grüner Status bedeutet, dass das CONNACK zurückgekommen ist.
3. Abonniere ein eindeutiges Topic wie testmqtt/demo-42/#.
4. Publishe {"hello":"world"} an testmqtt/demo-42/hello und beobachte, wie die Nachricht in der Liste erscheint.

Im Online-MQTT-Client ausprobieren

2. Auf der Kommandozeile testen

Die Mosquitto-Clients sind die Standard-CLI-Tools. Öffne zwei Terminals – einen Subscriber, einen Publisher:

mosquitto_sub -h broker.hivemq.com -p 1883 -t 'testmqtt/demo-42/#' -v

mosquitto_pub -h broker.hivemq.com -p 1883 -t 'testmqtt/demo-42/hello' -m 'hello from the CLI'

Ergänze -u und -P für Benutzername und Passwort, -q 1, um QoS 1 zu testen, und --cafile mit Port 8883, um TLS zu testen.

3. Im Code testen

Ein kleines Skript ist der am besten wiederholbare Test – du kannst es in der CI oder als Health Check laufen lassen. Hier ist ein Round-Trip-Test mit MQTT.js, der zusätzlich die Latenz misst:

import mqtt from 'mqtt';

const topic = `testmqtt/${Math.random().toString(16).slice(2, 8)}/ping`;
const client = mqtt.connect('wss://broker.hivemq.com:8884/mqtt');

client.on('connect', () => {
  client.subscribe(topic, { qos: 1 }, () => {
    const sentAt = Date.now();
    client.publish(topic, String(sentAt), { qos: 1 });
  });
});

client.on('message', (_topic, payload) => {
  console.log(`round trip: ${Date.now() - Number(payload)} ms`);
  client.end();
});

client.on('error', (err) => {
  console.error('connection failed:', err.message);
  process.exit(1);
});

QoS, Retained Messages und Last Will testen

• QoS – publishe mit QoS 1 und 2 und prüfe, ob der Publish-Callback ausgelöst wird. Siehe MQTT-QoS-Stufen.
• Retained Messages – publishe mit retain, trenne die Verbindung, verbinde dich neu und subscribe: Der letzte Wert sollte sofort ankommen. Siehe Retained Messages.
• Last Will – verbinde einen Client mit einer Will-Nachricht, beende ihn ohne sauberes Disconnect und prüfe, ob die Subscriber den Will erhalten. Siehe Last Will and Testament.

Wenn der Test fehlschlägt

Timeouts deuten meist auf einen blockierten Port oder den falschen Transport hin (TCP-Port aus dem Browser). Sofortige Ablehnungen sprechen für falsche Zugangsdaten, Client-ID-Konflikte oder ACLs. Unser Leitfaden zu MQTT-Verbindungsfehlern ordnet jedem CONNACK-Reason-Code eine Lösung zu.

Häufig gestellte Fragen