Check status.claude.com first, because roughly one in five of these is an incident and nothing you do locally will help. If Anthropic is healthy, the message tells you which layer failed. "Unable to connect to Anthropic services" is the first-run setup check, which reaches api.anthropic.com and platform.claude.com before you have a session. "Can't reach Claude" with "Check your connection" is the browser, where a VPN, an extension, or blocked CDN hosts are the usual causes. "Unable to connect to API" is a running session, and the error code in the parentheses names the layer. The single most common enterprise cause is a TLS-inspecting proxy, fixed by pointing NODE_EXTRA_CA_CERTS at your organisation root certificate. The most confusing cause is broken IPv6, which curl survives and the client does not.
- Check status.claude.com before touching a setting. This is an incident often enough to be worth sixty seconds.
- The wording names the layer: setup check, browser, running session, or credential.
- Behind a TLS-inspecting proxy, set
NODE_EXTRA_CA_CERTSto your CA bundle. Certificate failures are never retried. curlworks and the CLI does not? Suspect broken IPv6. curl falls back to IPv4 and the client does not.- Allowlisting
claude.aibut not its CDN hosts gives you a blank page, not an error. - A VPN is the most common single cause on the browser side, per Anthropic support.
- Set proxy and certificate variables before launch. They are read once at startup.
Three different errors, one underlying question
These messages get searched interchangeably, and they come from three different places in the stack. Establishing which one you are looking at decides everything that follows, because the fix for a browser problem has nothing in common with the fix for a first-run setup check.
| You saw | It came from | Read |
|---|---|---|
Unable to connect to Anthropic services | The setup and login connectivity check, before a session exists | The setup check section |
Can't reach Claude with Check your connection | claude.ai in a browser, or the desktop app shell | The browser section |
Unable to connect to API, plus an error code | A running Claude Code session | The running-session section |
401, 403, or an organisation message | The credential. The network is fine. | The credential section |
Sixty seconds before you change anything
Every fix below is reversible except the time you spend on it. Four checks, in this order, and each one either ends the investigation or narrows it.
Check the status page
Open status.claude.com. Anthropic posts incidents affecting claude.ai, the Console, and the API separately, and the history shows repeated incidents where logins failed while the API stayed healthy. If there is an open incident matching your symptom, stop here: nothing local will help, and changes you make now are changes you will have to undo.
Prove the route from this machine
# does anything answer at all?
ping -c 3 8.8.8.8
# does the API host resolve, and to what?
nslookup api.anthropic.com
# does TLS complete end to end?
curl -sS -o /dev/null -w '%{http_code}\n' https://api.anthropic.com
# a 404 here is a SUCCESS: you reached the server and it declined the pathThat 404 confuses people every time. The root path is not a valid endpoint, so reaching it and being turned away proves the whole path works: DNS, routing, TLS, and the certificate chain. A timeout, a connection refused, or a certificate error at this step is the real answer.
Ask the CLI what it thinks
claude doctorIt reports install health, PATH, settings validity, and credential state without starting a session, which is exactly what you need when a session will not start. Inside a running session, /status shows the active credential and the proxy and certificate rows.
Change one variable, ideally the network
Tether to a phone. It is the fastest single test in this whole page, because it swaps DNS, routing, IPv6 behaviour, and any corporate middlebox all at once. If it works on a hotspot and not on your network, you are in the proxy or IPv6 sections and you can skip the rest.
Unable to connect to Anthropic services
This exact wording comes from the connectivity check that runs during setup and login, before you have a working session. It means the client could not reach Anthropic to download or verify what it needs.
Unable to connect to Anthropic servicesWhat that check reaches for matters, because it is a narrower set of hosts than a running session uses. The first-run setup check needs api.anthropic.com and platform.claude.com, and the binary download and verification path adds Anthropic download hosts. A firewall that allows the API but blocks the download host produces this message on a machine whose network is otherwise fine.
| Cause | Tell | Fix |
|---|---|---|
| TLS-inspecting corporate proxy | A certificate error alongside it, often UNABLE_TO_GET_ISSUER_CERT_LOCALLY | Set NODE_EXTRA_CA_CERTS. See the proxy section. |
| Firewall or proxy blocking one host | curl https://api.anthropic.com works but setup still fails | Allowlist the full set, not just the API host |
| Proxy variables not set, or set after launch | Works in a browser, fails in the terminal | Export before you launch; they are read once at startup |
| An open incident | The status page says so | Wait. Retry the setup command afterwards. |
| Region or network policy blocking Anthropic | Everything Anthropic fails, everything else works | A different network. A VPN can be cause or cure here. |
Can't reach Claude, check your connection
On claude.ai this appears as a short stack: Can't reach Claude, then Check your connection, then a Try again button. It is a browser-side failure, which means the useful suspects are entirely different from the CLI ones. Nothing here involves certificates or proxy variables.
- Check the status page first. This message is what an incident looks like from a user seat, and the incident history has plenty of them.
- Disconnect the VPN completely, close the tab, and reopen the site. Not pausing it, not switching regions. Anthropic support names this specifically.
- Open a private window. It bypasses extensions and cached site data in one step, which distinguishes an account or profile problem from a network one faster than clearing anything.
- Disable extensions, particularly content blockers and privacy tools. They are the second most common cause after VPNs, and a rule that was fine last month can start matching after a CDN change.
- Clear cache and cookies for claude.ai specifically, then sign in again. A stale session token produces failures that look like connectivity.
- Try a second network. A hotspot answers the question that ten minutes of browser settings will not.
If two other sites you do not already have open are also slow or failing, the problem is upstream of Claude and none of the above applies. That check takes five seconds and rules out the whole page.
Unable to connect to API, and the code in the parentheses
Once a session is running, connection failures print with a specific error code, and that code is the most informative thing on the screen. Claude Code emits a small family of these.
Unable to connect to API
Connection refused - (error code)
Can't reach the API server - (error code)
No internet route - (error code)
Couldn't connect through your proxy - (error code)
Connection dropped - (error code)| Wording | Means | Go to |
|---|---|---|
Couldn't connect through your proxy | The proxy itself refused or failed | The proxy section |
No internet route | No path to the host from this interface | Routing, VPN, or IPv6 |
Connection refused | Something answered and said no | A local firewall, or a proxy on the wrong port |
Connection dropped / ECONNRESET | The connection was reset mid-flight | The IPv6 section, then the proxy |
SSL certificate verification failed | The chain did not validate | The proxy section |
Socket is closed | The connection went away unexpectedly | Network stability, then the proxy |
# request deadline, default 600000 (ten minutes)
export API_TIMEOUT_MS=1200000
# streaming goes quiet on a slow link: the byte-level watchdog aborts at 180s
# on the direct API. Raise both watchdogs together, capped at 30 minutes.
export CLAUDE_STREAM_IDLE_TIMEOUT_MS=900000Those two are the right lever only when requests are completing eventually. A timeout on a link that is otherwise healthy is a different problem from a connection that never opens, and raising a deadline will not fix the second one.
Corporate proxy and TLS interception
This is the largest single cause in any managed environment, and it is worth understanding rather than pattern-matching. An inspecting proxy terminates TLS, reads the traffic, and re-signs it with your organisation certificate authority. Your browser trusts that authority because your device management installed it. A command-line client only trusts it if it can read the same store.
# proxy. Lowercase variants work; the order checked is
# https_proxy, HTTPS_PROXY, http_proxy, HTTP_PROXY
export HTTPS_PROXY=https://proxy.example.com:8080
export HTTP_PROXY=http://proxy.example.com:8080
# bypass list, space or comma separated; "*" bypasses everything
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"
# your organisation root certificate, as PEM
export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/corp-ca.pem
claude| Variable | Does |
|---|---|
NODE_EXTRA_CA_CERTS | Adds your CA to the trusted set. The usual fix. |
CLAUDE_CODE_CERT_STORE | Which stores to trust. Accepts bundled, system, or both. Default is bundled,system. |
CLAUDE_CODE_CLIENT_CERT | Client certificate, where the gateway requires mutual TLS |
CLAUDE_CODE_CLIENT_KEY | The matching private key |
CLAUDE_CODE_CLIENT_KEY_PASSPHRASE | Passphrase, if the key is encrypted |
claude --debug
# writes to ~/.claude/debug/<session-id>.txt, not the terminal
# the lines that prove it:
# CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS (/etc/ssl/certs/corp-ca.pem)
# mTLS: Loaded client certificate from CLAUDE_CODE_CLIENT_CERTThe allowlist your firewall actually needs
Allowlisting api.anthropic.com and stopping there is the most common half-fix. Sign-in, updates, and plugin installs all reach elsewhere, and each one fails as a connection error rather than as something that names the host it wanted.
| Host | Needed for |
|---|---|
api.anthropic.com | API requests, feature flags, the WebFetch domain safety check |
claude.ai | claude.ai account authentication |
claude.com | Sign-in opens here and redirects; documentation lookups |
platform.claude.com | Console authentication, and OAuth token exchange and refresh for both account types |
downloads.claude.ai | Native installer, auto-updater, plugin executables |
mcp-proxy.anthropic.com | MCP connectors from claude.ai |
registry.npmjs.org | npm and bun installs, npx-launched MCP servers, plugin dependencies |
storage.googleapis.com | Plugin metadata and install counts; artifact uploads |
raw.githubusercontent.com | The changelog feed behind /release-notes |
code.claude.com | Documentation lookups only. Safe to block if you accept that. |
When curl works and the client does not
This is the case that wastes the most time, because every check you know how to run passes. curl connects. The browser loads claude.ai. DNS resolves. And the CLI fails on every request with a reset connection.
curl -4 -sS -o /dev/null -w 'ipv4 %{http_code}\n' https://api.anthropic.com
curl -6 -sS -o /dev/null -w 'ipv6 %{http_code}\n' https://api.anthropic.com
# ipv4 answers, ipv6 hangs or resets? That is your bug.The mechanism is a router advertising local IPv6 addresses while the connection upstream has no IPv6 route, which is common on consumer equipment and on some satellite links. api.anthropic.com publishes an AAAA record, so a client that prefers IPv6 tries it first. curl and browsers implement Happy Eyeballs, race both families, and quietly use whichever answers. The CLI runtime does not do that reliably, so it picks the address that resets and stays there.
| Attempt | Result reported |
|---|---|
NODE_OPTIONS=--dns-result-order=ipv4first | Partial. Some code paths use native resolution and ignore it. |
| Disabling IPv6 at the operating system level | Unreliable. The runtime has been observed bypassing it. |
Adding an IPv4 entry to /etc/hosts | Ineffective. Resolution still returns both families. |
| A firewall rule blocking IPv6 to the host | Ineffective for the same reason |
| A phone hotspot | Works. Which confirms the diagnosis, if not much else. |
When it is the credential rather than the network
A surprising share of reported connection failures are authentication failures wearing a connection failure costume. The give-away is that they arrive fast and identically every time, with no retry delay, because the request reached Anthropic and came back rejected.
# inside a session
/status
# a stray key in a shell profile outranks your subscription login
unset ANTHROPIC_API_KEY
/login| Message | It is |
|---|---|
401 Invalid authentication credentials | The credential was rejected. Re-authenticate with /login. |
OAuth token revoked or has expired | A refresh failed. /login again. |
Your ANTHROPIC_API_KEY belongs to a disabled organization | A leftover key, not a network fault. Unset it. |
Your organization has disabled API key authentication | Policy. Sign in with your account instead. |
Credit balance is too low | A Console key with no credits, used unintentionally |
403 with host_not_allowed | A cloud session network policy, not your machine |
Questions people ask
How do I fix "Unable to connect to Anthropic services"?
Check status.claude.com first, since this is what an incident looks like from a client. If Anthropic is healthy, run curl https://api.anthropic.com: a 404 means the whole path works and the problem is elsewhere, while a timeout or certificate error is your answer. Behind a corporate proxy, set NODE_EXTRA_CA_CERTS to your organisation root certificate and export the proxy variables before launching. Then confirm your firewall allows platform.claude.com and the download hosts, not only the API host.
Why does it say "Can't reach Claude, check your connection" when my internet works?
On claude.ai this is a browser-side failure, and the usual causes are a VPN, a content-blocking extension, or stale site data. Disconnect the VPN entirely rather than switching regions, then try a private window, which bypasses extensions and cached data in one step. If a managed device shows a blank page instead of an error, the CDN hosts that serve the app are blocked while claude.ai itself is allowed.
Why does curl reach api.anthropic.com but Claude Code cannot?
Almost always broken IPv6. The host publishes an AAAA record, and on a network that advertises IPv6 locally without an upstream route, connections over it are reset. curl and browsers implement Happy Eyeballs, race both address families, and use whichever answers first; the CLI runtime does not fall back reliably. Confirm by comparing curl -4 and curl -6 against the same host, then test on a phone hotspot.
What do I set for Claude Code behind a corporate proxy?
Export HTTPS_PROXY and HTTP_PROXY, plus NO_PROXY for internal hosts, and set NODE_EXTRA_CA_CERTS to your organisation root certificate as a PEM file. Set all of them before you launch, because they are read once at startup. SOCKS proxies are not supported, and NTLM or Kerberos authentication needs an LLM gateway rather than a proxy variable.
Which domains do I need to allowlist for Claude Code?
At minimum api.anthropic.com, claude.ai, claude.com, and platform.claude.com for requests and authentication, downloads.claude.ai for the installer and updates, registry.npmjs.org for npm installs and npx-launched MCP servers, mcp-proxy.anthropic.com for claude.ai connectors, and raw.githubusercontent.com for release notes. Telemetry hosts are optional and can be turned off with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC.
How do I know whether the certificate setting actually took effect?
Run claude --debug, which writes to ~/.claude/debug/<session-id>.txt, and look for a line reading "CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS". The /status row for additional CA certificates prints the configured path without confirming the file loaded, so a typo there looks configured and is not.
Is "Unable to connect to Anthropic services" ever an Anthropic outage?
Yes, and the status history shows incidents where sign-in failed while the API stayed healthy, which is exactly the shape a setup or login connectivity check would report. Check status.claude.com before changing anything, so you do not spend the outage undoing local changes afterwards.
Why does the connection error appear instantly instead of retrying?
Claude Code retries transient failures up to 10 times with exponential backoff, but it never retries a TLS certificate validation failure, so you can fix the certificate setup immediately. An error that appears with no delay is therefore either a certificate problem or a credential rejection, and neither is fixed by anything in your network configuration.
Could this be my API key rather than my network?
Often. Run /status and read the active credential. A stray ANTHROPIC_API_KEY in a shell profile outranks a subscription login, and a key from a disabled organisation or one with no credit produces errors that read like connectivity. Unset the variable and run /login to go back to your subscription.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.