Claude Code "Can't reach the API server" / "Connection refused": Causes and Fixes for Network, Proxy and TLS Errors (Unable to connect)

Trying to use Claude Code on a corporate machine or over VPN, and it won't connect with errors like these?

# What you see now (examples)
Can't reach the API server — check your internet or DNS (ENOTFOUND)
Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)
Unable to connect to API. Check your internet connection
Unable to connect to Anthropic services
fetch failed

# What older versions showed
Unable to connect to API (ECONNREFUSED)
Unable to connect to API: SSL certificate verification failed.
  Check your proxy or corporate SSL certificates

The wording depends on your version. Since v2.1.227, messages that used to just append a code, like Unable to connect to API (ECONNREFUSED), lead with the kind of failure instead, like Connection refused — or Can't reach the API server — (mapping table in §2). Whichever wording you see, what is happening and how to fix it are the same.

These are network errors meaning "Claude Code cannot reach Anthropic's server (api.anthropic.com)." They are not authentication (401/403), not server overload (529/500), and not a rate limit (429) — the request never reached the server at all. The usual causes are corporate proxies, TLS inspection (certificates), and firewalls, which makes this especially common on enterprise networks. This article covers proxy setup, corporate CA certs, the domains to allowlist, and the diagnostic steps — based on official information.

Key points up front. (1) Behind a proxy, set HTTPS_PROXY. (2) For a certificate error from TLS inspection (Zscaler, etc.), point NODE_EXTRA_CA_CERTS at the corporate CA — and never disable verification with NODE_TLS_REJECT_UNAUTHORIZED=0 (it exposes all traffic to interception). (3) Start by running curl -I https://api.anthropic.com to check "can it even reach?" — that is the root of triage.

1. What this error is telling you

Unable to connect to API, fetch failed, ECONNREFUSED / ETIMEDOUT (since v2.1.227, worded like Connection refused —; see §2) mean "the request did not reach Anthropic's server" = it failed somewhere in TCP/TLS/DNS. This is the decisive difference from other errors: auth (401/403), server (529/500), and rate (429) are responses after reaching the server, whereas network errors mean it never got there.

On enterprise networks, the typical blockers split into three layers. (1) Proxy — you can't go out directly and must route through a corporate proxy that isn't configured. (2) TLS inspection (certificates) — an inspection proxy like Zscaler replaces certs, so you must trust the corporate root CA. (3) Firewall — required domains aren't allowed. The first thing to do is confirm "can it reach?" with curl -I https://api.anthropic.com — this single check separates "a network problem" from "everything else."

2. What each message means (wording since v2.1.227)

According to the official error reference, messages in this family mean the TCP connection to the API failed or never completed. For the common error codes, the message names the kind of failure and keeps the code in parentheses. This is what you see now:

Unable to connect to API. Check your internet connection
Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)
Can't reach the API server — check your internet or DNS (ENOTFOUND)
No internet route — check your connection or VPN (EHOSTUNREACH)
Couldn't connect through your proxy (ERR_PROXY_TUNNEL) — the proxy refused the tunnel: check its credentials and that it allows this host
Connection dropped (ECONNRESET)
fetch failed
Request timed out. Check your internet connection and proxy settings

Before v2.1.227, each of these coded messages read Unable to connect to API followed by the code (for example, Unable to connect to API (ECONNREFUSED)). A code Claude Code doesn't recognize still appears in that form. The same message can also carry different codes: Connection refused can show ConnectionRefused or ECONNREFUSED, and Can't reach the API server can show ENOTFOUND or FailedToOpenSocket.

Whichever message you see, transient failures are retried automatically, so by the time it appears on screen the retries are already spent. If it keeps coming back, the cause is in your local network. The official reference lists common causes such as no internet access, a VPN that blocks api.anthropic.com, or a required corporate proxy that isn't configured. The fixes are in §3–§6.

Unable to connect to Anthropic services (first-run setup)

During first-run setup, before showing the sign-in step, Claude Code checks that it can reach api.anthropic.com and platform.claude.com. If either check fails, it prints the reason and exits. The official example:

Unable to connect to Anthropic services
Failed to connect to api.anthropic.com: ECONNREFUSED
Connection to api.anthropic.com timed out after 10 seconds
A proxy is configured via HTTPS_PROXY. Check that it allows connections to the host above.

The check goes through the same proxy configuration as API requests and gives each probe 10 seconds. When the failed probe went through a proxy, the message names the environment variable that configured it (such as HTTPS_PROXY). What to do:

• Check that the named variable points at the right proxy, and ask your network team to allow HTTPS connections through it to the host in the message (allowlist in §5)
• Run the curl reachability check from §6 in the same shell
• If it stalls on Checking connectivity... behind a proxy URL starting with https://, you may be hitting a bug from before v2.1.222 (the check took a different path from API requests and had no timeout). Update
• If your organization signs in through a cloud gateway (Claude apps gateway) and this error appears on first run, update to v2.1.247 or later

If your network is open and the failure persists, the official reference notes that Claude Code may not be available in your country or region. Check the list of supported countries and regions.

Streaming response ended before any complete data was received

Streaming response ended before any complete data was received. Retrying without streaming. If this keeps happening, check any proxy or gateway between Claude Code and your model provider.

This warning means not "it never arrived" but "something in between altered the response." A streaming response from your model provider completed without delivering any usable data, so Claude Code re-sent the request without streaming to finish the turn. Each affected request is sent twice: the empty streaming attempt and the retry. Per the official reference, the usual cause is a proxy or gateway that consumes or transforms the streaming response body on its way back, and the fix is to configure any proxy or gateway between Claude Code and your model provider to pass streaming response bodies and their headers through unmodified. The warning appears once per session, in interactive sessions only. Before v2.1.239, Claude Code silently retried without streaming.

3. Proxy setup (HTTPS_PROXY)

When you must route through a corporate proxy, set the standard proxy environment variables. Claude Code respects them.

# Recommended: HTTPS proxy
export HTTPS_PROXY=http://proxy.example.com:8080
# If HTTPS isn't available, HTTP_PROXY
export HTTP_PROXY=http://proxy.example.com:8080
# Destinations that bypass the proxy (space- or comma-separated)
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

# Authenticating proxy (avoid hardcoding passwords)
export HTTPS_PROXY=http://username:password@proxy.example.com:8080

Caveats: SOCKS proxies are not supported. For NTLM / Kerberos proxies, the official recommendation is to stand up an LLM gateway in between and point ANTHROPIC_BASE_URL at it. These variables can also go in the env block of settings.json.

For setup, costs, and caveats when pointing ANTHROPIC_BASE_URL at a gateway for non-Claude models (DeepSeek, GLM, Kimi, and others), see How to use DeepSeek, GLM, and Kimi with Claude Code.

4. TLS and corporate CA certs (most important, safely)

The most common enterprise blocker is a certificate error caused by a TLS inspection proxy (Zscaler, Netskope, Palo Alto, etc.) replacing certificates. Typical messages are unable to get local issuer certificate and SELF_SIGNED_CERT_IN_CHAIN.

As of v2.1.273, Claude Code's own messages include the error code and the fix. During a session, API requests show:

Unable to connect to API: SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store · see https://code.claude.com/docs/en/network-config
Unable to connect to API: Self-signed certificate detected (SELF_SIGNED_CERT_IN_CHAIN). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store · see https://code.claude.com/docs/en/network-config

During /login and the startup connectivity check, the same failure produces a different message:

SSL certificate error (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). If you are behind a corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path, or ask IT to allowlist *.anthropic.com. Run `claude doctor` for details.

Before v2.1.273, both of the first two messages ended at Check your proxy or corporate SSL certificates, without the code or the NODE_EXTRA_CA_CERTS hint (the older output at the top of this article). Also, as of v2.1.199 a certificate validation failure isn't retried, so the error appears on the first attempt (earlier versions spent a few minutes retrying first). Transient TLS conditions such as a handshake timeout are still retried.

For context, recent Claude Code trusts BOTH its bundled CA set AND the OS trust store. So if the corporate root CA is in the OS certificate store, it often works with no extra config (behavior varies by version, so confirm the latest). If it's not in the OS store, point NODE_EXTRA_CA_CERTS at the CA bundle (PEM) you received from IT:

# The correct, secure way: trust the corporate CA
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem

# If the proxy requires a client certificate (mTLS)
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem

If you hit a certificate error at install time (before the binary exists), pass the CA to curl: curl --cacert /path/to/corporate-ca.pem -fsSL https://claude.ai/install.sh | bash.

OAuth error: SSL certificate error (CERT_HAS_EXPIRED)

Partway through sign-in (the OAuth step of /login), you may be stopped by the message below. This is the exact text users reported in GitHub issues:

OAuth error: SSL certificate error (CERT_HAS_EXPIRED). If you are behind a corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path, or ask IT to allowlist *.anthropic.com. Run /doctor for details.

This message is not in the official error reference. The official SSL certificate errors section only shows the codes UNABLE_TO_GET_ISSUER_CERT_LOCALLY and SELF_SIGNED_CERT_IN_CHAIN; an expired certificate is mentioned only in passing, as one example of a certificate validation failure in the section on automatic retries. The text above comes from users in GitHub issues #71708 and #71727 (both June 2026).

What CERT_HAS_EXPIRED means: it is one of the certificate error codes Node.js's TLS layer returns, and the Node.js documentation describes it as "Certificate has expired". In other words, the certificate received from the server was checked and judged to be past its expiry date. That expiry check is made against your own machine's clock.

What the reports say: the reporters in both issues wrote that they used no proxy or VPN and that curl reached the same host without trouble (the reporter of #71708 also checked that the clock was correct). So it also appears in setups the message's own hint (corporate proxy, TLS inspection) doesn't describe. The reporters suspected the runtime bundled with Claude Code, and several commenters said going back to an older version fixed it. But there is no reply from Anthropic in either issue, and both were closed after going inactive. The cause has not been officially confirmed. As of September 30, 2026, the official CHANGELOG has no entry that says it fixes this symptom either.

What to check, in order:

1. Your clock: are the date, time and time zone right? If the clock is far off, even a valid certificate can be judged expired.
2. Your company proxy's certificate: if your traffic passes through a TLS-inspecting proxy or security product, ask IT whether the certificate it inserts (including the corporate CA) has expired.
3. NODE_EXTRA_CA_CERTS: if you need to trust a corporate CA, point NODE_EXTRA_CA_CERTS at the CA bundle from IT, as the official network configuration page describes (the steps above). To confirm it loaded, look for the CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS line in the claude --debug log.
4. If it still appears: if your clock is right, there is no proxy, and curl -I https://platform.claude.com succeeds, you may be in the same situation as the GitHub reports. Update Claude Code, then check the issues and the changelog. One comment says NODE_TLS_REJECT_UNAUTHORIZED=0 got it working, but as the box above explains, that switches verification off entirely, so don't use it.

5. Firewall allowlist domains

If your firewall restricts destinations, allow these main domains over HTTPS (443) (per the official network requirements; if you use MCP connectors, plugins, and so on, you also need other hosts from the official list).

The operational telemetry and error-report hosts (http-intake.logs.us5.datadoghq.com and browser-intake-us5-datadoghq.com) are optional, and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC turns both off (no need to include them in the required allowlist). If you install via npm, you don't need the installer and auto-updater uses of downloads.claude.ai, but you do need the package registry registry.npmjs.org. The exact domains and IP ranges can be revised, so confirm the latest on the official network-config page.

6. The diagnostic workflow

When it won't connect, go top-down. The first curl sets the direction.

7. Telling it apart from similar errors

"It stopped" can be non-network too. The big split is "did it reach the server?"

A mnemonic: network errors mean "it never reached the server" (TCP/TLS/DNS), and HTTPS_PROXY or NODE_EXTRA_CA_CERTS only help at this layer. By contrast, 401/403, 529/500, and 429 are "responses after reaching", so tweaking the proxy or CA won't fix them. Whether curl succeeds is the single best tell that separates the two. For other common errors, see the error roundup.

Summary

Claude Code's network/proxy errors (Unable to connect / fetch failed / SSL certificate verification failed, etc.) mean the request never reached the server = a TCP/TLS/DNS failure. They are different from auth (401/403), server (529/500), and rate (429), and the usual culprits are the enterprise proxy, TLS inspection, and firewall. Since v2.1.227 they are worded to name the kind of failure first, like Connection refused — or Can't reach the API server —, and first-run setup exits with Unable to connect to Anthropic services.

The fixes: (1) behind a proxy, set HTTPS_PROXY (SOCKS unsupported; NTLM/Kerberos via a gateway), (2) for cert errors put the corporate CA in NODE_EXTRA_CA_CERTS — never NODE_TLS_REJECT_UNAUTHORIZED=0, (3) allowlist api.anthropic.com etc. in the firewall. Diagnose by first testing reachability with curl -I https://api.anthropic.com -> /doctor and proxy check -> cert/proxy settings -> a direct connection to confirm -> DNS/VPN/Docker. The key is to split network from auth/server/rate by "did it reach the server?" Related: auth / login errors, 529/500 errors, Claude Code error roundup.

FAQ

Q. On my company PC I get "Unable to connect to API" and can't connect.
A. Usually you must route through a corporate proxy that isn't configured. First check reachability with curl -I https://api.anthropic.com; if it fails, set a proxy like export HTTPS_PROXY=http://proxy.example.com:8080 (add user:password@ for an authenticating proxy). Note that SOCKS is unsupported, and for NTLM/Kerberos proxies the official recommendation is to go through an LLM gateway.

Q. Are "Can't reach the API server" and "Connection refused" different errors from the old "Unable to connect to API"?
A. They are the same family; only the wording changed in v2.1.227. It used to just append a code, like Unable to connect to API (ECONNREFUSED); now it names the kind of failure first, like Connection refused — a firewall or proxy may be blocking it (ConnectionRefused) or Can't reach the API server — check your internet or DNS (ENOTFOUND). The code in parentheses hints at the cause, so look up what to check in the table in §2.

Q. On first launch I get "Unable to connect to Anthropic services" and it exits.
A. It failed at the step that checks connectivity to api.anthropic.com and platform.claude.com before sign-in. If the message names a proxy variable (such as HTTPS_PROXY), confirm its value with your network team and check that connections to the host in the message are allowed. You can also check reachability with curl -I https://api.anthropic.com. If your network is open and it persists, the official reference notes that Claude Code may not be available in your country or region, which you can check against the official list of supported countries.

Q. I get "SSL certificate verification failed."
A. This is typically a corporate TLS inspection proxy (e.g., Zscaler) replacing certificates. Get the corporate root CA (PEM) from IT and set export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem. If the corporate CA is already in the OS certificate store, it may work with no config. Never disable verification with NODE_TLS_REJECT_UNAUTHORIZED=0 — that exposes all traffic to interception.

Q. Setting NODE_TLS_REJECT_UNAUTHORIZED=0 fixed it. Is that OK?
A. No — revert it now. It disables TLS certificate verification for the entire process, leaving all traffic — including to api.anthropic.com — defenseless against man-in-the-middle attacks (eavesdropping/tampering). That's a serious security risk that can leak credentials and source code. The only correct fix is to properly trust the corporate CA via NODE_EXTRA_CA_CERTS.

Q. Which domains should I allow in the firewall?
A. Over HTTPS (443), at minimum allow api.anthropic.com (API), claude.ai, claude.com, and platform.claude.com (auth), downloads.claude.ai (installer/updates), and raw.githubusercontent.com (changelog). Operational telemetry and error reporting (Datadog) are optional. The exact domains/IPs can be revised, so confirm the latest on the official network-config page.

Q. curl works, but only Claude Code won't connect.
A. The cause is often between Claude Code and the OS. Common cases: a WSL /etc/resolv.conf pointing at a dead DNS, stale VPN remnants (e.g., old macOS utun interfaces), or a resident tool like Docker intercepting traffic. Try a direct connection off VPN, stop resident tools, and review DNS, in that order. Note that transient 5xx errors are auto-retried up to 10 times, so if you see an error while curl succeeds, the retries are already spent.