Cómo probar un broker MQTT (online, CLI y código)

Probar un broker MQTT se reduce a una pregunta: ¿puede un cliente conectarse, publicar un mensaje y recibirlo de vuelta? Todo lo demás — QoS, mensajes retenidos (retained), autenticación, latencia — se construye sobre ese ciclo. Esta guía recorre el ciclo de tres maneras: en el navegador, desde la línea de comandos y en código.

Qué comprobar al probar un broker

1. Alcanzabilidad — el host se resuelve y el puerto está abierto (TCP 1883, TLS 8883 o un puerto WebSocket). Consulta los puertos MQTT explicados.
2. Handshake — el broker responde al CONNECT con un CONNACK correcto. Las credenciales o los client ID incorrectos fallan aquí.
3. Ida y vuelta — un mensaje publicado en un topic se entrega a un suscriptor del mismo topic.
4. Las funciones de las que dependes — confirmaciones de QoS 1/2, mensajes retenidos, Last Will, propiedades de MQTT 5.
5. Latencia y estabilidad — cuánto tarda la ida y vuelta y si la conexión sobrevive a los intervalos de keep-alive.

1. Probar un broker MQTT online

La forma más rápida es un cliente en el navegador. Los navegadores solo hablan MQTT sobre WebSockets, así que necesitas el endpoint wss:// del broker — todos los brokers de nuestra lista de brokers públicos lo muestran.

1. Abre el cliente MQTT online y elige un broker.
2. Haz clic en Connect. Un estado verde significa que llegó el CONNACK.
3. Suscríbete a un topic único como testmqtt/demo-42/#.
4. Publica {"hello":"world"} en testmqtt/demo-42/hello y observa cómo aparece en la lista de mensajes.

Pruébalo en el cliente MQTT online

2. Probar desde la línea de comandos

Los clientes de Mosquitto son las herramientas CLI estándar. Abre dos terminales — una para suscribirte y otra para publicar:

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'

Añade -u y -P para usuario y contraseña, -q 1 para probar QoS 1, y --cafile con el puerto 8883 para probar TLS.

3. Probar en código

Un script pequeño es la prueba más repetible — puedes ejecutarlo en CI o como health check. Aquí tienes una prueba de ida y vuelta con MQTT.js que además mide la latencia:

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);
});

Probar QoS, mensajes retenidos y Last Will

• QoS — publica con QoS 1 y 2 y confirma que se ejecuta el callback de publicación. Consulta los niveles de QoS de MQTT.
• Mensajes retenidos — publica con retain, desconéctate, vuelve a conectarte y suscríbete: el último valor debería llegar de inmediato. Consulta los mensajes retenidos.
• Last Will — conecta un cliente con un mensaje de última voluntad, mátalo sin una desconexión limpia y comprueba que los suscriptores reciben el will. Consulta Last Will and Testament.

Si la prueba falla

Los timeouts suelen indicar un puerto bloqueado o el transporte equivocado (un puerto TCP desde el navegador). Los rechazos inmediatos apuntan a credenciales, conflictos de client ID o ACL. Nuestra guía de errores de conexión MQTT relaciona cada código de motivo del CONNACK con su solución.

Preguntas frecuentes