As portas MQTT determinam como seus dispositivos chegam a um broker, se o tráfego é criptografado e se um firewall corporativo vai deixá-lo passar. Este guia explica as quatro portas que você encontrará na prática (1883, 8883, 8083 e 8084), quando usar cada uma e como testar todas em poucos minutos contra um broker ao vivo.
A resposta curta: quatro portas MQTT comuns
O MQTT em si é um protocolo de aplicação que roda sobre um fluxo de bytes confiável. A forma como esse fluxo é transportado determina a porta (se não sabe ao certo por que é sempre TCP, leia o MQTT usa TCP ou UDP). A IANA registrou a 1883 para MQTT e a 8883 para MQTT sobre TLS. As portas WebSocket são uma convenção, não um registro, e variam entre brokers; o ConnectMQ usa 8083 e 8084.
| Porta | Transporte | Criptografada | Clientes típicos | Usar em produção? |
|---|---|---|---|---|
| 1883 | MQTT sobre TCP | Não | Ferramentas de linha de comando, dispositivos de laboratório, redes locais | Somente em redes confiáveis e isoladas |
| 8883 | MQTT sobre TLS sobre TCP | Sim | Dispositivos, gateways, serviços de backend | Sim, a escolha padrão |
| 8083 | MQTT sobre WebSocket (ws://) |
Não | Demos no navegador, testes locais | Raramente |
| 8084 | MQTT sobre WebSocket seguro (wss://) |
Sim | Navegadores, apps web móveis, redes restritivas | Sim, para clientes web |
No ConnectMQ, os dois endpoints WebSocket usam o caminho /mqtt, então a URL completa no navegador é wss://broker.connectmq.com:8084/mqtt. As portas TLS apresentam um certificado Let's Encrypt, confiável por padrão em praticamente todos os sistemas operacionais e navegadores.
Porta 1883: MQTT sem criptografia sobre TCP
A porta 1883 transporta pacotes MQTT brutos, sem criptografia. Usuários, senhas e payloads atravessam a rede em texto puro, legíveis por qualquer pessoa capaz de capturar o tráfego no caminho. Por isso, a 1883 serve bem para:
- Aprendizado e experimentos rápidos no servidor MQTT público, nunca com dados de produção.
- Um broker local dentro de uma rede de laboratório isolada.
- Dispositivos muito limitados conversando com um gateway próximo em um segmento que você controla.
Ela não serve para credenciais trafegando pela internet. Se você encontrar uma frota de produção na 1883, trate isso como um problema a corrigir.
Porta 8883: MQTT sobre TLS
A porta 8883 envolve os mesmos pacotes MQTT em uma sessão TLS. O cliente verifica o certificado do broker contra uma autoridade certificadora confiável, negocia as chaves e só então envia o pacote CONNECT com suas credenciais. Essa é a escolha padrão para dispositivos, gateways e serviços de backend.
O que a 8883 exige do cliente:
- Uma biblioteca TLS (mbedTLS no ESP32, OpenSSL na maioria das ferramentas Linux, a pilha da plataforma em .NET e Java).
- Um pacote de CAs confiáveis para que o certificado do broker possa ser verificado. Nunca desative a verificação em produção.
- Um relógio razoavelmente preciso, porque a validade do certificado depende da data e hora. Dispositivos sem relógio de tempo real devem sincronizar via NTP antes de conectar.
- Server Name Indication (SNI) definido com o hostname do broker. A maioria das bibliotecas faz isso automaticamente quando você conecta pelo hostname.
O custo extra é um handshake na conexão e pacotes um pouco maiores. Como o MQTT mantém uma única conexão de longa duração, esse handshake acontece raramente, então o overhead em regime contínuo é pequeno. Nosso guia de boas práticas de segurança em MQTT cobre o restante da lista de proteção.
Portas 8083 e 8084: MQTT sobre WebSocket
Navegadores não conseguem abrir sockets TCP brutos, então as aplicações web encapsulam o MQTT em frames WebSocket. O cliente primeiro envia uma requisição HTTP de upgrade para um caminho (aqui /mqtt) e depois troca pacotes MQTT binários pela conexão atualizada.
- 8083 (
ws://) não é criptografada. Navegadores modernos a bloqueiam em páginas servidas via HTTPS (conteúdo misto), então ela é útil principalmente para testes locais. - 8084 (
wss://) é WebSocket sobre TLS, a única opção realista para um painel web em produção.
O WebSocket tem um segundo benefício: para muitos proxies e firewalls, ele parece tráfego HTTPS comum. Quando a rede de uma fábrica ou de um hotel bloqueia a 8883, o wss:// na 8084 às vezes passa onde o TLS bruto não passa. Veja MQTT sobre WebSocket para código de navegador e ressalvas sobre proxies.
Implicações para o firewall
Os clientes MQTT sempre iniciam a conexão de saída em direção ao broker, e o broker envia os dados de volta por essa mesma conexão. Isso simplifica muito as regras de firewall:
- Libere TCP de saída das redes dos dispositivos para o hostname do broker na 8883 (e na 8084, se houver clientes web).
- Nenhuma regra de entrada é necessária do lado dos dispositivos. Eles não escutam em nenhuma porta MQTT.
- Permita conexões de longa duração. Alguns firewalls e gateways NAT descartam silenciosamente sessões TCP ociosas depois de alguns minutos. Defina o intervalo de keep alive do MQTT menor que esse timeout (60 segundos é uma escolha comum) para que os pacotes PINGREQ mantenham o mapeamento ativo.
- Evite interceptação TLS no MQTT. Equipamentos intermediários que reassinam certificados quebram a verificação de certificados nos dispositivos. Exclua o hostname do broker da inspeção.
- Prefira hostnames a listas de IPs permitidos quando o firewall suportar, porque endpoints na nuvem podem mudar de endereço.
Se só conseguir liberar uma porta, peça a 8883. Se nem isso for possível, peça a 8084 e rode seus clientes sobre WebSocket seguro.
Teste todas as portas MQTT em cinco minutos
Os comandos abaixo usam o endpoint público anônimo em broker.connectmq.com. Use um client ID e um prefixo de tópico únicos, e lembre-se de que os tópicos públicos são visíveis para todos.
Verifique a acessibilidade TCP
# Linux / macOS
nc -vz broker.connectmq.com 1883
nc -vz broker.connectmq.com 8883
nc -vz broker.connectmq.com 8084
No Windows PowerShell, use Test-NetConnection broker.connectmq.com -Port 8883 e procure por TcpTestSucceeded : True.
Inspecione o certificado TLS na 8883
openssl s_client -connect broker.connectmq.com:8883 \
-servername broker.connectmq.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
Você deve ver um emissor Let's Encrypt e datas válidas. Se, em vez disso, o emissor for o proxy da sua empresa, há interceptação TLS no caminho.
Publique e assine na 1883 e na 8883
# Terminal A: assina via TLS (o mosquitto ativa TLS quando um caminho de CA é informado)
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i ports-sub-91c2 -t "connectmq/demo/91c2/#" -v
# Terminal B: publica via TCP sem criptografia
mosquitto_pub -h broker.connectmq.com -p 1883 -i ports-pub-91c2 \
-t "connectmq/demo/91c2/hello" -m "sent on 1883, received on 8883"
A mensagem passa de uma porta para a outra, o que mostra que as portas são apenas pontos de entrada para o mesmo broker.
Teste o WebSocket seguro na 8084 com Node.js
// 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));
Para TLS bruto a partir do Node, troque a URL por mqtts://broker.connectmq.com:8883.
Solução de problemas de portas
| Sintoma | Causa provável | Solução |
|---|---|---|
| Timeout de conexão na 8883, a 1883 funciona | Firewall libera apenas portas comuns | Solicite a liberação de saída da 8883 ou use a 8084 |
| Handshake TLS falha, certificado desconhecido | Pacote de CAs ausente ou inspeção TLS | Instale os certificados de CA e exclua o host do broker da inspeção |
| Certificado ainda não é válido | Relógio do dispositivo errado | Sincronize via NTP antes de conectar |
| WebSocket retorna 404 | Caminho errado | Use /mqtt |
Navegador recusa ws:// |
Conteúdo misto em uma página HTTPS | Use wss:// na 8084 |
| Desconexões a cada poucos minutos | Timeout de inatividade do NAT | Reduza o keep alive para abaixo do timeout |
Das portas de teste para a produção
No servidor MQTT público você se conecta anonimamente; em um broker privado, adiciona credenciais. Ao criar um broker no portal do ConnectMQ, você recebe um usuário, uma senha e um client ID vinculado a essas credenciais, e as mesmas quatro portas se aplicam. Uma configuração de produção típica usa a 8883 para dispositivos e gateways e a 8084 para o painel web, deixando 1883 e 8083 para depuração local. Como o ConnectMQ é um broker MQTT gerenciado, os certificados são renovados para você e não há configuração de listeners para manter. O guia de broker MQTT na nuvem compara as opções de hospedagem com mais profundidade, e o tutorial de MQTT para iniciantes mostra sua primeira conexão de ponta a ponta.
Comece a usar o ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e conecte-se na 8883 ou na 8084 com as credenciais geradas pelo portal. O cliente no navegador do ConnectMQ permite confirmar a conexão antes de mexer em qualquer firmware.
Perguntas frequentes
Qual é a porta padrão do MQTT?
A porta padrão do MQTT é a 1883 para TCP sem criptografia e a 8883 para MQTT sobre TLS. Ambas são registradas na IANA.
Qual porta MQTT devo usar em produção?
Use a 8883 para dispositivos e serviços e a 8084 (WebSocket seguro) para navegadores. Evite a 1883 pela internet, porque as credenciais trafegam em texto puro.
Posso rodar MQTT na porta 443?
Alguns brokers oferecem MQTT sobre WebSocket ou TLS na 443 para passar por firewalls rígidos. O broker.connectmq.com usa 8883 e 8084, então peça à sua equipe de rede para liberar o tráfego de saída para essas portas.
Por que minha conexão WebSocket falha quando o TCP funciona?
As causas mais comuns são a falta do caminho /mqtt, o uso de ws:// em uma página HTTPS ou um proxy que não suporta upgrades de WebSocket.
