[BUG] Claude Code fails with ESERVFAIL on HPC systems with DNS infrastructure issues

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/71699
2. https://github.com/anthropics/claude-code/issues/71824

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Hitting this on an HPC login node (Rocky/RHEL-family, glibc). Same getaddrinfo ESERVFAIL on both downloads.claude.ai (install) and api.anthropic.com (runtime).

Root cause (in my case)

Not an IP block. The site's primary nameserver is intermittently failing to resolve Anthropic domains, and glibc queries it first and doesn't reliably fail over to the secondaries. So resolution is a coin flip — sometimes it works, sometimes ESERVFAIL.

The secondaries resolve fine every time:

$ dig +short downloads.claude.ai @<primary>
# (empty / SERVFAIL)
$ dig +short downloads.claude.ai @<secondary>
35.190.46.17
$ dig +short api.anthropic.com @<secondary>
160.79.104.10

/etc/resolv.conf was byte-identical to a colleague whose install worked, which is what pointed to intermittent primary + failover behaviour rather than config.

What did NOT work

curl -fsSL https://claude.ai/install.sh | bash — the script's internal curl calls use the system resolver, so pinning DNS on the outer pipe doesn't propagate.
--resolve downloads.claude.ai:443:<IP> on the outer curl — same reason; child calls ignore it.
claude install --force — the native binary does its own version fetch against downloads.claude.ai at install time; --force does not skip it, so it still ESERVFAILs.

What worked (root-free)

1. Manual download, pinning every request to a working resolver's IP:

bashBASE="https://downloads.claude.ai/claude-code-releases"
DIR="$HOME/.claude/downloads"; mkdir -p "$DIR"
IP=$(dig +short downloads.claude.ai @<secondary> A | grep -E '^[0-9]' | head -1)
R="--resolve downloads.claude.ai:443:$IP"
arch=x64 # or arm64
platform="linux-$arch" # add -musl if on musl
V=$(curl -fsSL $R "$BASE/latest")
BIN="$DIR/claude-$V-$platform"
curl -fsSL $R -o "$BIN" "$BASE/$V/$platform/claude"

verify against $BASE/$V/manifest.json checksum, then:

chmod +x "$BIN"

1. Skip claude install — the binary is self-contained. Just put it on PATH and disable the auto-updater so it stops re-fetching downloads.claude.ai on startup:

bashmkdir -p ~/.local/bin
cp "$BIN" ~/.local/bin/claude && chmod +x ~/.local/bin/claude
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
echo 'export DISABLE_AUTOUPDATER=1' >> ~/.bashrc

1. For reliable runtime DNS, launch inside a private mount namespace with a fixed resolv.conf pointing at the good secondaries (no root):

bashprintf 'nameserver <secondary1>\nnameserver <secondary2>\n' > ~/.claude-resolv.conf
unshare --mount --map-root-user bash -c \
'mount --bind "$HOME/.claude-resolv.conf" /etc/resolv.conf; exec claude "$@"' bash "$@"

(Requires unprivileged user namespaces to be enabled; some clusters disable them.)

Suggestions

Two things would make this much less painful for locked-down / HPC environments:

Have claude install (and the startup update check) honor a standard proxy/DNS override, or at least degrade gracefully when downloads.claude.ai is unreachable but api.anthropic.com is fine — right now a flaky downloads resolver blocks install entirely even though the binary only needs the API host to actually run.
Document an offline/air-gapped install path (download binary + manifest checksum, drop on PATH, DISABLE_AUTOUPDATER=1) — that's effectively what worked here.

Thanks for the detailed investigation and workaround.

One possible improvement might be to make the installer more resilient when downloads.claude.ai cannot be resolved but api.anthropic.com is still reachable. Instead of immediately failing with ESERVFAIL, the installer could:

• Retry DNS resolution using the system resolver before exiting.
• Gracefully continue when an existing valid Claude binary is already available.
• Provide a clearer error message indicating that the failure is DNS resolution rather than a network connectivity issue.
• Link to an official offline/manual installation procedure for environments such as HPC clusters or air-gapped systems.

This could improve the installation experience on institutional and enterprise Linux environments where intermittent DNS issues are outside the user's control.

Reproduced this outside HPC, on a plain home network — so this isn't specific to institutional DNS infrastructure.

Environment

• Claude Code 2.1.197 (extends the affected range beyond 2.1.191/2.1.196)
• Ubuntu LXC container on Proxmox VE
• DNS: a single consumer router (192.168.1.1) in /etc/resolv.conf — the PVE default of inheriting host DNS

Symptom
claude login fails immediately with:

OAuth error: getaddrinfo ESERVFAIL platform.claude.com

So this affects the OAuth login flow too, not just the installer.

Why diagnostics look healthy while the CLI fails
The router SERVFAILs intermittently. Every manual check passed — nslookup, curl, and even getent ahosts platform.claude.com (which uses glibc getaddrinfo, the same path Node goes through) — because those paths retry or a subsequent attempt succeeds. Claude Code appears to exit on the first SERVFAIL with no retry, and with a single configured nameserver there is no fallback at all, so the failure is hard while everything around it looks fine.

Workaround (consistent with what others found: only the first nameserver matters)
Put a public resolver first, keep the local one as backup:

pct set <ctid> --nameserver "1.1.1.1 192.168.1.1"

(or the equivalent resolv.conf edit). Login works reliably since.

A single retry on SERVFAIL — or falling back to the next configured nameserver like the rest of the system stack does — would make this class of failure disappear on both consumer and institutional networks.