Claude Code "Unable to connect to API": proxies and fixes

Claude Code prints "Unable to connect to API" when its connection to the address it sends requests to fails or never completes. Anthropic's error reference says the cause is usually your own network, proxy or firewall. Run curl -I https://api.anthropic.com from the same shell to find out which half you're dealing with. No answer? Then it's your network, VPN or proxy. If it answers, look for a leftover ANTHROPIC_BASE_URL, then for DNS, VPN or Docker leftovers on the machine.

The messages, variables and fixes on this page are from Anthropic's error reference and network configuration pages as they read on 24 October 2026. When status.claude.com shows an incident, the trouble is on Anthropic's side, and what to do when Claude Code is down fits better.

What each "Unable to connect to API" message means#

Since v2.1.227 the message spells out the kind of failure, with the code in brackets; older versions print just Unable to connect to API (ECONNREFUSED) and so on. Don't expect the bracketed code to match the table every time: Connection refused can arrive with ECONNREFUSED, and Can't reach the API server with FailedToOpenSocket.

A dropped connection doesn't reach you on the first try. Claude Code retries it up to 10 times with exponential backoff, with Retrying in Ns · attempt x/y on the spinner, and shows the message only after that. Certificate failures skip the retries and show on the first attempt, so you can start on the certificate setup straight away.

How to fix it, in order#

1. Test the API from the same shell with curl -I https://api.anthropic.com. Any HTTP answer counts, even an error status: the network gets through. (In Windows PowerShell type curl.exe, since plain curl there is an alias for Invoke-WebRequest.)
2. If curl fails, fix the route. The usual causes, per Anthropic: no internet, a VPN that blocks api.anthropic.com, or a company proxy you haven't configured (next section). A firewall has to allow the hosts on Anthropic's network access list, api.anthropic.com first. A dev container running Anthropic's reference firewall keeps its own list in the script, and the host must be on that one too (Claude Code in a dev container).
3. If curl works, check ANTHROPIC_BASE_URL. Is it set? echo $ANTHROPIC_BASE_URL answers for your shell (echo $env:ANTHROPIC_BASE_URL in PowerShell), and the env block of your Claude Code settings files can hold it too. While it's set, Claude Code sends model requests there, not to Anthropic. A leftover from a gateway or local proxy you've since stopped gives Connection refused while curl works fine. Remove it from your shell profile or settings, then open a new terminal (Claude Code reads its environment once, at startup). Other variables that change where requests go are in the environment variables guide.
4. If you use a gateway on purpose and every request ends in Connection dropped, the gateway may be rejecting the tool search fields Claude Code sends. Anthropic's test for that is ENABLE_TOOL_SEARCH=false, then one more try.
5. Look for leftovers on the machine.
   • Linux and WSL: a nameserver in /etc/resolv.conf that doesn't answer. WSL can inherit a broken one from Windows.
   • macOS: utun interfaces left by a VPN you disconnected or uninstalled, which ifconfig lists. Remove that VPN's network extension in System Settings.
   • Any system with Docker Desktop running: Docker can intercept outbound traffic. Quit it and try Claude Code again.

Behind a corporate proxy: HTTPS_PROXY#

Claude Code reads the standard proxy variables at startup, so export them first:

export HTTPS_PROXY=http://proxy.example.com:8080
export NO_PROXY="localhost,.example.com"

Lowercase works too, and if you've set several, Claude Code picks the first of https_proxy, HTTPS_PROXY, http_proxy, HTTP_PROXY, in that order. Proxy passwords go in the URL itself (http://user:password@proxy.example.com:8080). SOCKS proxies aren't supported, and for proxies that need NTLM or Kerberos Anthropic points you at an LLM gateway.

Write the scheme. The proxy URL is the one network setting Claude Code checks at launch, and a value it can't parse, such as one without http://, stops it with an error naming the variable. A wrong proxy address or certificate path shows up only later, as a connection error. The Proxy row in /status shows what was loaded.

Background agents (--bg, claude agents) need the variables in ~/.claude/settings.json, not in your shell:

{
  "env": {
    "HTTPS_PROXY": "http://proxy.example.com:8080",
    "NODE_EXTRA_CA_CERTS": "/path/to/ca-bundle.pem"
  }
}

The reason is the shared supervisor process that hosts those sessions. It keeps the environment of whichever shell started it first, so an export in a later shell reaches them only some of the time.

"Self-signed certificate in certificate chain": NODE_EXTRA_CA_CERTS#

You'll see this behind a proxy or security appliance that opens TLS traffic and re-signs it with its own certificate, one Claude Code doesn't trust. The message is SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT_LOCALLY) or Self-signed certificate detected (SELF_SIGNED_CERT_IN_CHAIN); during /login and the first-run check it's SSL certificate error (...).

Out of the box, Claude Code trusts two sets of certificates: its bundled Mozilla ones and your operating system's store. The native installer can always read the system store; an npm install needs Node 22.15 or later for that. So if IT has put the company root in your system store, a native install works with nothing set. Otherwise export the company CA bundle and point Claude Code at it:

export NODE_EXTRA_CA_CERTS=/path/to/ca-bundle.pem

The Additional CA cert(s) row in /status is no proof that it loaded: it shows the path either way. claude --debug is. Its log under ~/.claude/debug/ should have a line beginning CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS.

Don't reach for NODE_TLS_REJECT_UNAUTHORIZED=0. Anthropic says plainly not to set it, because it switches certificate checking off altogether.

"Unable to connect to Anthropic services" during setup#

This one shows up on first run, before the sign-in step. Claude Code checks that it can reach api.anthropic.com and platform.claude.com, gives each check 10 seconds, and exits if either fails. Is a proxy involved? Then the message names its variable, as in A proxy is configured via HTTPS_PROXY, and whoever runs that proxy has to allow HTTPS to the host in the message. After that, work through the checks above.

Network open and it still fails? Anthropic's suggestion is that Claude Code may not be available in your country. Its Supported Regions Policy lists where Anthropic offers Claude, and it covers use by people physically located in an unsupported region. A VPN doesn't change where you are. It isn't a fix for this, and we won't suggest one.

"Connection lost mid-response": type continue#

Sometimes the connection drops after Claude has already finished a block of text or a tool call. Claude Code then doesn't resend the request, because that could run the same tool calls twice. It keeps the finished part and ends with a line such as API Error: Connection lost mid-response. The response above may be incomplete. A proxy that closes the response early leaves the same line. Reply continue, and Claude picks up from its last completed block. (Codex prints its own version of this, stream disconnected before completion, with different fixes.)

The response stopped arriving means the connection stayed open, nothing came through, and a watchdog closed it. API Error: No response from API is what you get from a proxy that holds every response back until it's complete; Anthropic's advice for that one is a higher API_TIMEOUT_MS (default 600000 milliseconds, ten minutes), so the retry waits longer. If they keep coming, go back to the network checks above. Capacity errors such as 529 overloaded are Anthropic's side, not your connection, and need a different fix.

How Shuriken handles it#

Shuriken runs Claude Code on your own computers and servers, so requests leave from that machine's network and the fixes above apply there too.

• An ANTHROPIC_BASE_URL in Shuriken's own environment doesn't reach Claude Code. Shuriken strips it, so a gateway you exported in your profile won't reroute a chat whose source didn't ask for one.
• Network gone mid-chat? The chat waits, then carries on; it doesn't end.
• A chat on a server uses that server's connection, not your laptop's. Services start with none of your shell's variables, which is why the server installer (Settings › Devices › Add device › A server) writes the proxy into the service's environment itself. It takes the proxy from --proxy, or from HTTPS_PROXY, HTTP_PROXY and NO_PROXY in the shell you run it in (and --proxy none removes a saved one).

The server page has the rest, and you can download Shuriken to try it.