🚨 Telegraf Error Guide: '[inputs.http] ... connection refused' — Fix HTTP Endpoint Collection

Overview

The http input fetches a URL each interval and parses the response into metrics. When nothing is listening on the target host and port, the underlying Go HTTP client returns a connection-refused error that Telegraf logs verbatim:

2026-07-10T12:00:00Z E! [inputs.http] Error in plugin: Get "http://127.0.0.1:9273/metrics": dial tcp 127.0.0.1:9273: connect: connection refused

Related failure modes for the same input include DNS resolution errors and timeouts against a host that accepts the connection but never answers:

E! [inputs.http] Error in plugin: Get "http://api.internal:8080/stats": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Metrics from that endpoint are absent on every interval until the connection succeeds.

Symptoms

• Metrics from a specific HTTP endpoint are missing while other inputs report normally.
• journalctl -u telegraf repeats connect: connection refused or context deadline exceeded for the URL.
• curl to the same URL from a different host works but fails from the Telegraf host, or vice versa.
• The endpoint listens on 127.0.0.1 but Telegraf runs on a different host or in a container.
• Switching between http:// and https:// changes the error.

Common Root Causes

• Nothing listening on the port — the target service is down, crashed, or never started.
• Bound to localhost only — the service listens on 127.0.0.1 but Telegraf connects from another host/container, so the connection is refused.
• Wrong port or path — a typo, or the metrics endpoint moved (e.g. /metrics vs /actuator/prometheus).
• Firewall / security group blocking the port — the packet is dropped or rejected before reaching the service.
• TLS scheme mismatch — using http:// against an HTTPS-only listener (or the reverse), causing refusal or handshake errors.
• DNS resolution failure — the hostname does not resolve from the Telegraf host.
• Timeout too short — a slow endpoint exceeds the input timeout, surfacing as context deadline exceeded.

Diagnostic Workflow

Reproduce the exact request from the Telegraf host with curl. If curl is refused, the problem is the endpoint or network, not Telegraf:

curl -v --max-time 5 http://127.0.0.1:9273/metrics

Confirm something is actually listening on the port and on which address:

sudo ss -ltnp | grep 9273        # is anything bound? on 127.0.0.1 or 0.0.0.0?

From a remote Telegraf host, verify reachability through any firewall:

nc -z -v api.internal 8080
getent hosts api.internal        # DNS resolves?

Run only the http input under Telegraf with debug to see the request and parsed result:

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

A correct http input config with an explicit timeout and matching parser:

[[inputs.http]]
  urls = ["http://127.0.0.1:9273/metrics"]
  method = "GET"
  timeout = "5s"
  data_format = "prometheus"
  # For JSON APIs use json_v2 instead:
  # data_format = "json_v2"

If the service binds to localhost and Telegraf is remote, either reconfigure the service to bind 0.0.0.0 or run Telegraf locally on that host.

Example Root Cause Analysis

A team ran Telegraf in a container to scrape an app’s Prometheus endpoint and saw endless dial tcp 127.0.0.1:9273: connect: connection refused. The config used urls = ["http://127.0.0.1:9273/metrics"]. From inside the container, curl http://127.0.0.1:9273/metrics was refused, but from the host it succeeded.

The cause was the container network namespace: inside the Telegraf container, 127.0.0.1 refers to the container itself, not the host where the app listened. There was nothing on port 9273 inside the container, so the connection was refused. The fix was to target the app over the shared network rather than loopback — using the Docker host gateway address:

[[inputs.http]]
  urls = ["http://host.docker.internal:9273/metrics"]
  timeout = "5s"
  data_format = "prometheus"

With --add-host=host.docker.internal:host-gateway on the container, the scrape succeeded and Prometheus metrics appeared. The lesson: 127.0.0.1 is namespace-local — in a container it never means the host, so target endpoints by a routable address, not loopback.

Prevention Best Practices

• Reproduce every new endpoint with curl from the exact Telegraf host (or container) before deploying the config.
• Never point a remote or containerized Telegraf at 127.0.0.1; use a routable hostname or the host-gateway address.
• Confirm the service binds a reachable address (0.0.0.0 or the interface IP) with ss -ltnp, not localhost only.
• Match the URL scheme to the listener (https:// for TLS) and set insecure_skip_verify only for known self-signed dev endpoints.
• Set a timeout slightly above the endpoint’s worst-case response time to avoid false context deadline exceeded errors.
• Monitor the http input for gaps and alert when a scrape target has produced no data for several intervals.

Quick Command Reference

# Reproduce the exact request from the Telegraf host
curl -v --max-time 5 http://127.0.0.1:9273/metrics

# See what is listening and on which address
sudo ss -ltnp | grep 9273

# Test reachability and DNS from a remote Telegraf host
nc -z -v api.internal 8080
getent hosts api.internal

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

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

Conclusion

[inputs.http] ... connection refused means Telegraf reached the host but nothing accepted the connection on that port — usually a service that is down, bound to localhost, on the wrong port, or unreachable across a container boundary or firewall. Reproduce with curl from the exact Telegraf host, confirm the listener with ss -ltnp, and target endpoints by a routable address rather than loopback. Match the TLS scheme and set a realistic timeout, and HTTP metrics collect cleanly.