Les ports MQTT déterminent comment vos appareils atteignent un broker, si le trafic est chiffré et si un pare-feu d'entreprise le laisse passer. Ce guide explique les quatre ports que vous rencontrerez en pratique (1883, 8883, 8083 et 8084), quand utiliser chacun, et comment les tester tous en quelques minutes sur un broker réel.
La réponse courte : quatre ports MQTT courants
MQTT est en soi un protocole applicatif qui fonctionne sur un flux d'octets fiable. La façon dont ce flux est transporté détermine le port (si vous vous demandez pourquoi c'est toujours TCP, lisez MQTT utilise-t-il TCP ou UDP). L'IANA a enregistré le port 1883 pour MQTT et le port 8883 pour MQTT sur TLS. Les ports WebSocket relèvent de la convention plutôt que de l'enregistrement, et varient selon les brokers ; ConnectMQ utilise 8083 et 8084.
| Port | Transport | Chiffré | Clients typiques | En production ? |
|---|---|---|---|---|
| 1883 | MQTT sur TCP | Non | Outils CLI, appareils de labo, réseaux locaux | Uniquement sur des réseaux de confiance et isolés |
| 8883 | MQTT sur TLS sur TCP | Oui | Appareils, passerelles, services backend | Oui, le choix par défaut |
| 8083 | MQTT sur WebSocket (ws://) |
Non | Démos dans le navigateur, tests locaux | Rarement |
| 8084 | MQTT sur WebSocket sécurisé (wss://) |
Oui | Navigateurs, applications web mobiles, réseaux restrictifs | Oui, pour les clients web |
Sur ConnectMQ, les deux endpoints WebSocket utilisent le chemin /mqtt : l'URL complète pour un navigateur est donc wss://broker.connectmq.com:8084/mqtt. Les ports TLS présentent un certificat Let's Encrypt, reconnu par défaut sur presque tous les systèmes d'exploitation et navigateurs.
Port 1883 : MQTT en clair sur TCP
Le port 1883 transporte des paquets MQTT bruts, sans chiffrement. Noms d'utilisateur, mots de passe et payloads traversent le réseau en clair, lisibles par quiconque peut capturer le trafic sur le chemin. Le port 1883 convient donc pour :
- L'apprentissage et les expériences rapides sur le serveur MQTT public gratuit.
- Un broker local à l'intérieur d'un réseau de labo isolé.
- Des appareils très contraints qui communiquent avec une passerelle proche sur un segment que vous maîtrisez.
Il ne convient pas pour faire transiter des identifiants sur Internet. Si vous voyez une flotte de production sur 1883, considérez-le comme un problème à corriger.
Port 8883 : MQTT sur TLS
Le port 8883 encapsule les mêmes paquets MQTT dans une session TLS. Le client vérifie le certificat du broker auprès d'une autorité de certification de confiance, négocie les clés, et seulement ensuite envoie le paquet CONNECT avec ses identifiants. C'est le choix standard pour les appareils, les passerelles et les services backend.
Ce que le port 8883 exige du client :
- Une bibliothèque TLS (mbedTLS sur ESP32, OpenSSL dans la plupart des outils Linux, la pile de la plateforme en .NET et Java).
- Un magasin de CA de confiance pour vérifier le certificat du broker. Ne désactivez jamais la vérification en production.
- Une horloge raisonnablement exacte, car la validité d'un certificat dépend de la date. Les appareils sans horloge temps réel doivent se synchroniser en NTP avant de se connecter.
- Le Server Name Indication (SNI) renseigné avec le nom d'hôte du broker. La plupart des bibliothèques le font automatiquement quand vous vous connectez par nom d'hôte.
Le surcoût se limite à une négociation à la connexion et à des paquets légèrement plus gros. Comme MQTT maintient une seule connexion de longue durée, cette négociation est rare, et le surcoût en régime établi reste faible. Notre guide des bonnes pratiques de sécurité MQTT couvre le reste de la liste de durcissement.
Ports 8083 et 8084 : MQTT sur WebSocket
Les navigateurs ne peuvent pas ouvrir de sockets TCP bruts : les applications web encapsulent donc MQTT dans des trames WebSocket. Le client envoie d'abord une requête HTTP d'upgrade vers un chemin (ici /mqtt), puis échange des paquets MQTT binaires sur la connexion ainsi promue.
- 8083 (
ws://) n'est pas chiffré. Les navigateurs modernes le bloquent depuis les pages servies en HTTPS (contenu mixte) : il sert donc surtout aux tests locaux. - 8084 (
wss://) est du WebSocket sur TLS, la seule option réaliste pour un tableau de bord web en production.
WebSocket offre un second avantage : pour de nombreux proxys et pare-feux, il ressemble à du trafic HTTPS ordinaire. Quand le réseau d'une usine ou d'un hôtel bloque le 8883, wss:// sur 8084 passe parfois là où le TLS brut échoue. Voir MQTT over WebSocket pour le code navigateur et les mises en garde liées aux proxys.
Conséquences pour le pare-feu
Les clients MQTT initient toujours la connexion en sortie vers le broker, et le broker renvoie les données sur cette même connexion. Cela simplifie beaucoup les règles de pare-feu :
- Autorisez le TCP sortant depuis les réseaux d'appareils vers le nom d'hôte du broker sur le 8883 (et le 8084 si vous avez des clients web).
- Aucune règle entrante n'est nécessaire côté appareils. Les appareils n'écoutent sur aucun port MQTT.
- Autorisez les connexions de longue durée. Certains pare-feux et passerelles NAT coupent silencieusement les sessions TCP inactives au bout de quelques minutes. Réglez l'intervalle de keep alive MQTT en dessous de ce délai (60 secondes est un choix courant) pour que les paquets PINGREQ maintiennent la correspondance active.
- Évitez l'interception TLS pour MQTT. Les équipements intermédiaires qui re-signent les certificats cassent la vérification des certificats sur les appareils. Exemptez le nom d'hôte du broker de l'inspection.
- Préférez les noms d'hôte aux listes d'IP autorisées lorsque votre pare-feu le permet, car les adresses des endpoints cloud peuvent changer.
Si vous ne pouvez faire ouvrir qu'un seul port, demandez le 8883. Si même cela est impossible, demandez le 8084 et faites passer vos clients par WebSocket sécurisé.
Tester chaque port MQTT en cinq minutes
Les commandes ci-dessous utilisent l'endpoint public anonyme broker.connectmq.com. Utilisez un client ID et un préfixe de topic uniques, et rappelez-vous que les topics publics sont visibles par tous.
Vérifier l'accessibilité TCP
# Linux / macOS
nc -vz broker.connectmq.com 1883
nc -vz broker.connectmq.com 8883
nc -vz broker.connectmq.com 8084
Sous Windows PowerShell, utilisez Test-NetConnection broker.connectmq.com -Port 8883 et cherchez TcpTestSucceeded : True.
Inspecter le certificat TLS sur 8883
openssl s_client -connect broker.connectmq.com:8883 \
-servername broker.connectmq.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
Vous devriez voir un émetteur Let's Encrypt et des dates valides. Si l'émetteur est le proxy de votre entreprise, c'est que l'interception TLS fait obstacle.
Publier et s'abonner sur 1883 et 8883
# Terminal A : abonnement en TLS (mosquitto active TLS quand un chemin de CA est fourni)
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i ports-sub-91c2 -t "connectmq/demo/91c2/#" -v
# Terminal B : publication en TCP en clair
mosquitto_pub -h broker.connectmq.com -p 1883 -i ports-pub-91c2 \
-t "connectmq/demo/91c2/hello" -m "sent on 1883, received on 8883"
Le message passe d'un port à l'autre, ce qui montre que les ports ne sont que des points d'entrée vers le même broker.
Tester le WebSocket sécurisé sur 8084 avec 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));
Pour du TLS brut depuis Node, remplacez l'URL par mqtts://broker.connectmq.com:8883.
Résoudre les problèmes de ports
| Symptôme | Cause probable | Solution |
|---|---|---|
| Délai de connexion dépassé sur 8883, alors que 1883 fonctionne | Le pare-feu n'autorise que les ports courants | Demandez l'ouverture du 8883 en sortie ou utilisez le 8084 |
| Échec de la négociation TLS, certificat inconnu | Magasin de CA absent ou inspection TLS | Installez les certificats de CA, exemptez l'hôte du broker de l'inspection |
| Certificat pas encore valide | Horloge de l'appareil incorrecte | Synchronisez le NTP avant de vous connecter |
| Le WebSocket renvoie 404 | Mauvais chemin | Utilisez /mqtt |
Le navigateur refuse ws:// |
Contenu mixte sur une page HTTPS | Utilisez wss:// sur 8084 |
| Déconnexions toutes les quelques minutes | Délai d'inactivité du NAT | Réglez le keep alive en dessous de ce délai |
Passer des ports de test à la production
Sur le serveur MQTT public gratuit, vous vous connectez anonymement ; sur un broker privé, vous ajoutez des identifiants. Quand vous créez un broker dans le portail ConnectMQ, vous recevez un nom d'utilisateur, un mot de passe et un client ID lié à ces identifiants, et les mêmes quatre ports s'appliquent. Une configuration de production typique utilise le 8883 pour les appareils et les passerelles et le 8084 pour le tableau de bord web, en réservant 1883 et 8083 au débogage local. Comme ConnectMQ est un broker MQTT managé, les certificats sont renouvelés pour vous et il n'y a aucune configuration de listener à maintenir. Le guide du broker MQTT cloud compare plus en profondeur les options d'hébergement, et le tutoriel MQTT pour débutants vous guide de bout en bout dans votre première connexion.
Démarrez avec ConnectMQ
Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et connectez-vous sur le 8883 ou le 8084 avec les identifiants générés par le portail. Le client intégré au navigateur de ConnectMQ vous permet de confirmer la connexion avant même de toucher au firmware.
Questions fréquentes
Quel est le port MQTT par défaut ?
Le port MQTT par défaut est 1883 pour le TCP non chiffré et 8883 pour MQTT sur TLS. Les deux sont enregistrés auprès de l'IANA.
Quel port MQTT utiliser en production ?
Utilisez le 8883 pour les appareils et les services, et le 8084 (WebSocket sécurisé) pour les navigateurs. Évitez le 1883 sur Internet, car les identifiants y circulent en clair.
Puis-je faire tourner MQTT sur le port 443 ?
Certains brokers proposent MQTT sur WebSocket ou TLS sur le port 443 pour franchir les pare-feux stricts. broker.connectmq.com utilise 8883 et 8084 : demandez donc à votre équipe réseau d'autoriser le trafic sortant vers ces ports.
Pourquoi ma connexion WebSocket échoue-t-elle alors que TCP fonctionne ?
Les causes les plus fréquentes sont l'absence du chemin /mqtt, l'utilisation de ws:// depuis une page HTTPS, ou un proxy qui ne prend pas en charge les upgrades WebSocket.
