n8n in Docker: getaddrinfo EAI_AGAIN on an HTTP request?

An HTTP Request node fails with getaddrinfo EAI_AGAIN, although the service appears reachable from the host or browser. The failure occurs during name resolution. A test outside the n8n container may therefore examine a different configuration from the affected workflow.

What the reported case shows

A historical report from 2021 concerns a local service name in Docker. Replacing it with an IP address produced a connection error on another port; the replacement did not establish a complete fix. Q1 Docker documents different DNS arrangements for default and user-defined networks. Node.js also distinguishes operating-system name lookup from direct DNS queries. Q2 Q3

This guide addresses a diagnostic category, not a claimed current n8n DNS defect. The hostname, network and resolver actually used by the failing process matter.

Narrow down the failure

1. Preserve the actual hostname. Inspect the URL after expression evaluation, including spelling, scheme, port and local name suffixes. A name known to your workstation need not exist in a container.
2. Test in the affected context. Ask the administrator to check resolution from the n8n container or an equivalently configured diagnostic environment. Compare several timestamped attempts with host-side results to distinguish a persistent configuration issue from an intermittent failure.
3. Identify the destination type. Is it a public hostname, a private company name or another container service? A Docker service needs a suitable shared network and the name valid on that network. A public resolver does not automatically know private zones.
4. Observe resolver and network configuration. Compare container DNS settings, network membership and reachability of the intended resolver. Do not change DNS globally before establishing which private namespaces must remain available.
5. Test connectivity afterwards. Once resolution succeeds, check the intended service port. ECONNREFUSED, TLS failures and HTTP status codes are new findings at a different layer and require different investigations.

Choose a correction supported by the result

Correct an invalid service name, add a specifically required network path, or ask the operator to repair a demonstrated resolver outage. Hard-coding a changing container IP is generally not a durable answer. For HTTPS, substituting an IP can also interfere with the intended hostname relationship.

After correction, repeat the same name-resolution checks and one harmless request using the original intended hostname. Keep the before-and-after results so that a later container recreation can be assessed against the same evidence.

Frequently asked questions

Will an immediate retry help?

It may help with a transient failure, but does not explain its cause. Limit attempts and consider the effects of the entire workflow.

What information is useful?

Provide n8n and Docker versions, anonymised URL with port, a narrow network diagram, timestamps and resolution results from inside and outside the container. Do not publish credentials or a full internal network inventory.

Help with this case

We can help isolate the affected process and prepare a controlled next step. Discuss case A0176 with KAN KAI WORKS.