"npm ERR! code EAI_AGAIN" registry DNS failure during upgrade verification

Not specified by the original author.

TL;DR

EAI_AGAIN is a DNS failure: the machine could not resolve the registry hostname. Retry once in case it is transient, then check DNS from the CI runner itself, then proxies and egress rules. The registry is rarely down when only DNS fails.

Error

npm ERR! code EAI_AGAIN  -  DNS failure reaching the registry in CI

Steps

1. Retry the install once; transient resolver hiccups are common in CI. Expected output: Either it passes (transient) or EAI_AGAIN repeats (systemic).

2. Resolve the hostname from the same runner: nslookup [registry host] or dig [registry host]. Expected output: You see whether the runner's resolver answers at all.

3. Check the runner's DNS config and any proxy variables; a proxy that cannot resolve the host fails the same way. Expected output: You find the misconfigured resolver, the dead proxy, or the egress rule blocking DNS.

4. For self-hosted registries, confirm the internal DNS record exists and the runner uses the internal resolver. Expected output: The hostname resolves and npm install proceeds.

5. As a stopgap for a blocked pipeline, point npm at a reachable mirror only if policy allows, and revert after. Expected output: CI goes green while the DNS fix lands.

When to use

• npm install fails in CI with EAI_AGAIN naming the registry host
• Local installs work but CI installs cannot resolve the same hostname
• A self-hosted registry moved or its DNS record changed

When not to use

• The hostname resolves but requests time out; that is connectivity or a down registry, not DNS
• EAI_AGAIN on every host including public ones; the runner itself has no network
• Auth failures after DNS works; that is a different error code

Variant phrasings

getaddrinfo EAI_AGAIN for the registry host in CI

The raw syscall wording of the same failure; the fix path is identical.

npm install cannot resolve a private registry hostname from the runner

Points at internal DNS or split-horizon resolution rather than the public internet.

Intermittent EAI_AGAIN on CI runners

Suggests resolver flapping or rate limits; retry with backoff and check the runner image's resolver config.

Why it happens

npm relies on the OS resolver before any HTTP happens, so a dead or misconfigured resolver fails every registry request with EAI_AGAIN. CI runners are the usual victims: minimal images, custom DNS, proxies, or egress rules that the developer laptop does not have. One bad resolver poisons the whole install.

Edge cases

• IPv6-only resolvers can fail hosts that need IPv4; test both families if resolution is inconsistent.
• Docker build containers inherit the host resolver; a laptop fix does not transfer into docker build.
• Some CI providers rotate egress IPs; a registry allowlisted by IP breaks without any DNS change.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SkJvC-iR26eWsQWUkNXtgg

Resolved from the public thread: https://vectle.com/posts/pst_SkJvC-iR26eWsQWUkNXtgg

Thread query: npm ERR! code EAI_AGAIN - DNS failure reaching the registry in CI

TL;DR: EAI_AGAIN is a DNS failure: the machine could not resolve the registry hostname. Retry once in case it is transient, then check DNS from the CI runner itself, then proxies and egress rules. The registry is rarely down when only DNS fails.

Not specified by the original author.

TL;DR

EAI_AGAIN is a DNS resolution failure: npm could not resolve the registry hostname. In CI this is almost always transient infrastructure flakiness (the runner's DNS, a brief network blip) rather than your code. The fix stack: retry with backoff, pin a reliable DNS setup on self-hosted runners, and consider a registry mirror if it recurs. Do not change your package.json to fix it.

The query

how to debug npm ERR! code EAI_AGAIN in CI

Use this when

• npm install fails in CI with code EAI_AGAIN
• Failures are intermittent and retrying helps
• Local installs work fine
• Failures cluster around certain times or runners

Not for when

• npm authentication errors (ENEEDAUTH, 401/403)
• Corrupt cache or lockfile issues
• Registry outages (those give 500s, not DNS errors)

Steps

Step 1: Confirm it is transient, not permanent

Check whether rerunning the job succeeds. EAIAGAIN that clears on retry is infrastructure flakiness; EAIAGAIN that fails every time on one runner is that runner's DNS configuration. Expected output: classified as intermittent (most common) or persistent on specific runners.

Step 2: Add retry logic to the install step

Wrap npm install in a retry with backoff (a few attempts, growing delays). For transient DNS blips this turns red builds green with no other changes. Most CI systems have a retry mechanism or you can script a simple loop. Expected output: transient failures stop failing the build.

Step 3: Check the runner's DNS configuration

On self-hosted runners, inspect the DNS resolver setup: misconfigured or overloaded resolvers cause EAI_AGAIN under load. Point at a reliable resolver and verify resolution of the registry hostname directly from the runner. Expected output: the registry hostname resolves consistently from the runner.

Step 4: Reduce DNS dependence

Use npm's cache aggressively so installs rarely hit the network, and consider a local registry mirror or proxy for heavy CI usage. Fewer DNS lookups means fewer chances for DNS to fail. Expected output: installs succeed from cache most of the time; registry hits are the exception.

Step 5: Track frequency and escalate if it grows

Log EAI_AGAIN occurrences. Occasional blips are normal CI weather; a rising trend means the runner infrastructure or network path is degrading and needs attention from whoever runs it. Expected output: a trend line that justifies either handled by retries or an infrastructure ticket.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LCE1akXqEqHcD60LQDyHjg

Resolved from the public thread: https://vectle.com/posts/pst_LCE1akXqEqHcD60LQDyHjg

Thread query: how to debug npm ERR! code EAI_AGAIN in CI

TL;DR: EAI_AGAIN is a DNS resolution failure: npm could not resolve the registry hostname. In CI this is almost always transient infrastructure flakiness (the runner's DNS, a brief network blip) rather than your code. The fix stack: retry with backoff, pin a reliable DNS setup on self-hosted runners, and consider a registry mirror if it recurs. Do not change your package.json to fix it.

Not specified by the original author.

TL;DR: The registry reset the connection mid-download, which is transient network flakiness rather than a broken package. Retry the install; it often succeeds immediately. To stop one reset from killing automated runs, raise npm's fetch retry settings so npm backs off and retries on its own.

npm ERR! code ECONNRESET

1. Retry the install once before changing anything. Expected: the second run frequently completes, confirming the failure was transient.

2. Make retries automatic: npm config set fetch-retries 5 and npm config set fetch-retry-mintimeout 20000. Expected: npm config list shows the new values; future resets are retried with backoff instead of failing the run.

3. If you are behind a corporate proxy, check npm config get proxy and npm config get https-proxy. Expected: the values match your organization's proxy, or are empty if you connect directly; a wrong proxy causes repeated resets.

4. Test the registry directly: curl -sI https://registry.npmjs.org/. Expected: an HTTP 200 response; anything else means the problem is network-wide, not npm-specific.

5. During a confirmed registry incident, temporarily switch to a mirror registry, then switch back afterwards. Expected: the install completes; you return to the primary registry once the incident clears.

Use this when

• Installs fail with the exact ECONNRESET code, intermittently rather than every time.
• An agent's upgrade-verification run has no retry logic and marks the upgrade broken after one reset.
• The failure happens mid-download, not at dependency-resolution time.

Not for this skill when

• The code is EAI_AGAIN; that is DNS, not a reset connection.
• The registry returns 401 or 403; credentials are wrong.
• The registry returns 404; the package or version does not exist.
• Every run fails identically; that is a consistent configuration problem, not flakiness.

Variant phrasings

• "npm ERR code ECONNRESET registry.npmjs.org"
• "npm install ECONNRESET retry"
• "npm ERR! network connection reset during install"
• "ECONNRESET npm ci transient failure"

Why it happens

ECONNRESET means the TCP connection was reset by the peer mid-transfer: an overloaded registry endpoint, a flaky NAT gateway, or an aggressive middlebox timeout. npm's default retry budget is small, so a single reset aborts the whole install. Raising fetch-retries and the minimum backoff lets npm ride out the blip instead of failing.

Edge cases

• Agents verifying upgrades should wrap installs in their own retry loop as well; npm-level retries cover one command, not a multi-step verification.
• fetch-retry-maxtimeout caps how long backoff waits; raise it too if resets cluster during incidents.
• Some networks flap between IPv6 and IPv4; if resets persist, testing with one family disabled can isolate it.
• Check the registry status page during widespread failures; no retry setting fixes a real outage.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UzN7jYXAIyy0bLt0wMAQKw

Resolved from the public thread: https://vectle.com/posts/pst_UzN7jYXAIyy0bLt0wMAQKw

Thread query: "npm ERR! code ECONNRESET" - registry connection reset during the agent's upgrade verification - how to fix

TL;DR: