MQTT-Reason-Code-Suche
Du bekommst 0x87, 135 oder „Connection refused: not authorized“? Durchsuche alle MQTT-5-Reason-Codes und MQTT-3.1.1-Return-Codes und finde heraus, was sie bedeuten und wie du sie behebst.
- CONNACK
Der Server hat Benutzername oder Passwort abgelehnt.
So behebst du es: Prüfe die Zugangsdaten genau (Leerzeichen am Ende, Groß-/Kleinschreibung) und ob der Benutzer in der Passwortdatei oder im Auth-Backend des Brokers existiert.
Tipp: Zugangsdaten pro Benutzer und Topic-ACLs bekommst du leichter richtig hin, wenn du den Broker selbst kontrollierst – mit ConnectMQ verwaltest du beides in einem Dashboard.
- CONNACKPUBACKPUBRECSUBACKUNSUBACKDISCONNECT
Der Client darf das nicht – sich verbinden, auf dieses Topic publizieren oder diesen Filter abonnieren.
So behebst du es: Prüfe die Broker-ACL für diesen Benutzer und dieses Topic. Im CONNACK heißt es oft, dass anonymer Zugriff deaktiviert ist und keine Zugangsdaten gesendet wurden.
Tipp: Zugangsdaten pro Benutzer und Topic-ACLs bekommst du leichter richtig hin, wenn du den Broker selbst kontrollierst – mit ConnectMQ verwaltest du beides in einem Dashboard.
- CONNACK
Die Client-ID ist formal korrekt, wird vom Server aber nicht akzeptiert (zu lang, ungültige Zeichen oder leer, obwohl das nicht erlaubt ist).
So behebst du es: Verwende eine kurze alphanumerische Client-ID (bis 23 Zeichen ist immer sicher) oder lass den Broker eine vergeben – mit leerer ID und Clean Start.
- DISCONNECT
Eine andere Verbindung mit derselben Client-ID hat sich verbunden, daher wurde diese hier rausgeworfen.
So behebst du es: Gib jedem Gerät und jedem Browser-Tab eine eindeutige Client-ID. Zwei Clients mit derselben ID trennen sich gegenseitig in einer Endlosschleife.
- DISCONNECT
Innerhalb des 1,5-fachen Keep-Alive-Intervalls kam kein Paket an, deshalb wurde die Verbindung geschlossen.
So behebst du es: Sorge dafür, dass die Client-Schleife läuft (PINGREQ wird gesendet), blockiere den Netzwerk-Thread nicht oder erhöhe das Keep-Alive-Intervall.
- CONNACKPUBACKPUBRECSUBACKUNSUBACKDISCONNECT
Etwas ist fehlgeschlagen, und der Server will (oder kann) nicht sagen, was.
So behebst du es: Sieh in die Broker-Logs – dort steht meist die eigentliche Ursache. Achte auch auf die Reason-String-Property, falls eine mitgesendet wurde.
- CONNACKPUBACKPUBRECSUBACKDISCONNECT
Ein implementierungsspezifisches oder administratives Kontingent wurde überschritten (Nachrichten, Verbindungen, Speicher, …).
So behebst du es: Prüfe deinen Tarif oder die Broker-Quotas, reduziere das Nachrichtenvolumen oder bitte den Betreiber, das Limit zu erhöhen.
Tipp: Zugangsdaten pro Benutzer und Topic-ACLs bekommst du leichter richtig hin, wenn du den Broker selbst kontrollierst – mit ConnectMQ verwaltest du beides in einem Dashboard.
- 5Connection Refused, not authorized · Verbindung abgelehnt, nicht autorisiertMQTT 3.1.1 · CONNACK-Return-CodeCONNACK
Der Client ist nicht berechtigt, sich zu verbinden.
So behebst du es: Sende Zugangsdaten, falls anonymer Zugriff deaktiviert ist, und prüfe die Broker-ACL für diesen Benutzer.
Tipp: Zugangsdaten pro Benutzer und Topic-ACLs bekommst du leichter richtig hin, wenn du den Broker selbst kontrollierst – mit ConnectMQ verwaltest du beides in einem Dashboard.
So funktionieren MQTT-Reason-Codes
Ein Reason Code ist ein einzelnes Byte, mit dem der Broker (oder Client) meldet, wie eine Operation ausgegangen ist. In MQTT 5 steckt er in CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT und AUTH. Die Regel ist einfach: Werte unter 0x80 bedeuten Erfolg (manchmal mit Zusatzinfo, etwa 0x10 No matching subscribers), Werte ab 0x80 bedeuten einen Fehler. Dieselbe Zahl hat in jedem Paket, in dem sie erlaubt ist, dieselbe Bedeutung – 0x87 ist also immer „Not authorized“, egal ob beim Verbinden, Publizieren oder Abonnieren.
MQTT 3.1.1 ist deutlich wortkarger. Nur CONNACK enthält einen Return Code (0–5), und SUBACK kann nur „granted QoS 0/1/2“ oder 0x80 Failure melden. Ein abgelehntes QoS-0-Publish wird stillschweigend verworfen, und viele Broker schließen bei Fehlern einfach die TCP-Verbindung – oft ist das Broker-Log dein einziger Hinweis. Wenn du präzise Fehlermeldungen brauchst, lohnt sich der Umstieg auf MQTT 5.
Codes aus deiner Bibliothek richtig lesen
Client-Bibliotheken geben Codes unterschiedlich aus. Paho Python zeigt Dezimalwerte (rc=135), MQTT.js meist die Dezimalzahl zusammen mit einer Meldung, und die Kommandozeilen-Tools von Mosquitto geben Text wie „Connection Refused: not authorised“ aus. Das Suchfeld oben versteht alles davon: Gib 135, 0x87, 87 oder einen Begriff wie keep alive ein. In MQTT 5 kann der Broker zusätzlich eine Reason String-Property mit einer lesbaren Erklärung mitschicken – logge sie, denn sie ist oft genauer als der Code selbst.
Die Fehler, die dir am häufigsten begegnen
- 0x86 / Return Code 4 – falscher Benutzername oder falsches Passwort. Prüfe auf Tippfehler, Leerzeichen am Ende und Groß-/Kleinschreibung. Im Mosquitto-Authentifizierungs-Guide erfährst du, wie du Passwortdateien einrichtest.
- 0x87 / Return Code 5 – nicht autorisiert. Die Zugangsdaten können korrekt sein, aber die ACL sperrt das Topic oder der Broker lehnt anonyme Clients ab.
- 0x8E – Session übernommen. Zwei Clients teilen sich eine Client-ID. Erzeuge eindeutige IDs mit dem Client-ID-Generator.
- 0x8D – Keep-Alive-Timeout. Der Client hat aufgehört, Pakete zu senden. Lies, wie MQTT Keep Alive funktioniert.
- 0x95 – Paket zu groß. Prüfe deine Nachrichtengröße mit dem Paketgrößenrechner.
Viele Verbindungsprobleme kommen gar nicht bis zum Reason Code – DNS-Fehler, falsche Ports und TLS-Handshake-Fehler passieren, bevor MQTT überhaupt startet. Dafür gibt es die häufigsten MQTT-Verbindungsfehler und die Übersicht der MQTT-Ports. Oder du stellst das Problem im Online-MQTT-Client nach, der das CONNACK-Ergebnis im Log anzeigt.
Alle MQTT-5-Reason-Codes
Alle Reason Codes aus Abschnitt 2.4 der OASIS-MQTT-5.0-Spezifikation. Verlinke einen Code direkt mit #0x87.
| Code | Name | Pakete | Bedeutung & Lösung |
|---|---|---|---|
| 0x00 dez. 0 | Success Erfolg | CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, UNSUBACK, AUTH | Die Operation wurde erfolgreich abgeschlossen. Lösung: Nichts zu tun – das ist das normale Ergebnis. |
| 0x00 dez. 0 | Normal disconnection Normale Trennung | DISCONNECT | Die Verbindung wurde absichtlich geschlossen, die Will Message wird nicht gesendet. Lösung: Nichts zu tun. Kam die Trennung unerwartet, prüfe, welche Seite sie ausgelöst hat und warum. |
| 0x00 dez. 0 | Granted QoS 0 QoS 0 gewährt | SUBACK | Die Subscription wurde mit maximal QoS 0 akzeptiert. Lösung: Hast du QoS 1 oder 2 angefordert, hat der Broker herabgestuft – prüfe seine Einstellung für die maximale QoS. |
| 0x01 dez. 1 | Granted QoS 1 QoS 1 gewährt | SUBACK | Die Subscription wurde mit maximal QoS 1 akzeptiert. Lösung: Hast du QoS 2 angefordert, begrenzt der Broker auf QoS 1 – plane für At-least-once-Zustellung (idempotente Handler). |
| 0x02 dez. 2 | Granted QoS 2 QoS 2 gewährt | SUBACK | Die Subscription wurde mit maximal QoS 2 akzeptiert. Lösung: Nichts zu tun – du bekommst wie angefordert Exactly-once-Zustellung. |
| 0x04 dez. 4 | Disconnect with Will Message Trennung mit Will Message | DISCONNECT | Der Client möchte sich trennen, bittet den Server aber trotzdem, seine Will Message zu veröffentlichen. Lösung: Nichts zu tun – das ist eine bewusste Entscheidung des Clients. |
| 0x10 dez. 16 | No matching subscribers Keine passenden Abonnenten | PUBACK, PUBREC | Die Nachricht wurde angenommen, aber aktuell hat niemand dieses Topic abonniert. Lösung: Kein Fehler. Prüfe, ob der Subscriber verbunden ist und sein Topic-Filter exakt zum Topic passt (Groß-/Kleinschreibung beachten). |
| 0x11 dez. 17 | No subscription existed Keine Subscription vorhanden | UNSUBACK | Der Client wollte einen Topic-Filter abbestellen, den er gar nicht abonniert hatte. Lösung: Stelle sicher, dass der Unsubscribe-Filter Byte für Byte mit dem Filter beim Abonnieren übereinstimmt. |
| 0x18 dez. 24 | Continue authentication Authentifizierung fortsetzen | AUTH | Eine erweiterte Authentifizierung läuft, und ein weiterer AUTH-Schritt ist nötig. Lösung: Dein Client muss mit einem AUTH-Paket antworten, das den nächsten Schritt der Authentifizierungsmethode enthält. |
| 0x19 dez. 25 | Re-authenticate Erneut authentifizieren | AUTH | Der Client möchte die erweiterte Authentifizierung auf einer bestehenden Verbindung erneut durchführen. Lösung: Nichts zu tun – wird genutzt, um Zugangsdaten wie ablaufende Tokens zu erneuern. |
| 0x80 dez. 128 | Unspecified error Nicht näher bestimmter Fehler | CONNACK, PUBACK, PUBREC, SUBACK, UNSUBACK, DISCONNECT | Etwas ist fehlgeschlagen, und der Server will (oder kann) nicht sagen, was. Lösung: Sieh in die Broker-Logs – dort steht meist die eigentliche Ursache. Achte auch auf die Reason-String-Property, falls eine mitgesendet wurde. |
| 0x81 dez. 129 | Malformed Packet Fehlerhaftes Paket | CONNACK, DISCONNECT | Das empfangene Paket entspricht nicht der MQTT-Spezifikation und konnte nicht geparst werden. Lösung: Aktualisiere deine Client-Bibliothek, stelle sicher, dass die Protokollversion passt, und prüfe, dass du nicht MQTT mit einem Nicht-MQTT-Port sprichst (oder Klartext-TCP mit einem TLS-Port). |
| 0x82 dez. 130 | Protocol Error Protokollfehler | CONNACK, DISCONNECT | Das Paket wurde korrekt geparst, verletzt aber eine Protokollregel, z. B. ein zweites CONNECT oder eine doppelte Property. Lösung: Meist ein Bug in der Client-Bibliothek oder in eigenem Paketcode. Aktualisiere die Bibliothek und sende Pakete nicht in falscher Reihenfolge. |
| 0x83 dez. 131 | Implementation specific error Implementierungsspezifischer Fehler | CONNACK, PUBACK, PUBREC, SUBACK, UNSUBACK, DISCONNECT | Das Paket ist gültig, aber der Server lehnt es aus einem brokerspezifischen Grund ab. Lösung: Lies den Reason String sowie Doku und Logs des Brokers – die Ursache hängt vom Broker ab (Plugins, Limits, Richtlinien). |
| 0x84 dez. 132 | Unsupported Protocol Version Nicht unterstützte Protokollversion | CONNACK | Der Server unterstützt die vom Client angeforderte MQTT-Protokollversion nicht. Lösung: Stelle den Client auf MQTT 3.1.1 (Protocol Level 4) um oder aktualisiere auf einen Broker, der MQTT 5 unterstützt. |
| 0x85 dez. 133 | Client Identifier not valid Ungültige Client-ID | CONNACK | Die Client-ID ist formal korrekt, wird vom Server aber nicht akzeptiert (zu lang, ungültige Zeichen oder leer, obwohl das nicht erlaubt ist). Lösung: Verwende eine kurze alphanumerische Client-ID (bis 23 Zeichen ist immer sicher) oder lass den Broker eine vergeben – mit leerer ID und Clean Start. |
| 0x86 dez. 134 | Bad User Name or Password Falscher Benutzername oder falsches Passwort | CONNACK | Der Server hat Benutzername oder Passwort abgelehnt. Lösung: Prüfe die Zugangsdaten genau (Leerzeichen am Ende, Groß-/Kleinschreibung) und ob der Benutzer in der Passwortdatei oder im Auth-Backend des Brokers existiert. |
| 0x87 dez. 135 | Not authorized Nicht autorisiert | CONNACK, PUBACK, PUBREC, SUBACK, UNSUBACK, DISCONNECT | Der Client darf das nicht – sich verbinden, auf dieses Topic publizieren oder diesen Filter abonnieren. Lösung: Prüfe die Broker-ACL für diesen Benutzer und dieses Topic. Im CONNACK heißt es oft, dass anonymer Zugriff deaktiviert ist und keine Zugangsdaten gesendet wurden. |
| 0x88 dez. 136 | Server unavailable Server nicht verfügbar | CONNACK | Der MQTT-Server ist gerade nicht erreichbar. Lösung: Versuche es mit exponentiellem Backoff erneut. Hält das Problem an, prüfe Zustand des Brokers, Cluster-Status und Wartungsfenster. |
| 0x89 dez. 137 | Server busy Server ausgelastet | CONNACK, DISCONNECT | Der Server ist überlastet und lehnt die Operation ab; versuche es später erneut. Lösung: Warte ab und versuche es mit Jitter erneut, damit sich nicht Tausende Geräte im selben Moment neu verbinden. |
| 0x8A dez. 138 | Banned Gesperrt | CONNACK | Dieser Client wurde administrativ gesperrt. Lösung: Wende dich an den Betreiber des Brokers. Wiederholte fehlgeschlagene Logins oder missbräuchlicher Traffic sind häufige Gründe für Sperren. |
| 0x8B dez. 139 | Server shutting down Server fährt herunter | DISCONNECT | Der Server wird heruntergefahren. Lösung: Verbinde dich mit Backoff neu; nutze eine Persistent Session, damit Subscriptions und gepufferte QoS-1/2-Nachrichten erhalten bleiben. |
| 0x8C dez. 140 | Bad authentication method Ungültige Authentifizierungsmethode | CONNACK, DISCONNECT | Die Authentifizierungsmethode im CONNECT wird nicht unterstützt oder passt nicht zur verwendeten Methode. Lösung: Entferne die Authentication-Method-Property oder setze eine Methode, die der Broker unterstützt (z. B. SCRAM-SHA-256). |
| 0x8D dez. 141 | Keep Alive timeout Keep-Alive-Timeout | DISCONNECT | Innerhalb des 1,5-fachen Keep-Alive-Intervalls kam kein Paket an, deshalb wurde die Verbindung geschlossen. Lösung: Sorge dafür, dass die Client-Schleife läuft (PINGREQ wird gesendet), blockiere den Netzwerk-Thread nicht oder erhöhe das Keep-Alive-Intervall. |
| 0x8E dez. 142 | Session taken over Session übernommen | DISCONNECT | Eine andere Verbindung mit derselben Client-ID hat sich verbunden, daher wurde diese hier rausgeworfen. Lösung: Gib jedem Gerät und jedem Browser-Tab eine eindeutige Client-ID. Zwei Clients mit derselben ID trennen sich gegenseitig in einer Endlosschleife. |
| 0x8F dez. 143 | Topic Filter invalid Ungültiger Topic-Filter | SUBACK, UNSUBACK, DISCONNECT | Der Topic-Filter ist formal korrekt, wird von diesem Server aber nicht akzeptiert. Lösung: Prüfe die Position der Wildcards (+ muss eine ganze Ebene füllen, # muss am Ende stehen) und etwaige Broker-Limits für Topic-Tiefe oder -Länge. |
| 0x90 dez. 144 | Topic Name invalid Ungültiger Topic-Name | CONNACK, PUBACK, PUBREC, DISCONNECT | Der Topic-Name ist formal korrekt, wird von Client oder Server aber nicht akzeptiert. Lösung: Publiziere nie auf ein Topic mit + oder #, vermeide leere Topics und prüfe die Limits des Brokers für Topic-Länge und -Tiefe. |
| 0x91 dez. 145 | Packet Identifier in use Packet Identifier bereits belegt | PUBACK, PUBREC, SUBACK, UNSUBACK | Der Packet Identifier wird bereits für einen anderen laufenden Austausch verwendet. Lösung: Meist ein Bug in der Client-Bibliothek oder eine inkonsistent wiederhergestellte Session. Aktualisiere die Bibliothek oder starte eine saubere Session. |
| 0x92 dez. 146 | Packet Identifier not found Packet Identifier nicht gefunden | PUBREL, PUBCOMP | Der Packet Identifier ist unbekannt – der Zustand des QoS-2-Ablaufs ist verloren gegangen. Lösung: Tritt auf, wenn der Session-State verloren ging (z. B. Clean Start oder Broker-Neustart ohne Persistenz). Aktiviere Persistenz auf dem Broker. |
| 0x93 dez. 147 | Receive Maximum exceeded Receive Maximum überschritten | DISCONNECT | Es wurden mehr unbestätigte QoS-1/2-PUBLISH-Pakete gesendet, als der Empfänger erlaubt. Lösung: Halte dich an das Receive Maximum aus CONNACK/CONNECT; begrenze die Zahl der In-flight-Nachrichten in den Client-Einstellungen. |
| 0x94 dez. 148 | Topic Alias invalid Ungültiger Topic Alias | DISCONNECT | Ein Topic Alias war 0, größer als das Topic Alias Maximum oder wurde vor seiner Definition verwendet. Lösung: Halte dich an das Topic Alias Maximum, das die Gegenseite angekündigt hat, oder deaktiviere Topic Aliases. |
| 0x95 dez. 149 | Packet too large Paket zu groß | CONNACK, DISCONNECT | Das Paket überschreitet die vom Empfänger erlaubte maximale Paketgröße. Lösung: Verkleinere den Payload (komprimieren, aufteilen oder nur eine Referenz senden) oder erhöhe das Nachrichtengrößen-Limit des Brokers. |
| 0x96 dez. 150 | Message rate too high Nachrichtenrate zu hoch | DISCONNECT | Der Client publiziert schneller, als der Server erlaubt. Lösung: Drossle die Publishes, fasse Messwerte in weniger Nachrichten zusammen oder erhöhe das Rate-Limit am Broker. |
| 0x97 dez. 151 | Quota exceeded Kontingent überschritten | CONNACK, PUBACK, PUBREC, SUBACK, DISCONNECT | Ein implementierungsspezifisches oder administratives Kontingent wurde überschritten (Nachrichten, Verbindungen, Speicher, …). Lösung: Prüfe deinen Tarif oder die Broker-Quotas, reduziere das Nachrichtenvolumen oder bitte den Betreiber, das Limit zu erhöhen. |
| 0x98 dez. 152 | Administrative action Administrative Maßnahme | DISCONNECT | Die Verbindung wurde von einem Administrator geschlossen. Lösung: Wende dich an den Betreiber des Brokers – jemand hat diesen Client manuell oder über eine Admin-API rausgeworfen. |
| 0x99 dez. 153 | Payload format invalid Ungültiges Payload-Format | CONNACK, PUBACK, PUBREC, DISCONNECT | Der Payload passt nicht zum Payload Format Indicator (z. B. als UTF-8 markiert, aber kein gültiges UTF-8). Lösung: Setze Payload Format Indicator = 1 nur, wenn der Payload gültiger UTF-8-Text ist; Binärdaten sendest du ohne. |
| 0x9A dez. 154 | Retain not supported Retain nicht unterstützt | CONNACK, DISCONNECT | Der Server unterstützt keine Retained Messages, der Client hat aber eine gesendet. Lösung: Entferne das Retain-Flag bei Publishes und bei der Will Message oder nutze einen Broker, der Retain unterstützt. |
| 0x9B dez. 155 | QoS not supported QoS nicht unterstützt | CONNACK, DISCONNECT | Der Client hat eine höhere QoS verwendet als die Maximum QoS, die der Server im CONNACK angekündigt hat. Lösung: Lies Maximum QoS aus dem CONNACK und publiziere (und setze die Will-QoS) höchstens mit diesem Wert. |
| 0x9C dez. 156 | Use another server Anderen Server verwenden | CONNACK, DISCONNECT | Der Client soll vorübergehend einen anderen Server verwenden. Lösung: Lies die Server-Reference-Property und verbinde dich dorthin; unterstütze Weiterleitungen in deinem Client, wenn du Cluster betreibst. |
| 0x9D dez. 157 | Server moved Server umgezogen | CONNACK, DISCONNECT | Der Server ist dauerhaft umgezogen; der Client soll einen anderen Server verwenden. Lösung: Aktualisiere den Broker-Hostnamen in deiner Konfiguration anhand der Server-Reference-Property. |
| 0x9E dez. 158 | Shared Subscriptions not supported Shared Subscriptions nicht unterstützt | SUBACK, DISCONNECT | Der Server unterstützt keine Shared Subscriptions ($share/…). Lösung: Nutze normale Subscriptions oder einen Broker mit Shared-Subscription-Unterstützung für Consumer mit Lastverteilung. |
| 0x9F dez. 159 | Connection rate exceeded Verbindungsrate überschritten | CONNACK, DISCONNECT | Der Client verbindet sich zu oft; das Limit für die Verbindungsrate wurde erreicht. Lösung: Baue exponentiellen Backoff mit Jitter für Reconnects ein und suche nach einer Reconnect-Schleife (oft durch doppelte Client-IDs verursacht). |
| 0xA0 dez. 160 | Maximum connect time Maximale Verbindungsdauer | DISCONNECT | Die für diesen Client erlaubte maximale Verbindungsdauer ist erreicht. Lösung: Verbinde dich neu; eine Persistent Session sorgt dafür, dass beim kurzen Reconnect nichts verloren geht. |
| 0xA1 dez. 161 | Subscription Identifiers not supported Subscription Identifiers nicht unterstützt | SUBACK, DISCONNECT | Der Server unterstützt die Subscription-Identifier-Property nicht. Lösung: Entferne den Subscription Identifier aus dem SUBSCRIBE und ordne Nachrichten stattdessen anhand des Topics zu. |
| 0xA2 dez. 162 | Wildcard Subscriptions not supported Wildcard-Subscriptions nicht unterstützt | SUBACK, DISCONNECT | Der Server unterstützt keine Subscriptions mit den Wildcards + oder #. Lösung: Abonniere exakte Topic-Namen oder nutze einen Broker, der Wildcard-Subscriptions unterstützt. |
MQTT-3.1.1-Return-Codes
Die CONNACK-Return-Codes 0–5 und der SUBACK-Fehlercode aus der MQTT-3.1.1-Spezifikation.
| Code | Name | Pakete | Bedeutung & Lösung |
|---|---|---|---|
| 0 dez. 0 | Connection Accepted Verbindung akzeptiert | CONNACK | Der Broker hat die Verbindung akzeptiert. Lösung: Nichts zu tun. |
| 1 dez. 1 | Connection Refused, unacceptable protocol version Verbindung abgelehnt, nicht akzeptierte Protokollversion | CONNACK | Der Broker unterstützt das vom Client angeforderte Protocol Level nicht. Lösung: Stelle den Client passend zum Broker auf MQTT 3.1.1 (Level 4) oder 3.1 (Level 3) ein. |
| 2 dez. 2 | Connection Refused, identifier rejected Verbindung abgelehnt, Client-ID zurückgewiesen | CONNACK | Die Client-ID ist gültiges UTF-8, wird vom Broker aber nicht erlaubt. Lösung: Verwende 1–23 Zeichen aus [0-9a-zA-Z] oder sende eine leere ID mit Clean Session = true. |
| 3 dez. 3 | Connection Refused, server unavailable Verbindung abgelehnt, Server nicht verfügbar | CONNACK | Die Netzwerkverbindung hat geklappt, aber der MQTT-Dienst ist nicht verfügbar. Lösung: Versuche es mit Backoff erneut und prüfe den Zustand des Brokers. |
| 4 dez. 4 | Connection Refused, bad user name or password Verbindung abgelehnt, falscher Benutzername oder falsches Passwort | CONNACK | Benutzername oder Passwort sind fehlerhaft formatiert oder falsch. Lösung: Prüfe die Zugangsdaten und ob der Benutzer im Auth-Backend des Brokers existiert. |
| 5 dez. 5 | Connection Refused, not authorized Verbindung abgelehnt, nicht autorisiert | CONNACK | Der Client ist nicht berechtigt, sich zu verbinden. Lösung: Sende Zugangsdaten, falls anonymer Zugriff deaktiviert ist, und prüfe die Broker-ACL für diesen Benutzer. |
| 0x80 dez. 128 | Failure Fehlgeschlagen | SUBACK | Die Subscription wurde abgelehnt – meist wegen einer ACL oder eines ungültigen Topic-Filters. Lösung: Prüfe die Filter-Syntax und ob der Benutzer ihn abonnieren darf. MQTT 3.1.1 liefert keine weiteren Details; sieh ins Broker-Log. |
FAQ zu Reason Codes
Was bedeutet der MQTT-Reason-Code 0x87 (135)?
0x87 bedeutet Not authorized. Im CONNACK hat der Broker die Verbindung abgelehnt (oft, weil anonymer Zugriff deaktiviert ist und keine Zugangsdaten gesendet wurden). In PUBACK, SUBACK oder DISCONNECT heißt es, dass dem Benutzer laut Broker-ACL die Berechtigung für dieses Topic fehlt.
Was ist der Unterschied zwischen Reason Code und Return Code?
MQTT 3.1.1 kennt Return Codes nur in CONNACK (0–5) und SUBACK (0x00–0x02 und 0x80). MQTT 5 hat sie durch Reason Codes ersetzt, die in fast jeder Bestätigung, in DISCONNECT und in AUTH vorkommen – und Werte ab 0x80 bedeuten immer einen Fehler.
Warum trennt sich mein Client ständig mit 0x8E Session taken over?
Zwei Verbindungen verwenden dieselbe Client-ID. Sobald sich die zweite verbindet, trennt der Broker die erste. Verbinden sich beide automatisch neu, werfen sie sich gegenseitig in einer Endlosschleife raus. Gib jedem Gerät und jedem Browser-Tab eine eindeutige Client-ID.
Warum bekomme ich in MQTT 3.1.1 den Return Code 5?
Return Code 5 bedeutet Connection Refused, not authorized. Der Broker verlangt eine Authentifizierung oder der Benutzer wird durch die Zugriffsregeln blockiert. Sende gültigen Benutzernamen und Passwort und prüfe die Broker-ACL bzw. die Einstellung allow_anonymous.