MQTT Gateway Cannot Connect: DNS, TLS and Authentication Checks

An MQTT connection has several gates: name resolution, IP routing, TCP connection, optional TLS negotiation and MQTT authentication. Changing topics will not fix a failure that occurs before the broker accepts the session. Read the gateway and broker logs together and identify the last successful layer.

Verify destination and network reachability

Confirm the broker hostname, port and transport. Plain MQTT and MQTT over TLS normally use different ports, but the actual service may be customized. Resolve the hostname from the gateway's network, test the destination port and check that firewalls allow outbound traffic and return packets.

A successful ping is not proof that the broker port is reachable, and a blocked ping is not proof that TCP is unavailable. Use a test matched to the required service and record whether the failure is DNS timeout, route failure, connection refusal or connection timeout.

Validate time and TLS material

TLS certificate validation depends on the gateway clock. Confirm time synchronization, time zone handling and persistence after power loss. Load the correct CA chain and, for mutual TLS, the client certificate and matching private key. Check certificate validity, hostname and server-name indication requirements.

Do not disable certificate verification as a permanent fix. It hides configuration errors and exposes credentials and process data to interception. If a private certificate authority is used, manage its root certificate through an approved update process.

Check MQTT identity and permissions

Client IDs may need to be unique. A duplicate ID can make two gateways repeatedly disconnect each other. Confirm username, password or token exactly, including case and expiry. Review the CONNACK reason code and broker log before regenerating credentials.

Broker authorization can allow connection but deny publish or subscribe operations. Verify each topic against the assigned policy, including leading slashes, case, wildcards and tenant prefixes. Retained messages and last-will topics may have separate permissions.

Choose session and keepalive settings

Set keepalive shorter than the idle timeout imposed by firewalls or mobile networks, but not so short that thousands of devices create unnecessary load. Decide whether the session should persist and how queued messages behave after reconnecting. Configure a last will that indicates loss of communication without creating false process alarms.

For unstable links, use bounded exponential reconnect delays with jitter rather than rapid retries. Preserve locally timestamped records and prevent duplicate processing through message identifiers or application logic.

Test failure and recovery

Interrupt DNS, WAN and broker access separately in a controlled test. Confirm the diagnostic shown for each case, reconnect time, subscription restoration and buffered-data behavior. Verify that the platform distinguishes stale data from a live zero value.

Field checklist

• Confirm broker hostname, port, transport and DNS resolution.
• Check gateway time, CA chain, client certificate, key and hostname validation.
• Use a unique client ID and review CONNACK reason codes.
• Verify publish and subscribe permissions for exact topic paths.
• Test reconnection, resubscription and duplicate-free backfill.

Common questions

Why does the gateway connect without TLS but fail with TLS?

Typical causes are an inaccurate clock, missing CA certificates, hostname mismatch, unsupported TLS settings or a client certificate that does not match its private key.

Can two devices share a client ID?

Not reliably. Most brokers keep one active session per client ID, so the newer connection may disconnect the older one.

Does changing QoS fix a connection failure?

No. QoS affects message delivery after the MQTT session is accepted. Diagnose DNS, TCP, TLS and authentication first.