Teste um broker MQTT pelo navegador (sem instalar nada)

Você consegue testar um broker MQTT pelo navegador em cerca de dois minutos — sem instalar o Mosquitto, sem Python, sem permissão de administrador. Abra o cliente MQTT online, conecte via WebSocket seguro (wss), assine um topic, publique uma mensagem e veja-a voltar. Se essa ida e volta funcionar, o broker está no ar, acessível a partir da sua rede e roteando mensagens.

Este guia percorre o teste completo passo a passo, mostra como apontá-lo para o seu próprio broker e como compartilhar um teste pronto com um colega ou com quem desenvolve o firmware.

Como o MQTT funciona no navegador

Navegadores não conseguem abrir sockets TCP puros, então uma página web não fala MQTT diretamente na porta 1883. Em vez disso, ela usa MQTT sobre WebSockets: os mesmos pacotes MQTT, encapsulados em uma conexão WebSocket que começa como uma requisição HTTP de upgrade.

Duas consequências importam para o teste: o broker precisa ter um listener WebSocket ativo (com o caminho correto — geralmente /mqtt) e, a partir de uma página https, você precisa usar wss. O cliente do TestMQTT também oferece TCP e TLS; como navegadores não abrem esses sockets, ele os retransmite pelo servidor do TestMQTT. Isso é útil para verificar um broker só com TCP, mas lembre que a conexão passa a sair da rede do relay, não da sua. Para o contexto, veja MQTT sobre WebSockets.

Passo 1 — Conectar

1. Abra testmqtt.com/client. O protocolo padrão é WSS e um broker recomendado já vem selecionado.
2. Clique em Connect. O status muda para conectado e o log registra a conexão bem-sucedida (o CONNACK do broker).
3. Um client ID único (testmqtt_xxxxxxxx) é gerado para cada aba, então duas abas nunca derrubam uma à outra do broker.

Para testar o seu próprio broker, escolha Custom broker… na lista de brokers e preencha as configurações:

Se o broker usa um certificado autoassinado, quem decide se confia nele é o navegador, não a página. Abra https://host:8084/ uma vez em uma aba e aceite o certificado — ou, melhor, use um certificado de uma CA pública.

Passo 2 — Assinar e publicar

Use um topic que ninguém mais esteja usando. Em um broker compartilhado, test é movimentado; algo como testmqtt/<seu-nome>-<aleatorio>/# mantém as suas mensagens separadas.

1. Em Subscriptions, adicione testmqtt/demo-7f3a/# com QoS 1.
2. Em Publish, defina o topic testmqtt/demo-7f3a/sensor, escolha o modelo Sensor JSON ou digite o seu payload e clique em Publish.
3. A mensagem aparece na lista, marcada como recebida. Dê um clique duplo para ver todos os detalhes: topic, QoS, flag retained, tamanho e o payload completo.

Se você publica e nada aparece, confira se o filtro da assinatura realmente corresponde ao topic — testmqtt/demo-7f3a/+ corresponde a um nível, # a todos os níveis abaixo. O topic matcher resolve isso em segundos, e topics e wildcards explica as regras.

Para um fluxo contínuo, defina um intervalo de repetição no painel de publicação. Assim fica fácil observar a conexão por alguns minutos e perceber quedas ou lacunas.

Passo 3 — Testar mensagens retained e Last Will

Um teste de broker de verdade vai além de uma mensagem:

• Retained: publique em testmqtt/demo-7f3a/status com retain ativado. Desconecte, reconecte e assine de novo — o broker deve entregar o último valor retido imediatamente. Para apagá-lo, publique um payload retido vazio — ou use Clear retained message nos detalhes da mensagem.
• Last Will: em Settings, defina um will topic como testmqtt/demo-7f3a/lwt com o payload offline. Abra uma segunda aba assinando esse topic e feche a primeira sem desconectar. Depois de aproximadamente 1,5× o intervalo de keep alive, o broker deve publicar o will. Um Disconnect limpo não o dispara — esse é o comportamento correto.
• MQTT 5: mude a versão do protocolo para 5 e reconecte. Se o broker só suporta 3.1.1, você receberá um erro no CONNACK como Unsupported Protocol Version; a ferramenta de reason codes explica cada código.

Passo 4 — Conferir com outro cliente

Um teste no navegador prova que o listener WebSocket funciona. Dispositivos normalmente usam TCP ou TLS, então feche o ciclo: mantenha o navegador inscrito e publique a partir de um terminal.

mosquitto_pub -h broker.connectmq.com -p 1883 \
  -t testmqtt/demo-7f3a/sensor -m '{"temp":21.5}' -q 1 -d

mosquitto_pub -h broker.connectmq.com -p 8883 \
  --cafile /etc/ssl/certs/ca-certificates.crt \
  -u "$MQTT_USER" -P "$MQTT_PASS" \
  -t testmqtt/demo-7f3a/sensor -m '{"temp":21.5}' -q 1

Se a mensagem aparece no navegador, os dois listeners compartilham o mesmo broker e o roteamento funciona entre transportes. Se o TCP funciona e o navegador não — ou o contrário —, o problema está no listener ou no caminho de rede de um transporte, não no broker como um todo.

Compartilhe um teste pronto

Quando você depura com outra pessoa — um desenvolvedor de firmware, um cliente, um colega —, envie um link que abre o cliente já conectado ao endpoint certo e inscrito no topic certo:

https://testmqtt.com/client?url=wss://broker.connectmq.com:8084/mqtt&topic=testmqtt/demo-7f3a/%23

url define protocolo, host, porta e caminho e conecta automaticamente; topic define a assinatura (codifique # como %23). Vocês dois veem as mesmas mensagens ao vivo, o que é muito mais rápido do que trocar prints de logs. As credenciais nunca fazem parte do link — cada pessoa digita as suas.

Quando o teste no navegador falha

As ferramentas de desenvolvedor do navegador mostram os frames WebSocket brutos em Network → WS, muitas vezes o jeito mais rápido de ver se o CONNECT saiu e o que voltou. Depurar MQTT com o Chrome DevTools mostra o passo a passo.

Abrir o cliente de teste no navegador

Testar pelo navegador é a primeira verificação mais rápida que existe: não exige instalação, funciona em qualquer máquina e um link compartilhado coloca todo mundo olhando o mesmo topic ao vivo. Quando a ida e volta no navegador funcionar, confira via TCP ou TLS e você saberá que broker, listeners e caminho de rede estão em ordem.

Perguntas frequentes