Claude Code „Can't reach the API server“ und „Connection refused“: Ursachen und Lösungen für Netzwerk-, Proxy- und TLS-Fehler (Unable to connect)

Du willst Claude Code auf einem Firmenrechner oder über VPN nutzen, und die Verbindung scheitert mit Fehlern wie diesen?

# Was jetzt angezeigt wird (Beispiele)
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

# Was ältere Versionen anzeigten
Unable to connect to API (ECONNREFUSED)
Unable to connect to API: SSL certificate verification failed.
  Check your proxy or corporate SSL certificates

Der Wortlaut hängt von der Version ab. Seit v2.1.227 beginnen Meldungen, die früher nur einen Code anhängten, etwa Unable to connect to API (ECONNREFUSED), stattdessen mit der Art des Fehlers, etwa Connection refused — oder Can't reach the API server — (Zuordnungstabelle in §2). Egal welchen Wortlaut du siehst: Was passiert und wie du es behebst, ist dasselbe.

Das sind Netzwerkfehler und bedeuten "Claude Code erreicht den Server von Anthropic (api.anthropic.com) nicht." Es handelt sich nicht um Authentifizierung (401/403), nicht um Serverüberlastung (529/500) und nicht um ein Rate-Limit (429) – die Anfrage hat den Server überhaupt nie erreicht. Die üblichen Ursachen sind Firmen-Proxys, TLS-Inspektion (Zertifikate) und Firewalls, weshalb dieses Problem in Unternehmensnetzwerken besonders häufig auftritt. Dieser Artikel behandelt Proxy-Konfiguration, Firmen-CA-Zertifikate, die freizugebenden Domains und die Diagnoseschritte – auf Basis offizieller Informationen.

Die Kernpunkte vorab. (1) Hinter einem Proxy setzt du HTTPS_PROXY. (2) Bei einem Zertifikatsfehler durch TLS-Inspektion (Zscaler usw.) richtest du NODE_EXTRA_CA_CERTS auf die Firmen-CA – und deaktiviere niemals die Prüfung mit NODE_TLS_REJECT_UNAUTHORIZED=0 (das setzt den gesamten Datenverkehr dem Abfangen aus). (3) Führe zuerst curl -I https://api.anthropic.com aus, um zu prüfen "wird der Server überhaupt erreicht?" – das ist der Ausgangspunkt jeder Eingrenzung.

1. Was dieser Fehler bedeutet

Unable to connect to API, fetch failed, ECONNREFUSED / ETIMEDOUT (seit v2.1.227 mit Wortlaut wie Connection refused —; siehe §2) bedeuten "die Anfrage hat den Server von Anthropic nicht erreicht" = sie ist irgendwo in TCP/TLS/DNS gescheitert. Das ist der entscheidende Unterschied zu anderen Fehlern: Authentifizierung (401/403), Server (529/500) und Rate (429) sind Antworten, nachdem der Server erreicht wurde, während Netzwerkfehler bedeuten, dass er nie erreicht wurde.

In Unternehmensnetzwerken teilen sich die typischen Blockaden in drei Schichten auf. (1) Proxy – du kommst nicht direkt nach außen und musst über einen Firmen-Proxy routen, der nicht konfiguriert ist. (2) TLS-Inspektion (Zertifikate) – ein Inspektions-Proxy wie Zscaler ersetzt Zertifikate, sodass du der Firmen-Root-CA vertrauen musst. (3) Firewall – die erforderlichen Domains sind nicht freigegeben. Das Erste, was du tun solltest, ist, mit curl -I https://api.anthropic.com zu bestätigen "ist der Server erreichbar?" – diese eine Prüfung trennt "ein Netzwerkproblem" von "allem anderen."

2. Was jede Meldung bedeutet (Wortlaut seit v2.1.227)

Laut der offiziellen Fehlerreferenz bedeuten die Meldungen dieser Gruppe, dass die TCP-Verbindung zur API fehlgeschlagen ist oder nie zustande kam. Bei den gängigen Fehlercodes nennt die Meldung die Art des Fehlers in Worten und behält den Code in Klammern. So sieht es jetzt aus:

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

Vor v2.1.227 lauteten all diese Meldungen mit Code Unable to connect to API, gefolgt vom Code (zum Beispiel Unable to connect to API (ECONNREFUSED)). Codes, die Claude Code nicht kennt, erscheinen weiterhin in dieser Form. Außerdem kann dieselbe Meldung verschiedene Codes tragen: Connection refused kann ConnectionRefused oder ECONNREFUSED zeigen, und Can't reach the API server kann ENOTFOUND oder FailedToOpenSocket zeigen.

Egal welche Meldung erscheint: Vorübergehende Fehler werden automatisch wiederholt, sodass die Wiederholungen bereits aufgebraucht sind, wenn sie auf dem Bildschirm steht. Kommt sie immer wieder, liegt die Ursache in deinem lokalen Netzwerk. Als häufige Ursachen nennt die offizielle Referenz fehlenden Internetzugang, ein VPN, das api.anthropic.com blockiert, oder einen vorgeschriebenen Firmen-Proxy, der nicht konfiguriert ist. Die Lösungen stehen in §3–§6.

Unable to connect to Anthropic services (Ersteinrichtung)

Bei der Einrichtung beim ersten Start prüft Claude Code, bevor der Anmeldeschritt erscheint, ob api.anthropic.com und platform.claude.com erreichbar sind. Schlägt eine der beiden Prüfungen fehl, gibt es den Grund aus und beendet sich. Das offizielle Beispiel:

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.

Die Prüfung läuft über dieselbe Proxy-Konfiguration wie die API-Anfragen und gibt jedem Versuch 10 Sekunden. Lief der fehlgeschlagene Versuch über einen Proxy, nennt die Meldung die Umgebungsvariable, mit der er konfiguriert ist (etwa HTTPS_PROXY). Was zu tun ist:

• Prüfe, ob die genannte Variable auf den richtigen Proxy zeigt, und bitte dein Netzwerkteam, HTTPS-Verbindungen zum Host aus der Meldung über ihn zuzulassen (Allowlist in §5)
• Führe die Erreichbarkeitsprüfung mit curl aus §6 in derselben Shell aus
• Bleibt es hinter einer Proxy-URL, die mit https:// beginnt, bei Checking connectivity... hängen, handelt es sich womöglich um einen Fehler aus der Zeit vor v2.1.222 (die Prüfung nahm einen anderen Weg als die API-Anfragen und hatte kein Timeout). Aktualisiere
• Wenn sich deine Organisation über ein Cloud-Gateway (Claude apps gateway) anmeldet und dieser Fehler beim ersten Start erscheint, aktualisiere auf v2.1.247 oder neuer

Ist dein Netzwerk offen und der Fehler bleibt, weist die offizielle Referenz darauf hin, dass Claude Code in deinem Land oder deiner Region möglicherweise nicht verfügbar ist. Sieh in der Liste der unterstützten Länder und Regionen nach.

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.

Diese Warnung bedeutet nicht "die Anfrage kam nicht an", sondern "etwas dazwischen hat die Antwort verändert". Eine Streaming-Antwort deines Modellanbieters endete, ohne verwertbare Daten zu liefern, daher hat Claude Code die Anfrage ohne Streaming erneut gesendet, um den Durchgang abzuschließen. Jede betroffene Anfrage wird zweimal gesendet: der leere Streaming-Versuch und die Wiederholung. Laut der offiziellen Referenz ist die übliche Ursache ein Proxy oder Gateway, der den Body der Streaming-Antwort unterwegs verbraucht oder umwandelt, und die Lösung besteht darin, jeden Proxy und jedes Gateway zwischen Claude Code und deinem Modellanbieter so zu konfigurieren, dass Body und Header von Streaming-Antworten unverändert durchgereicht werden. Die Warnung erscheint einmal pro Sitzung und nur in interaktiven Sitzungen. Vor v2.1.239 hat Claude Code stillschweigend ohne Streaming wiederholt.

3. Proxy-Konfiguration (HTTPS_PROXY)

Wenn du über einen Firmen-Proxy routen musst, setze die standardmäßigen Proxy-Umgebungsvariablen. Claude Code berücksichtigt sie.

# Empfohlen: HTTPS-Proxy
export HTTPS_PROXY=http://proxy.example.com:8080
# Falls HTTPS nicht verfügbar ist, HTTP_PROXY
export HTTP_PROXY=http://proxy.example.com:8080
# Ziele, die den Proxy umgehen (durch Leerzeichen oder Komma getrennt)
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

# Proxy mit Authentifizierung (Passwörter nicht fest einbetten)
export HTTPS_PROXY=http://username:password@proxy.example.com:8080

Hinweise: SOCKS-Proxys werden nicht unterstützt. Für NTLM- / Kerberos-Proxys empfiehlt die offizielle Dokumentation, dazwischen ein LLM gateway aufzusetzen und ANTHROPIC_BASE_URL darauf zu richten. Diese Variablen können auch im env-Block der settings.json stehen.

Die Einrichtung, die Kosten und die Hinweise für die Anbindung von Modellen außerhalb von Claude (DeepSeek, GLM, Kimi usw.) über ANTHROPIC_BASE_URL erklärt Claude Code mit DeepSeek, GLM und Kimi nutzen.

4. TLS und Firmen-CA-Zertifikate (am wichtigsten, sicher)

Die häufigste Blockade in Unternehmen ist ein Zertifikatsfehler, der dadurch entsteht, dass ein TLS-Inspektions-Proxy (Zscaler, Netskope, Palo Alto usw.) Zertifikate ersetzt. Typische Meldungen sind unable to get local issuer certificate und SELF_SIGNED_CERT_IN_CHAIN.

Seit v2.1.273 enthalten die Meldungen von Claude Code selbst den Fehlercode und die Lösung. Während einer Sitzung zeigen API-Anfragen:

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

Während /login und der Verbindungsprüfung beim Start erzeugt derselbe Fehler eine andere Meldung:

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.

Vor v2.1.273 endeten die beiden ersten Meldungen bei Check your proxy or corporate SSL certificates, ohne den Code und ohne den Hinweis auf NODE_EXTRA_CA_CERTS (die alte Ausgabe am Anfang des Artikels). Außerdem wird seit v2.1.199 ein Fehler bei der Zertifikatsprüfung nicht wiederholt, sodass der Fehler schon beim ersten Versuch erscheint (ältere Versionen haben zuerst einige Minuten lang wiederholt). Vorübergehende TLS-Probleme wie ein Handshake-Timeout werden weiterhin wiederholt.

Zum Hintergrund: Neuere Versionen von Claude Code vertrauen SOWOHL dem mitgelieferten CA-Satz ALS AUCH dem Trust Store des Betriebssystems. Das heißt: Wenn die Firmen-Root-CA im Zertifikatsspeicher des Betriebssystems liegt, funktioniert es oft ohne zusätzliche Konfiguration (das Verhalten variiert je nach Version, prüfe daher den aktuellen Stand). Liegt sie nicht im OS-Speicher, richte NODE_EXTRA_CA_CERTS auf das CA-Bundle (PEM), das du von der IT erhalten hast:

# Der korrekte, sichere Weg: der Firmen-CA vertrauen
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem

# Falls der Proxy ein Client-Zertifikat erfordert (mTLS)
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem

Wenn du bereits zum Installationszeitpunkt (bevor die Binärdatei existiert) auf einen Zertifikatsfehler stößt, gib die CA an curl weiter: curl --cacert /path/to/corporate-ca.pem -fsSL https://claude.ai/install.sh | bash.

OAuth error: SSL certificate error (CERT_HAS_EXPIRED)

Mitten in der Anmeldung (dem OAuth-Schritt von /login) kann die folgende Meldung erscheinen und alles anhalten. Das ist der exakte Text, den Nutzer in GitHub-Issues gemeldet haben:

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.

Diese Meldung steht nicht in der offiziellen Fehlerreferenz. Der offizielle Abschnitt SSL certificate errors zeigt nur die Codes UNABLE_TO_GET_ISSUER_CERT_LOCALLY und SELF_SIGNED_CERT_IN_CHAIN; ein abgelaufenes Zertifikat wird nur beiläufig erwähnt, als ein Beispiel für eine fehlgeschlagene Zertifikatsprüfung in der Erklärung zu automatischen Wiederholungen. Der Text oben stammt von Nutzern in den GitHub-Issues #71708 und #71727 (beide Juni 2026).

Was CERT_HAS_EXPIRED bedeutet: Es ist einer der Zertifikatsfehlercodes, die die TLS-Schicht von Node.js zurückgibt, und die offizielle Node.js-Dokumentation beschreibt ihn als „Certificate has expired“ (das Zertifikat ist abgelaufen). Das vom Server erhaltene Zertifikat wurde also geprüft und als abgelaufen eingestuft. Verglichen wird dabei mit der Uhr deines eigenen Rechners.

Was in den Meldungen steht: Die Verfasser beider Issues schreiben, dass sie weder Proxy noch VPN nutzten und dass curl denselben Host problemlos erreichte (der Verfasser von #71708 hat außerdem geprüft, dass die Uhr stimmte). Die Meldung tritt also auch in Umgebungen auf, auf die ihr eigener Hinweis (Firmenproxy, TLS-Inspektion) nicht passt. Die Verfasser hatten die in Claude Code gebündelte Laufzeitumgebung im Verdacht, und mehrere Kommentare berichten, dass der Wechsel zurück auf eine ältere Version geholfen hat. In keinem der beiden Issues gibt es aber eine Antwort von Anthropic, und beide wurden wegen Inaktivität geschlossen. Die Ursache ist offiziell nicht bestätigt. Stand 30. September 2026 enthält auch das offizielle CHANGELOG keinen Eintrag, der dieses Symptom als behoben nennt.

Was du der Reihe nach prüfst:

1. Die Uhr des Rechners: Stimmen Datum, Uhrzeit und Zeitzone? Geht die Uhr stark falsch, kann selbst ein gültiges Zertifikat als abgelaufen gelten.
2. Das Zertifikat des Firmenproxys: Läuft dein Datenverkehr über einen Proxy oder ein Sicherheitsprodukt mit TLS-Inspektion, frag die IT, ob das eingesetzte Zertifikat (einschließlich der Firmen-CA) abgelaufen ist.
3. NODE_EXTRA_CA_CERTS: Musst du einer Firmen-CA vertrauen, setze NODE_EXTRA_CA_CERTS auf das CA-Bundle von der IT, wie es die offizielle Seite zur Netzwerkkonfiguration beschreibt (die Schritte oben). Ob es geladen wurde, erkennst du an der Zeile CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS im Log von claude --debug.
4. Wenn sie trotzdem erscheint: Stimmt die Uhr, gibt es keinen Proxy und kommt curl -I https://platform.claude.com durch, bist du vielleicht in derselben Lage wie die GitHub-Meldungen. Aktualisiere Claude Code und sieh dir dann die Issues und das Changelog an. Ein Kommentar sagt, NODE_TLS_REJECT_UNAUTHORIZED=0 habe es zum Laufen gebracht, aber wie der Kasten oben erklärt, schaltet das die Prüfung komplett ab, also nutze es nicht.

5. Firewall-Allowlist-Domains

Wenn deine Firewall die Ziele einschränkt, gib diese wichtigsten Domains über HTTPS (443) frei (gemäß den offiziellen Netzwerkanforderungen; wenn du MCP-Konnektoren, Plugins usw. nutzt, brauchst du zusätzlich weitere Hosts aus der offiziellen Liste).

Die Hosts für betriebliche Telemetrie und Fehlerberichte (http-intake.logs.us5.datadoghq.com und browser-intake-us5-datadoghq.com) sind optional, und CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC schaltet beide ab (sie müssen nicht in der erforderlichen Allowlist enthalten sein). Wenn du über npm installierst, brauchst du downloads.claude.ai nicht für Installer und automatische Updates, wohl aber die Paket-Registry registry.npmjs.org. Die genauen Domains und IP-Bereiche können überarbeitet werden, daher prüfe den aktuellen Stand auf der offiziellen Netzwerkkonfigurationsseite.

6. Der Diagnose-Workflow

Wenn keine Verbindung zustande kommt, gehe von oben nach unten vor. Das erste curl gibt die Richtung vor.

7. Abgrenzung zu ähnlichen Fehlern

"Es bleibt hängen" kann auch nicht-netzwerkbedingt sein. Die große Trennlinie ist "hat es den Server erreicht?"

Eine Eselsbrücke: Netzwerkfehler bedeuten "der Server wurde nie erreicht" (TCP/TLS/DNS), und HTTPS_PROXY oder NODE_EXTRA_CA_CERTS helfen nur auf dieser Schicht. Im Gegensatz dazu sind 401/403, 529/500 und 429 "Antworten nach dem Erreichen", sodass das Anpassen von Proxy oder CA sie nicht behebt. Ob curl erfolgreich ist, ist das beste einzelne Indiz, das die beiden voneinander trennt. Zu weiteren häufigen Fehlern siehe die Fehlerübersicht.

Zusammenfassung

Die Netzwerk-/Proxy-Fehler von Claude Code (Unable to connect / fetch failed / SSL certificate verification failed usw.) bedeuten, dass die Anfrage den Server nie erreicht hat = ein TCP/TLS/DNS-Fehler. Sie sind etwas anderes als Authentifizierung (401/403), Server (529/500) und Rate (429), und die üblichen Verursacher sind der Firmen-Proxy, die TLS-Inspektion und die Firewall im Unternehmen. Seit v2.1.227 sind sie so formuliert, dass zuerst die Art des Fehlers genannt wird, etwa Connection refused — oder Can't reach the API server —, und die Ersteinrichtung beendet sich mit Unable to connect to Anthropic services.

Die Lösungen: (1) Hinter einem Proxy setzt du HTTPS_PROXY (SOCKS nicht unterstützt; NTLM/Kerberos über ein Gateway), (2) bei Zertifikatsfehlern legst du die Firmen-CA in NODE_EXTRA_CA_CERTS – niemals NODE_TLS_REJECT_UNAUTHORIZED=0, (3) setze api.anthropic.com usw. in der Firewall auf die Allowlist. Diagnostiziere, indem du zuerst die Erreichbarkeit mit curl -I https://api.anthropic.com testest -> /doctor und Proxy-Prüfung -> Zertifikats-/Proxy-Einstellungen -> eine direkte Verbindung zur Bestätigung -> DNS/VPN/Docker. Der Schlüssel ist, Netzwerk von Authentifizierung/Server/Rate über die Frage "hat es den Server erreicht?" zu trennen. Verwandt: Authentifizierungs-/Login-Fehler, 529/500-Fehler, Claude-Code-Fehlerübersicht.

FAQ

Q. Auf meinem Firmen-PC erscheint "Unable to connect to API" und ich komme nicht durch.
A. Meistens musst du über einen Firmen-Proxy routen, der nicht konfiguriert ist. Prüfe zuerst die Erreichbarkeit mit curl -I https://api.anthropic.com; wenn das scheitert, setze einen Proxy wie export HTTPS_PROXY=http://proxy.example.com:8080 (für einen Proxy mit Authentifizierung ergänze user:password@). Beachte, dass SOCKS nicht unterstützt wird, und für NTLM/Kerberos-Proxys lautet die offizielle Empfehlung, über ein LLM gateway zu gehen.

Q. Sind "Can't reach the API server" und "Connection refused" andere Fehler als das frühere "Unable to connect to API"?
A. Sie gehören zur selben Gruppe; in v2.1.227 hat sich nur der Wortlaut geändert. Früher wurde nur ein Code angehängt, etwa Unable to connect to API (ECONNREFUSED); jetzt steht die Art des Fehlers vorn, etwa Connection refused — a firewall or proxy may be blocking it (ConnectionRefused) oder Can't reach the API server — check your internet or DNS (ENOTFOUND). Der Code in Klammern gibt einen Hinweis auf die Ursache; was du prüfen solltest, steht in der Tabelle in §2.

Q. Beim ersten Start erscheint "Unable to connect to Anthropic services", und das Programm beendet sich.
A. Es ist an dem Schritt gescheitert, der vor der Anmeldung die Verbindung zu api.anthropic.com und platform.claude.com prüft. Nennt die Meldung eine Proxy-Variable (etwa HTTPS_PROXY), klär ihren Wert mit deinem Netzwerkteam und prüfe, ob Verbindungen zum Host aus der Meldung erlaubt sind. Die Erreichbarkeit kannst du auch mit curl -I https://api.anthropic.com prüfen. Ist dein Netzwerk offen und der Fehler bleibt, weist die offizielle Referenz darauf hin, dass Claude Code in deinem Land oder deiner Region möglicherweise nicht verfügbar ist; das kannst du in der offiziellen Liste der unterstützten Länder nachsehen.

Q. Ich bekomme "SSL certificate verification failed."
A. Das ist typischerweise ein Firmen-TLS-Inspektions-Proxy (z. B. Zscaler), der Zertifikate ersetzt. Hole dir die Firmen-Root-CA (PEM) von der IT und setze export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem. Wenn die Firmen-CA bereits im Zertifikatsspeicher des Betriebssystems liegt, funktioniert es eventuell ohne Konfiguration. Deaktiviere niemals die Prüfung mit NODE_TLS_REJECT_UNAUTHORIZED=0 – das setzt den gesamten Datenverkehr dem Abfangen aus.

Q. NODE_TLS_REJECT_UNAUTHORIZED=0 zu setzen hat es behoben. Ist das in Ordnung?
A. Nein – mach das sofort rückgängig. Es deaktiviert die TLS-Zertifikatsprüfung für den gesamten Prozess und lässt den gesamten Datenverkehr – einschließlich des Verkehrs zu api.anthropic.com – schutzlos gegenüber Man-in-the-Middle-Angriffen (Abhören/Manipulation). Das ist ein gravierendes Sicherheitsrisiko, das Zugangsdaten und Quellcode preisgeben kann. Die einzig richtige Lösung ist, der Firmen-CA über NODE_EXTRA_CA_CERTS korrekt zu vertrauen.

Q. Welche Domains sollte ich in der Firewall freigeben?
A. Über HTTPS (443) gibst du mindestens api.anthropic.com (API), claude.ai, claude.com und platform.claude.com (Authentifizierung), downloads.claude.ai (Installer/Updates) und raw.githubusercontent.com (Changelog) frei. Betriebliche Telemetrie und Fehlerberichte (Datadog) sind optional. Die genauen Domains/IPs können überarbeitet werden, daher prüfe den aktuellen Stand auf der offiziellen Netzwerkkonfigurationsseite.

Q. curl funktioniert, aber nur Claude Code stellt keine Verbindung her.
A. Die Ursache liegt oft zwischen Claude Code und dem Betriebssystem. Häufige Fälle: eine WSL-/etc/resolv.conf, die auf einen toten DNS zeigt, Überreste eines veralteten VPN (z. B. alte macOS-utun-Schnittstellen), oder ein residentes Tool wie Docker, das den Verkehr abfängt. Probiere eine direkte Verbindung ohne VPN, stoppe residente Tools und überprüfe das DNS, in dieser Reihenfolge. Beachte, dass vorübergehende 5xx-Fehler bis zu 10 Mal automatisch wiederholt werden; wenn du also einen Fehler siehst, während curl erfolgreich ist, sind die Wiederholungsversuche bereits aufgebraucht.