Claude Code Network, Proxy and TLS Certificate Errors (Unable to connect): Causes and Fixes

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

Unable to connect to API. Check your internet connection
Unable to connect to API (ECONNREFUSED)
Unable to connect to API: SSL certificate verification failed.
  Check your proxy or corporate SSL certificates
fetch failed

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 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. 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. Also, if you use MCP servers, you must explicitly set HTTPS_PROXY and NODE_EXTRA_CA_CERTS in each server's env (they are not inherited from the parent). These variables can also go in the env block of settings.json.

3. 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.

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.

4. Firewall allowlist domains

If your firewall restricts destinations, allow these domains over HTTPS (443) (per the official network requirements).

Telemetry (statsig.anthropic.com) and error reporting (*.sentry.io) are optional and can be disabled (no need to include them in the required allowlist). If you self-manage installs via npm, you may not need downloads.claude.ai. The exact domains and IP ranges can be revised, so confirm the latest on the official network-config page.

5. The diagnostic workflow

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

6. 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.

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. 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 and platform.claude.com (auth), downloads.claude.ai (installer/updates), and raw.githubusercontent.com. Telemetry (statsig) and error reporting (sentry) 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.