Puertos MQTT explicados: 1883, 8883, 8083, 8084 y 443

Cuando una conexión MQTT falla, el puerto es lo primero que hay que revisar. MQTT puede funcionar sobre TCP sin cifrar, sobre TLS, sobre WebSockets y sobre WebSockets seguros — y cada transporte suele vivir en un puerto distinto. Elegir el equivocado es la causa más habitual de que un cliente se quede colgado en Connecting…. Esta guía explica cada puerto MQTT común, cuándo usarlo y los puertos exactos de los brokers públicos contra los que puedes hacer pruebas.

Los puertos MQTT de un vistazo

Solo 1883 y 8883 están registrados en la IANA (como mqtt y secure-mqtt). Los puertos WebSocket son una convención que cambia de un broker a otro, por eso siempre debes consultar la documentación del broker — o nuestra lista de brokers públicos — antes de conectarte.

Puerto MQTT 1883: TCP sin cifrar

El puerto MQTT 1883 es el transporte original, sin cifrar. El cliente abre una conexión TCP y envía directamente el paquete binario CONNECT. Tiene la menor sobrecarga y es lo que usan por defecto la mayoría de dispositivos embebidos, herramientas de línea de comandos como mosquitto_pub y librerías de servidor.

El problema: todo — incluidos el usuario y la contraseña dentro del CONNECT — viaja en texto plano. Usa el 1883 en una red local de confianza o para pruebas desechables, nunca para credenciales ni datos de producción que crucen internet.

Puerto MQTT 8883: MQTT sobre TLS

El puerto MQTT 8883 es el mismo protocolo MQTT envuelto en TLS. El cliente realiza primero un handshake TLS, verifica el certificado del broker y solo entonces envía el CONNECT. Es la opción por defecto para dispositivos y servicios backend que hablan con un broker a través de internet.

• El cliente necesita un bundle de CA de confianza (el almacén del sistema sirve para CA públicas; las configuraciones autofirmadas necesitan un cafile).
• El nombre de host al que te conectas debe coincidir con el certificado, así que conéctate por nombre, no por dirección IP.
• Los brokers pueden exigir además certificados de cliente (TLS mutuo) en este puerto o en uno separado.

Puertos WebSocket de MQTT: 8083, 8084 y compañía

Los navegadores no pueden abrir sockets TCP directos, así que las aplicaciones web tunelizan MQTT a través de un WebSocket. El cliente hace una petición HTTP de upgrade a una ruta (normalmente /mqtt) con el subprotocolo mqtt, y a partir de ahí los paquetes MQTT viajan dentro de frames WebSocket. No existe un único puerto WebSocket de MQTT estándar:

• EMQX usa por defecto 8083 (ws) y 8084 (wss).
• El broker público de HiveMQ usa 8000 (ws) y 8884 (wss).
• test.mosquitto.org usa 8080 (ws) y 8081 (wss).
• Muchos despliegues en producción ponen los WebSockets detrás de un proxy inverso en 80 / 443.

Puerto 443: atravesar firewalls

Las redes corporativas, el Wi-Fi de los hoteles y los operadores móviles suelen bloquear todo excepto los puertos web. Ejecutar MQTT sobre WebSockets seguros en el 443 hace que el tráfico parezca HTTPS normal, así que pasa casi por cualquier sitio. El sandbox de Eclipse en mqtt.eclipseprojects.io hace exactamente eso. Algunas plataformas IoT en la nube también aceptan MQTT nativo sobre TLS en el 443 y usan la extensión TLS ALPN para distinguirlo del HTTPS en el mismo puerto.

Puertos de los brokers MQTT públicos más populares

test.mosquitto.org también ofrece listeners adicionales para pruebas concretas, como un listener con autenticación en el 1884 (usuario rw, contraseña readwrite).

Conéctate a EMQX por el puerto wss 8084

Cómo poner el puerto en una URL de conexión

La mayoría de librerías cliente aceptan una única URL que combina esquema, host, puerto y (para WebSockets) ruta:

import mqtt from 'mqtt';

// Node.js only — raw TCP and TLS
mqtt.connect('mqtt://broker.emqx.io:1883');
mqtt.connect('mqtts://broker.emqx.io:8883');

// Browser or Node.js — WebSockets (note the /mqtt path)
mqtt.connect('ws://broker.emqx.io:8083/mqtt');
mqtt.connect('wss://broker.emqx.io:8084/mqtt');

Errores habituales con los puertos

• Usar mqtt:// en un puerto WebSocket (o ws:// en el 1883). El esquema decide qué protocolo habla el cliente; el puerto tiene que coincidir.
• Olvidar la ruta del WebSocket. Muchos brokers solo aceptan el upgrade en /mqtt; sin ella obtienes un 404 o un fallo silencioso.
• Usar TLS en un puerto sin cifrar. mqtts:// en el 1883 falla con un error de handshake TLS como wrong version number.
• Probar solo desde tu propia red. Un puerto que funciona en la oficina puede estar bloqueado en redes móviles o en el Wi-Fi de invitados. Prueba desde la red que usarán realmente tus dispositivos.
• Exponer el 1883 a internet con acceso anónimo. Los escáneres que recorren internet encuentran rápido los brokers MQTT abiertos. Si un broker debe ser accesible, exige credenciales y prefiere TLS.

Cómo comprobar si un puerto MQTT está abierto

Antes de culpar a tu código, confirma que el puerto es accesible desde tu red:

# Is the TCP port open?
nc -vz broker.hivemq.com 1883

# Does the TLS port complete a handshake with a valid certificate?
openssl s_client -connect broker.hivemq.com:8883 -servername broker.hivemq.com </dev/null

# Full MQTT round trip over TLS
mosquitto_sub -h broker.hivemq.com -p 8883 --capath /etc/ssl/certs -t 'testmqtt/port-check' -v

Un timeout suele significar que un firewall descarta el tráfico; connection refused significa que no hay nada escuchando en ese puerto. Nuestra guía de errores de conexión MQTT cubre ambos casos.

Abrir puertos en tu propio broker

Si ejecutas Mosquitto tú mismo, cada puerto es un listener independiente. Una configuración típica mantiene el 1883 ligado a localhost y expone públicamente solo listeners cifrados:

# Plain MQTT, local clients only
listener 1883 127.0.0.1

# MQTT over TLS
listener 8883
certfile /etc/mosquitto/certs/server.crt
keyfile  /etc/mosquitto/certs/server.key

# Secure WebSockets for browsers
listener 8084
protocol websockets
certfile /etc/mosquitto/certs/server.crt
keyfile  /etc/mosquitto/certs/server.key

allow_anonymous false
password_file /etc/mosquitto/passwd

Recuerda abrir los mismos puertos en el firewall o el security group de tu nube.

¿Qué puerto MQTT deberías usar?

• Dispositivo o backend a través de internet: 8883 (TLS).
• Aplicación en el navegador: el puerto wss:// del broker, idealmente el 443.
• Red restrictiva: wss:// en el 443.
• Desarrollo local o una prueba rápida con un broker público: el 1883 sirve.

¿Listo para probar uno? Abre el cliente MQTT online, elige un broker y el puerto WebSocket seguro se rellena automáticamente.

Preguntas frecuentes