🚨 Telegraf Error Guide: '[inputs.mqtt_consumer] dial tcp: connection refused' — Fix MQTT Broker Connectivity

Overview

The mqtt_consumer input subscribes to an MQTT broker and turns incoming messages into metrics. When the broker refuses the TCP connection, the plugin surfaces the raw dial error from the Paho MQTT client:

2026-07-12T12:00:00Z E! [inputs.mqtt_consumer] Error in plugin: network Error : dial tcp 10.0.0.6:1883: connect: connection refused

A closely related form appears when you point a plain tcp:// scheme at a TLS-only listener (typically port 8883), which resets or refuses the handshake:

E! [inputs.mqtt_consumer] Error in plugin: network Error : EOF

Telegraf keeps retrying on each interval, but no messages are consumed and no metrics are produced from the affected topics.

Symptoms

• Metrics derived from MQTT topics stop appearing while other inputs report normally.
• journalctl -u telegraf repeats dial tcp <broker>:1883: connect: connection refused every collection interval.
• The broker host answers ping but the MQTT port refuses connections.
• The connection succeeds intermittently, then drops — a sign of a duplicate client_id fighting another consumer.
• Switching a device from a plaintext to a TLS listener (1883 → 8883) broke collection with an EOF or handshake error.

Common Root Causes

• Broker down or not listening — the MQTT service (Mosquitto, EMQX, HiveMQ) is stopped or bound only to 127.0.0.1, so remote connects are refused.
• Wrong port — pointing at 1883 (plaintext) when the broker only exposes 8883 (TLS), or vice versa.
• Wrong URI scheme — using tcp:// against a TLS listener; TLS brokers need ssl:// (or tls://) plus a tls_ca/certs block.
• Bad or missing credentials — the broker requires username/password and rejects anonymous connects, or the wrong password is supplied.
• Duplicate client_id — two consumers share an ID, so the broker disconnects the older session each time the other connects.
• Firewall/security group blocking the port — a network ACL drops TCP/1883 even though the broker is up.
• Topic mismatch — the connection succeeds but topics never match published subjects, so no data flows (no error, but empty metrics).

Diagnostic Workflow

First confirm the broker is actually listening and reachable from the Telegraf host. If mosquitto_sub also fails, the problem is the broker/network, not Telegraf:

# Is anything listening on the MQTT port?
nc -z -v 10.0.0.6 1883

# Subscribe directly with the mosquitto client (plaintext)
mosquitto_sub -h 10.0.0.6 -p 1883 -t 'sensors/#' -u "$MQTT_USER" -P "$MQTT_PASS" -v

# TLS listener
mosquitto_sub -h 10.0.0.6 -p 8883 --cafile /etc/telegraf/ca.pem -t 'sensors/#' -v

Then run only the mqtt_consumer input under Telegraf to confirm it connects and receives after a fix:

telegraf --config /etc/telegraf/telegraf.conf --test --input-filter mqtt_consumer --debug

A correct plaintext block names the broker with an explicit scheme, a unique client_id, and topics:

[[inputs.mqtt_consumer]]
  servers = ["tcp://10.0.0.6:1883"]
  topics = [
    "sensors/+/temperature",
    "telegraf/host01/#",
  ]
  client_id = "telegraf-host01"
  username = "${MQTT_USER}"
  password = "${MQTT_PASS}"
  qos = 0
  connection_timeout = "30s"
  data_format = "influx"

For a TLS broker, switch the scheme to ssl://, use the TLS port, and supply the CA:

[[inputs.mqtt_consumer]]
  servers = ["ssl://10.0.0.6:8883"]
  topics = ["sensors/#"]
  client_id = "telegraf-host01"
  username = "${MQTT_USER}"
  password = "${MQTT_PASS}"
  tls_ca = "/etc/telegraf/ca.pem"
  insecure_skip_verify = false
  data_format = "influx"

If the connection is fine but no metrics appear, the topics patterns do not match what devices publish — verify with mosquitto_sub -t '#' to see live subjects.

Example Root Cause Analysis

An IoT gateway fleet stopped reporting after the broker team “hardened” Mosquitto. Telegraf logged dial tcp 10.0.0.6:1883: connect: connection refused on every interval, yet ping 10.0.0.6 succeeded. Running nc -z -v 10.0.0.6 1883 from the Telegraf host was also refused, ruling out Telegraf itself.

The hardening change had disabled the plaintext listener and moved all clients to TLS on 8883, but the Telegraf config still pointed at tcp://10.0.0.6:1883. Updating servers to ["ssl://10.0.0.6:8883"] and adding tls_ca = "/etc/telegraf/ca.pem" restored collection immediately. The lesson: an MQTT “connection refused” almost always means nothing is listening on that host:port — confirm the listener with nc/mosquitto_sub before assuming a Telegraf bug, and keep the URI scheme in step with the broker’s TLS posture.

Prevention Best Practices

• Always use an explicit scheme in servers (tcp:// or ssl://) so the port and transport can never drift apart.
• Give every consumer a unique, stable client_id (e.g. include the hostname) to avoid session-stealing disconnects.
• Store username/password in environment variables (${MQTT_USER}) referenced from the config, never inline in version control.
• Pin TLS brokers to 8883 with a managed tls_ca, and avoid insecure_skip_verify = true outside of throwaway testing.
• Alert on the broker’s own connection count and Telegraf’s gather errors so a refused connection is caught before data goes dark.
• Document which listeners (plaintext vs TLS) each environment exposes so config changes track broker changes.

Quick Command Reference

# Is the MQTT port open from the Telegraf host?
nc -z -v 10.0.0.6 1883

# Subscribe directly (plaintext / TLS)
mosquitto_sub -h 10.0.0.6 -p 1883 -t 'sensors/#' -u "$MQTT_USER" -P "$MQTT_PASS" -v
mosquitto_sub -h 10.0.0.6 -p 8883 --cafile /etc/telegraf/ca.pem -t 'sensors/#' -v

# Run only the mqtt_consumer input with debug
telegraf --config /etc/telegraf/telegraf.conf --test --input-filter mqtt_consumer --debug

# Watch MQTT connection errors live
journalctl -u telegraf -f | grep -i mqtt

Related Guides

• Telegraf [inputs.http] connection refused
• Telegraf [inputs.snmp] request timeout
• Telegraf output context deadline exceeded

More fixes in the Telegraf guides.

Conclusion

[inputs.mqtt_consumer] dial tcp ...: connection refused means nothing accepted the TCP connection on the broker host and port — usually a stopped broker, a wrong port, or a tcp:// scheme aimed at a TLS-only listener. Confirm the listener with nc and mosquitto_sub from the exact Telegraf host, then align servers scheme/port, tls_ca, and credentials with the broker. Give each consumer a unique client_id, and MQTT metrics will flow reliably again.