How to Fix an MQTT Client That Connects Then Disconnects
The client reports a successful connection and then, seconds later, it is gone - and the cycle repeats. This is different from a client that never connects; the handshake clearly succeeded. The immediate drop points at a small set of causes: two clients sharing an identity, a keepalive the client cannot meet, or a session-level rejection that arrives just after connect. This page orders those causes by how often they are the culprit.
Fix an MQTT Client Connecting Then Disconnecting in one line: An MQTT client that connects then immediately disconnects is most often two clients using the same client ID, where the broker kicks the older on each new connect. Other causes are a keepalive the client cannot honor on a slow link and an authorization failure applied just after connect. Check for a duplicate client ID first.
First Checks
Look at the pattern. If the disconnect is near-instant and repeats on a fixed rhythm, especially with a second device also cycling, suspect a shared client ID. If the disconnect comes after roughly the keepalive interval of silence, suspect keepalive. If it comes right after connect with an authorization-flavored reason, suspect permissions. The timing alone narrows the field before you touch anything.
Capture the disconnect reason if your client and broker expose one. A takeover, a keepalive timeout, and a not-authorized result are different reason codes, and reading the reason turns three hypotheses into one. If you cannot get a reason from the client, the broker log usually records why it dropped the session.
Rule Out a Duplicate Client ID
MQTT requires every connected client to have a unique client ID. When a second client connects with an ID already in use, the broker disconnects the first to honor the new one - a session takeover. If two devices, or a device and a leftover test client, share an ID, they fight forever: each connect kicks the other, producing exactly this connect-then-drop cycle across both.
The test is decisive: temporarily give one client a different ID and watch both stabilize. The fix is a genuinely unique client ID per device, derived from a stable per-device identifier so it never collides even after a reboot or a firmware reflash. This is closely related to how reconnect loops form - see fixing an MQTT client reconnect loop.
Check for a Keepalive the Client Cannot Meet
If the drop happens after a period of silence rather than instantly, the client is failing to send a ping within the keepalive window and the broker is declaring it dead. On a slow or intermittent link, a client that gets busy or loses the link briefly can miss its ping and be disconnected even though nothing is truly wrong. The disconnect then triggers a reconnect and the cycle continues.
Confirm by widening the keepalive and seeing if the drops stop, then set a keepalive the client can reliably meet on its real link. On cellular, this interacts with carrier NAT and must be tuned deliberately - the full method is in setting an MQTT keepalive for a cellular link. A keepalive the client cannot honor is a self-inflicted disconnect.
Rule Out a Post-Connect Authorization Drop
Some brokers accept the connection, then enforce authorization on the first subscribe or publish, dropping the client when it attempts something its credentials do not allow. The connect succeeds, the first action fails, and the client is disconnected - which reads as a connect-then-drop even though the real fault is a permission on a topic. The clue is that the drop coincides with the client's first subscribe or publish, not with idle time.
Check whether the client is trying to use a topic its account cannot access, given the broker's per-branch access control. If the topic tree grants rights per branch, a client publishing outside its branch gets refused. Aligning the client's topics to its granted branch fixes it - which is why topic and access design matter, as in designing MQTT topics for an oilfield fleet.
Verify the Fix
After the change, watch the client stay connected across several keepalive intervals and through at least one idle period and one active period. A duplicate-ID fix should immediately stabilize both previously-fighting clients. A keepalive fix should survive idle time that used to drop it. An authorization fix should let the first subscribe and publish succeed without a drop.
Confirm the disconnect reason is gone from the broker log too, not just that the client appears up. A client that stays connected in your test window but still logs occasional takeovers means a second client is still occasionally grabbing the ID, and the duplicate is not fully resolved.
Common Mistakes
The dominant mistake is hard-coding the same client ID into a fleet image so every device collides on connect, then blaming the broker for unstable clients. The second is setting an aggressive keepalive the client cannot meet on a real field link and reading the resulting timeout as a network fault.
Another is missing that the drop coincides with the first subscribe or publish, which points at authorization, not connectivity. And do not treat the reconnect that follows each drop as the problem - the reconnect is the client behaving correctly after a disconnect whose real cause is upstream.
Frequently Asked Questions
Why does my MQTT client connect and then immediately disconnect?
Most often two clients share the same client ID, so each new connect makes the broker kick the other in a session takeover, producing an endless connect-then-drop cycle. Give each device a unique, stable client ID and watch both stabilize. If the drop follows idle time instead, suspect keepalive; if it follows the first subscribe or publish, suspect authorization.
Can two MQTT clients use the same client ID?
No. The client ID must be unique per connected client. When a second client connects with an ID already in use, the broker disconnects the first to honor the new one. Two devices sharing an ID will disconnect each other forever. Derive the client ID from a stable per-device identifier so it never collides, even after a reboot or reflash.
How do I tell a duplicate-ID drop from a keepalive drop?
By timing and reason code. A duplicate-ID takeover is near-instant and repeats on a fixed rhythm, often with a second device also cycling, and shows a takeover reason. A keepalive drop follows a period of silence roughly one keepalive interval long and shows a keepalive-timeout reason. Read the disconnect reason from the client or broker log to distinguish them.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- MQTT Version 5.0 (OASIS Standard) - OASIS (v5.0, 2019)
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.