Como testar um broker MQTT (online, CLI e código)

Testar um broker MQTT se resume a uma pergunta: um cliente consegue se conectar, publicar uma mensagem e recebê-la de volta? Todo o resto — QoS, mensagens retidas, autenticação, latência — se apoia nesse ciclo. Este guia mostra o ciclo de três formas: no navegador, pela linha de comando e em código.

O que verificar ao testar um broker

1. Alcançabilidade — o host resolve e a porta está aberta (TCP 1883, TLS 8883 ou uma porta WebSocket). Veja portas MQTT explicadas.
2. Handshake — o broker responde ao CONNECT com um CONNACK de sucesso. Credenciais ou client IDs errados falham aqui.
3. Ida e volta — uma mensagem publicada em um tópico é entregue a um assinante do mesmo tópico.
4. Recursos dos quais você depende — confirmações de QoS 1/2, mensagens retidas, Last Will, propriedades do MQTT 5.
5. Latência e estabilidade — quanto tempo leva a ida e volta e se a conexão sobrevive aos intervalos de keep-alive.

1. Teste um broker MQTT online

O jeito mais rápido é um cliente no navegador. Navegadores só falam MQTT sobre WebSockets, então você precisa do endpoint wss:// do broker — todos os brokers da nossa lista de brokers públicos o exibem.

1. Abra o cliente MQTT online e escolha um broker.
2. Clique em Connect. Um status verde significa que o CONNACK voltou.
3. Assine um tópico exclusivo, como testmqtt/demo-42/#.
4. Publique {"hello":"world"} em testmqtt/demo-42/hello e veja a mensagem aparecer na lista.

Teste no cliente MQTT online

2. Teste pela linha de comando

Os clientes do Mosquitto são as ferramentas de CLI padrão. Abra dois terminais — um assinante e um publicador:

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'

Adicione -u e -P para usuário e senha, -q 1 para testar QoS 1 e --cafile com a porta 8883 para testar TLS.

3. Teste em código

Um script pequeno é o teste mais reproduzível — você pode rodá-lo no CI ou como health check. Aqui está um teste de ida e volta com MQTT.js que também mede a latência:

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

Testando QoS, mensagens retidas e Last Will

• QoS — publique com QoS 1 e 2 e confirme que o callback de publicação é disparado. Veja níveis de QoS do MQTT.
• Mensagens retidas — publique com retain, desconecte, reconecte e assine: o último valor deve chegar imediatamente. Veja mensagens retidas (retained).
• Last Will — conecte um cliente com uma mensagem de will, derrube-o sem um disconnect limpo e verifique se os assinantes recebem o will. Veja Last Will and Testament.

Se o teste falhar

Timeouts geralmente indicam uma porta bloqueada ou o transporte errado (porta TCP a partir de um navegador). Recusas imediatas apontam para credenciais, conflitos de client ID ou ACLs. Nosso guia de erros de conexão MQTT associa cada reason code do CONNACK a uma solução.

Perguntas frequentes