SpyBara
Go Premium

network-config.md 2026-10-22 22:58 UTC to 2026-10-23 22:59 UTC

This page contains 44 additions and 44 deletions.

2026
Thu 1 23:59 Fri 2 22:59 Tue 6 23:59 Thu 8 22:58 Sat 10 23:01 Wed 14 22:58 Sat 17 23:57 Mon 19 23:58 Tue 20 23:00 Wed 21 23:02 Thu 22 22:58 Fri 23 22:59 Sat 24 22:59

Enterprise-Netzwerkkonfiguration

Konfigurieren Sie Claude Code für Enterprise-Umgebungen mit Proxy-Servern, benutzerdefinierten Zertifizierungsstellen (CA) und gegenseitiger Transport Layer Security (mTLS)-Authentifizierung.

Claude Code unterstützt verschiedene Enterprise-Netzwerk- und Sicherheitskonfigurationen über Umgebungsvariablen. Dies umfasst das Routing von Datenverkehr über unternehmenseigene Proxy-Server, das Vertrauen in benutzerdefinierte Zertifizierungsstellen (CA) und die Authentifizierung mit gegenseitigen Transport Layer Security (mTLS)-Zertifikaten für erhöhte Sicherheit.

Legen Sie diese Umgebungsvariablen fest, bevor Sie Claude Code starten. Variablen, die in Ihrer Shell exportiert werden, werden einmalig beim Start gelesen, daher werden später vorgenommene Änderungen an Ihrer Shell-Umgebung von einer laufenden Sitzung nicht übernommen.

[!NOTE]

Alle auf dieser Seite gezeigten Umgebungsvariablen können auch in settings.json konfiguriert werden.

Proxy-Konfiguration

Umgebungsvariablen

Claude Code respektiert Standard-Proxy-Umgebungsvariablen. In Claude Desktop-Sitzungen, in denen die App die Anbieterverbindung verwaltet, liest Claude Code diese nur aus verwalteten Einstellungen und ~/.claude/settings.json; siehe mTLS-Authentifizierung für die Bereichsregeln.

# HTTPS-Proxy (empfohlen)
export HTTPS_PROXY=https://proxy.example.com:8080

# HTTP-Proxy (falls HTTPS nicht verfügbar)
export HTTP_PROXY=http://proxy.example.com:8080

# Proxy für spezifische Anfragen umgehen – durch Leerzeichen getrennt
export NO_PROXY="localhost 192.168.1.1 example.com .example.com"
# Proxy für spezifische Anfragen umgehen – durch Komma getrennt
export NO_PROXY="localhost,192.168.1.1,example.com,.example.com"
# Proxy für alle Anfragen umgehen
export NO_PROXY="*"

Kleingeschriebene Varianten funktionieren auch, und Claude Code verwendet die erste, die in der Reihenfolge https_proxy, HTTPS_PROXY, http_proxy, HTTP_PROXY gesetzt ist.

Claude Code sendet seine WebSocket-Verbindungen zu localhost, ::1 oder 127.0.0.0/8 niemals über den Proxy, daher benötigen Sie keinen Loopback-Eintrag in NO_PROXY für diese.

[!NOTE]

Claude Code unterstützt keine SOCKS-Proxies.

Basis-Authentifizierung

Wenn Ihr Proxy eine Basis-Authentifizierung erfordert, fügen Sie Anmeldedaten in die Proxy-URL ein:

export HTTPS_PROXY=http://username:password@proxy.example.com:8080

[!WARNING]

Vermeiden Sie das Hardcodieren von Passwörtern in Skripten. Verwenden Sie stattdessen Umgebungsvariablen oder sichere Anmeldedatenspeicherung.

[!TIP]

Für Proxies, die erweiterte Authentifizierung erfordern (NTLM, Kerberos usw.), erwägen Sie die Verwendung eines LLM-Gateway-Dienstes, der Ihre Authentifizierungsmethode unterstützt.

CA-Zertifikatspeicher

Standardmäßig vertraut Claude Code sowohl seinen gebündelten Mozilla-CA-Zertifikaten als auch dem Zertifikatspeicher Ihres Betriebssystems. Das Lesen des Betriebssystem-Speichers erfordert eine Laufzeit mit tls.getCACertificates: Das native Installationsprogramm hat es immer, und npm-Installationen benötigen Node 22.15 oder später. Bei älteren Node-Versionen gelten nur der gebündelte Satz und NODE_EXTRA_CA_CERTS. Enterprise-TLS-Inspektions-Proxys funktionieren ohne zusätzliche Konfiguration, wenn ihr Root-Zertifikat im Betriebssystem-Vertrauensspeicher installiert ist und die Laufzeit es lesen kann. Wenn ein solcher Proxy gzip-komprimierte Anfrage-Bodys fehlerhaft verarbeitet, setzen Sie CLAUDE_CODE_GZIP_REQUEST_BODIES=0, um die Komprimierung für Anfragen an die Claude API, für Telemetrie und für das Veröffentlichen von Artefakten auszuschalten.

CLAUDE_CODE_CERT_STORE akzeptiert eine durch Kommas getrennte Liste von Quellen. Erkannte Werte sind bundled für den mit Claude Code ausgelieferten Mozilla-CA-Satz und system für den Betriebssystem-Vertrauensspeicher. Der Standard ist bundled,system.

Um nur dem gebündelten Mozilla-CA-Satz zu vertrauen:

export CLAUDE_CODE_CERT_STORE=bundled

Um nur dem Betriebssystem-Zertifikatspeicher zu vertrauen:

export CLAUDE_CODE_CERT_STORE=system

[!NOTE]

CLAUDE_CODE_CERT_STORE hat keinen dedizierten settings.json-Schemaschlüssel. Setzen Sie ihn über den env-Block in ~/.claude/settings.json oder direkt in der Prozessumgebung.

Benutzerdefinierte CA-Zertifikate

Wenn Ihre Enterprise-Umgebung eine benutzerdefinierte CA verwendet, konfigurieren Sie Claude Code so, dass dieser direkt vertraut wird:

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

mTLS-Authentifizierung

Für Unternehmensumgebungen, die eine Client-Zertifikatauthentifizierung erfordern:

# Client-Zertifikat für die Authentifizierung
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem

# Privater Schlüssel des Clients
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem

# Optional: Passphrase für verschlüsselten privaten Schlüssel
export CLAUDE_CODE_CLIENT_KEY_PASSPHRASE="your-passphrase"

Claude Code liest die Zertifikat- und Schlüsseldateien beim Start und liest sie jedes Mal erneut, wenn es Einstellungen anwendet, z. B. wenn Ihre Organisation den env-Block in verwalteten Einstellungen während einer Sitzung ändert.

Um das Zertifikat und den Schlüssel zu rotieren, ersetzen Sie die Dateien unter denselben Pfaden. Claude Code übernimmt den Austausch in einer laufenden Sitzung ohne Neustart. Wenn eine API-Anfrage mit einem Fehler auf Verbindungsebene fehlschlägt, z. B. bei einem Verbindungsabbruch oder einem TLS-Handshake-Fehler, liest es beide Dateien erneut und versucht die Anfrage mit dem neuen Paar erneut. Vor v2.1.232 las Claude Code bei Verbindungsfehlern nicht erneut, daher behielt es das bereits geladene Paar bei, bis es das nächste Mal Einstellungen anwendete oder Sie es neu starteten.

Claude Code liest die Dateien als Reaktion auf fehlgeschlagene Anfragen erneut, nicht durch Überwachung auf Änderungen:

  • Timing: Claude Code tut nichts in dem Moment, in dem Sie die Dateien ersetzen. Es präsentiert das neue Paar beim Wiederversuch nach einem qualifizierenden Fehler oder bei der nächsten Anfrage nach dem Anwenden von Einstellungen, je nachdem, was zuerst kommt.
  • Gateway-Ablehnungen: Claude Code liest erneut, wenn Ihr Gateway die Verbindung zurückgesetzt oder den TLS-Handshake abgelehnt hat, nachdem es das alte Paar nicht mehr akzeptiert. Es liest nicht erneut, wenn das Gateway den Handshake abgeschlossen hat und mit einem HTTP-Fehler antwortet. In diesem Fall lädt Claude Code das neue Paar, wenn es das nächste Mal Einstellungen anwendet oder wenn Sie es neu starten.
  • Unvollständige Rotationen: Wenn Claude Code erneut liest, während Ihre Rotation noch geschrieben wird, z. B. beim Lesen eines Zertifikats und eines Schlüssels, die nicht zusammenpassen, behält es das vorherige Paar und liest beim nächsten Fehler erneut.
  • OTLP-Telemetrie-Exporter: Claude Code behält das Zertifikat, das die Exporter beim ersten Gebrauch geladen haben, daher starten Sie Claude Code neu, damit ein rotiertes Zertifikat Ihren Telemetrie-Collector erreicht.
  • Das Neuladen ausschalten: Setzen Sie CLAUDE_CODE_DISABLE_MTLS_RELOAD_ON_STALE_CONNECTION=1, um das Neulesen bei Verbindungsfehlern auszuschalten. Claude Code übernimmt dann rotierte Dateien nur, wenn es das nächste Mal Einstellungen anwendet oder beim nächsten Start.

Um zu bestätigen, dass Claude Code eine Rotation übernommen hat, starten Sie die Sitzung mit Debug-Protokollierung und suchen Sie nach Stale connection — reloaded rotated mTLS client material im Protokoll. Claude Code protokolliert diese Zeile nicht, wenn es die Rotation beim Anwenden von Einstellungen übernimmt, daher bedeutet eine fehlende Zeile allein nicht, dass die Rotation fehlgeschlagen ist.

Ersetzen Sie die Dateien, bevor das aktuelle Paar abläuft, damit Claude Code beim nächsten Start kein bereits abgelaufenes Paar lädt.

In Cloud-Sitzungen verwaltet die Hosting-Umgebung die Verbindung zur API, daher ignoriert Claude Code die folgenden Variablen, wenn sie aus einem env-Block einer Einstellungsdatei stammen:

  • CLAUDE_CODE_CLIENT_CERT
  • CLAUDE_CODE_CLIENT_KEY
  • CLAUDE_CODE_CLIENT_KEY_PASSPHRASE
  • NODE_EXTRA_CA_CERTS
  • NODE_TLS_REJECT_UNAUTHORIZED
  • CLAUDE_CODE_OAUTH_SCOPES

Claude Code notiert jeden ignorierten Schlüssel im Debug-Protokoll der Sitzung.

In Claude Desktop-Sitzungen, in denen die App die Provider-Verbindung verwaltet, z. B. die Registerkarte „Code“ auf einem Drittanbieter-Provider und Cowork-Sitzungen, liest Claude Code diese Variablen und die Proxy-Variablen HTTP_PROXY, HTTPS_PROXY und NO_PROXY nur aus verwalteten Einstellungen und ~/.claude/settings.json: Es ignoriert sie in den eigenen Einstellungsdateien eines Repositorys, daher kann ein ausgechecktes Repository den TLS- oder Proxy-Pfad einer Sitzung, deren Anmeldedaten von der App stammen, nicht umleiten. In einer lokalen, SSH- oder WSL-Code-Registerkarte-Sitzung, die sich über claude.ai anmeldet, verwaltet die App die Verbindung nicht, und Claude Code liest diese Variablen aus jedem Einstellungsbereich, wie jede Terminal-Sitzung; Cloud-Sitzungen folgen überall dort, wo Sie sie starten, den Cloud-Sitzungsregeln oben. Vor v2.1.217 ignorierte Claude Code diese Variablen in jeder Einstellungsdatei, wenn die App die Verbindung verwaltete.

Überprüfen Sie Ihre Konfiguration

Normalerweise erfahren Sie von einer falschen Proxy-Adresse oder einem ungültigen Zertifikatspfad durch einen Verbindungs- oder Zertifikatsfehler bei einer späteren Anfrage, da Claude Code die meisten dieser Einstellungen beim Lesen nicht validiert. Die einzige Einstellung, die beim Start überprüft wird, ist die Proxy-URL: Wenn Claude Code den Wert nicht analysieren kann, z. B. wenn das http://-Schema fehlt, stoppt Claude Code den Start mit einem Fehler, der die zu behebende Variable benennt.

Um zu bestätigen, dass Ihre Konfiguration geladen wurde, bevor Sie eine Anfrage senden, starten Sie Claude Code mit Debug-Protokollierung:

claude --debug

Die Debug-Ausgabe wird in ~/.claude/debug/<session-id>.txt statt im Terminal oder in einen Pfad geschrieben, den Sie mit --debug-file <path> festlegen. Suchen Sie im Protokoll nach den Zeilen, die bestätigen, dass jede Datei geladen wurde:

CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS (/etc/ssl/certs/corp-ca.pem)
mTLS: Loaded client certificate from CLAUDE_CODE_CLIENT_CERT
mTLS: Loaded client key from CLAUDE_CODE_CLIENT_KEY

Wenn Claude Code eine dieser Dateien nicht lesen kann, zeigt das Protokoll stattdessen eine Failed to read- oder Failed to load-Zeile mit dem Grund an.

Sie können auch /status in einer interaktiven Sitzung ausführen und diese Zeilen überprüfen:

  • Proxy: zeigt die aktive Proxy-URL an und markiert einen Wert, den es nicht analysieren kann, als ungültig und ignoriert.
  • mTLS client cert und mTLS client key: werden nur angezeigt, wenn die Dateien geladen wurden, daher bedeutet eine fehlende Zeile, dass das Laden fehlgeschlagen ist und das Debug-Protokoll den Grund enthält.
  • Additional CA cert(s): zeigt den NODE_EXTRA_CA_CERTS-Pfad an, ohne zu überprüfen, dass die Datei geladen wurde, daher bestätigen Sie diesen im Debug-Protokoll.

Netzwerkeinstellungen auf Hintergrund-Agenten anwenden

Hintergrund-Agenten werden nicht im Terminal ausgeführt, das sie gestartet hat. Ein benutzerspezifischer Supervisor-Prozess wird bei Bedarf gestartet, überlebt Ihre Shell und hostet jede claude agents-, --bg- und /background-Sitzung. Siehe Wie Hintergrund-Sitzungen gehostet werden. Dies ändert, wie die Konfiguration auf dieser Seite diese Sitzungen erreicht.

Netzwerkvariablen in Einstellungen festlegen, nicht in der Shell

Der Supervisor ist ein Prozess, der von jedem Terminal gemeinsam genutzt wird. Er erbt die Umgebung der Shell, die ihn zuerst startet. Wenn Sie eine Proxy-, CA-Pfad- oder mTLS-Variable nur in Ihrer Shell exportieren, erreicht sie Hintergrund-Agenten, wenn diese Shell den Supervisor kalt gestartet hat, und erreicht sie stillschweigend nicht, wenn eine andere Shell dies getan hat.

Legen Sie stattdessen die gleichen Variablen im env-Block von ~/.claude/settings.json oder in verwalteten Einstellungen fest. Jede Variable auf dieser Seite kann dort festgelegt werden, und Einstellungen sind die einzige Konfiguration, die jede Hintergrund-Sitzung auf jedem Computer erreicht.

Einen Corporate Launcher als Einstellung konfigurieren

Einige Organisationen erfordern, dass jeder Claude Code-Prozess über einen Corporate Launcher gestartet wird, der Sandboxing, Netzwerkkontrollen oder Credential Injection anwendet. Der Supervisor und seine Worker starten Claude Code von einem festen Pfad aus, anstatt claude auf PATH nachzuschlagen, sodass jeder Hintergrund-Agent einen Wrapper umgeht, den Sie früher auf PATH platziert haben.

Legen Sie die Einstellung processWrapper fest, um den Supervisor, seine Worker und die anderen unter Was der Launcher abdeckt aufgelisteten Hintergrund-Prozesse mit Ihrem Launcher zu präfixieren. Die entsprechende Umgebungsvariable CLAUDE_CODE_PROCESS_WRAPPER hat Vorrang, wenn beide festgelegt sind, und unterliegt der gleichen Regel: Liefern Sie sie über verwaltete Einstellungen oder ~/.claude/settings.json, nicht über einen Shell-Export. Claude Code hinter einem Corporate Launcher ausführen behandelt den Vertrag, den der Launcher erfüllen muss, was er erreicht und nicht erreicht, und wie Sie ihn bereitstellen.

[!NOTE]

Ein bereits laufender Supervisor behält die Startkonfiguration, mit der er gestartet wurde. Nach der Bereitstellung der Launcher-Einstellung führen Sie claude daemon stop --any aus, damit der nächste claude agents oder --bg einen Supervisor startet, der sie berücksichtigt.

Streaming-Idle-Watchdogs

Claude Code betreibt vier unabhängige Timer, die eine streamende Modellantwort abbrechen, wenn sie verstummt, sodass eine tote Verbindung fehlschlägt und erneut versucht wird, statt zu hängen. Eine Anfrage, die überhaupt keine Response-Header erhält, endet auf eine von zwei Arten:

  • Wo die First-Byte-Frist läuft: Der erste Versuch endet spätestens mit Ablauf dieser Frist. Um sie zu ändern, setzen Sie CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS. Zur Wartezeit des Wiederholungsversuchs siehe No response from API.
  • Auf den anderen Verbindungen: Die Anfrage endet nach 5 bis 6 Minuten, wenn der Body-Idle-Timeout auslöst, sofern Sie diesen Timeout nicht ausgeschaltet haben. Um sie früher zu beenden, verringern Sie API_TIMEOUT_MS. In einer Claude-Apps-Gateway-Sitzung können Sie den ersten Versuch stattdessen früher beenden, indem Sie die First-Byte-Frist einschalten.
Timer Bricht ab, wenn Läuft auf Standard-Timeout
First-Byte-Frist Nach dem Senden der Anfrage durch Claude Code keine Response-Header eintreffen Direkte Anthropic API und Claude Platform on AWS, auch über einen HTTPS-Proxy, jedoch nicht, wenn ANTHROPIC_BASE_URL oder ANTHROPIC_AWS_BASE_URL sie über ein Gateway leiten. Per Opt-in für eine Claude-Apps-Gateway-Sitzung sowie auf Amazon Bedrock mit CLAUDE_ENABLE_BYTE_WATCHDOG_BEDROCK=1; läuft nicht auf der Agent Platform von Google Cloud oder Microsoft Foundry 180 Sekunden auf der direkten Anthropic API und 300 Sekunden auf Claude Platform on AWS oder Amazon Bedrock, zuzüglich einer Sekunde pro 32 KB Request-Body
Watchdog auf Ereignisebene Keine Antwortereignisse geparst werden. Wo der Watchdog auf Byte-Ebene auf einer anderen Verbindung als Amazon Bedrock läuft, setzen eintreffende Bytes, einschließlich Keep-alive-Pings, diesen Watchdog ebenfalls zurück, und zwar für eine begrenzte Zeit ohne geparstes Ereignis. Diese Zeit beträgt etwa fünf Minuten, wenn mindestens alle 10 Sekunden Bytes eintreffen. Bei den 15-Sekunden-Pings eines Claude-Apps-Gateways sind es etwa 7,5 Minuten, sodass ein Stream, der nur aus Pings besteht, beim Standard-Timeout nach etwa 12,5 Minuten endet. Jedem Anbieter 300 Sekunden
Watchdog auf Byte-Ebene Keine Bytes auf der Leitung eintreffen, einschließlich SSE-Keep-alive-Pings Direkte Anthropic API, Claude Platform on AWS und Gateway-Verbindungen, einschließlich einer benutzerdefinierten ANTHROPIC_BASE_URL. Auf Amazon-Bedrock-Antworten vom Typ vnd.amazon.eventstream per Opt-in mit CLAUDE_ENABLE_BYTE_WATCHDOG_BEDROCK=1; läuft nicht auf der Agent Platform von Google Cloud oder Microsoft Foundry 180 Sekunden auf der direkten Anthropic API. 300 Sekunden auf Claude Platform on AWS, auf Amazon Bedrock, in einer Claude-Apps-Gateway-Sitzung und über eine benutzerdefinierte ANTHROPIC_BASE_URL
Body-Idle-Timeout 5 Minuten lang keine Bytes eintreffen, einschließlich der Wartezeit auf Response-Header Anderen Anbietern als der direkten Anthropic API, Claude Platform on AWS und Amazon Bedrock mit gesetztem CLAUDE_ENABLE_BYTE_WATCHDOG_BEDROCK=1, sofern API_FORCE_IDLE_TIMEOUT dies nicht ändert 5 Minuten

Wenn Sie CLAUDE_ENABLE_BYTE_WATCHDOG_BEDROCK=1 setzen, ersetzt der Watchdog auf Byte-Ebene auf Bedrock den Body-Idle-Timeout, statt parallel dazu zu laufen. CLAUDE_STREAM_IDLE_TIMEOUT_MS bestimmt dann auch, wie lange ein Bedrock-Stream still bleiben darf, bevor Claude Code die Verbindung als tot betrachtet, innerhalb der unten aufgeführten Grenzen. Eintreffende Bytes setzen den Watchdog auf Ereignisebene auf Bedrock weiterhin nicht zurück. Bei aktiviertem Debug-Logging protokolliert dann jeder Bedrock-Stream eine Debug-Meldung, die mit wire-heartbeat: _chunkTimes absent beginnt.

Konfigurieren Sie die Timer mit diesen Variablen, die jeweils in der Referenz der Umgebungsvariablen beschrieben sind:

  • CLAUDE_ENABLE_STREAM_WATCHDOG und CLAUDE_ENABLE_BYTE_WATCHDOG schalten den entsprechenden Watchdog mit 1 zwangsweise ein oder mit 0 aus, und zwar innerhalb der Verbindungen, die die Tabelle aufführt; keine der beiden Variablen erweitert einen Watchdog auf einen Verbindungstyp, den er nicht abdeckt. CLAUDE_ENABLE_BYTE_WATCHDOG auf 0 gesetzt schaltet auch die First-Byte-Frist aus.
  • CLAUDE_STREAM_IDLE_TIMEOUT_MS legt den Timeout beider Watchdogs fest. Claude Code hebt Werte unter 5 Minuten auf 5 Minuten an und begrenzt den Wert für den Watchdog auf Byte-Ebene auf 30 Minuten.
  • CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS legt den Timeout des Watchdogs auf Byte-Ebene fest, ohne den des Watchdogs auf Ereignisebene zu ändern, begrenzt auf einen Wert zwischen 10 Sekunden und 30 Minuten, und hat für diesen Watchdog Vorrang vor CLAUDE_STREAM_IDLE_TIMEOUT_MS.
  • CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS legt die First-Byte-Frist fest. In einer Claude-Apps-Gateway-Sitzung setzen Sie diese Variable, um die Frist einzuschalten. Wenn Sie die Variable auf einer anderen Verbindung, auf der die Frist läuft, nicht setzen, verwendet Claude Code den Timeout des Watchdogs auf Byte-Ebene, sodass CLAUDE_STREAM_IDLE_TIMEOUT_MS und CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS die Frist ebenfalls ändern. Zu den Begrenzungen des Werts siehe No response from API.
  • API_TIMEOUT_MS begrenzt die Wartezeit auf Response-Header, nicht wie lange eine Antwort danach streamt. Wo die First-Byte-Frist nicht läuft, setzen Sie API_TIMEOUT_MS auf einen positiven Wert unter 300000, um eine unbeantwortete Anfrage in weniger als 5 Minuten erneut zu versuchen. Halten Sie API_TIMEOUT_MS über der längsten Wartezeit auf Header und der längsten Nicht-Streaming-Anfrage, die Sie erwarten: Eine Anfrage, die länger braucht, läuft bei jedem Wiederholungsversuch erneut in den Timeout.
  • API_FORCE_IDLE_TIMEOUT auf 0 gesetzt schaltet den Body-Idle-Timeout aus, und auf 1 gesetzt schaltet es ihn für jeden Anbieter ein. Die Watchdogs laufen unabhängig davon; damit ein Stream länger als ihre Schwellenwerte pausieren kann, müssen Sie sie also ebenfalls erhöhen oder deaktivieren.

Wenn ein Watchdog einen blockierten Stream abbricht, behandelt Claude Code den Abbruch als Fehler während des Streams, und was Sie sehen, hängt davon ab, wie weit die Antwort bereits gekommen war. Claude Code versucht die Anfrage erneut oder beendet den Turn mit einem Fehler, behält die abgeschlossene Ausgabe und zeigt einen Hinweis auf eine unvollständige Antwort an oder beendet den Turn normal. Automatische Wiederholungsversuche erläutert, wo welches Ergebnis gilt.

In einer nicht interaktiven Sitzung sowie bei der Antwort eines Subagenten in jeder Sitzung fordert Claude Code Claude möglicherweise zunächst per Prompt auf, die abgeschnittene Antwort fortzusetzen; der Eintrag zu diesem Hinweis erläutert, wann dies geschieht und wann Sie den Hinweis dennoch sehen.

Wenn die First-Byte-Frist auslöst, hat noch keine Antwort begonnen, sodass es keine Teilausgabe gibt, die behalten werden könnte. Wie Claude Code die Anfrage erneut sendet und wann stattdessen der Turn endet, erfahren Sie unter No response from API.

Anforderungen für Netzwerkzugriff

Claude Code benötigt Zugriff auf die folgenden URLs. Fügen Sie diese in Ihrer Proxy-Konfiguration und Firewall-Regeln zur Allowlist hinzu, besonders in containerisierten oder Netzwerken mit eingeschränktem Zugriff. Die Konnektivitätsprüfung beim ersten Start verweist hier hin, wenn sie api.anthropic.com oder platform.claude.com nicht erreichen kann; siehe Unable to connect to Anthropic services für die Meldungen der Prüfung und Wiederherstellungsschritte.

URL Erforderlich für
api.anthropic.com Claude API-Anfragen, einschließlich der WebFetch Domänensicherheitsprüfung, Feature-Flag-Abrufe und Telemetrie-Ereignisprotokollierung
claude.ai claude.ai-Kontoauthentifizierung
claude.com claude.ai-Kontoanmeldung öffnet eine claude.com-Seite im Browser, die zu claude.ai umleitet; vorab genehmigte WebFetch-Dokumentationssuchen erreichen diesen Host auch von der CLI aus
platform.claude.com Anthropic Console-Kontoauthentifizierung. OAuth-Token-Austausch, Aktualisierung und Widerruf gehen auch zu diesem Host für claude.ai-Konten, daher erfordern sowohl Console- als auch claude.ai-Anmeldungen ihn
sso.claude.com Teil des Browser-Anmeldeablaufs für Organisationen, die Single Sign-On (SSO) verwenden. Wenn ein Proxy diesen Host blockiert, können diese Anmeldungen fehlschlagen
mcp-proxy.anthropic.com MCP-Konnektoren von claude.ai, einschließlich Konnektoren, die ein Organisationsadministrator konfiguriert. Der Konnektordatenverkehr wird durch diesen Proxy geleitet; Konnektoren sind standardmäßig für claude.ai-authentifizierte Benutzer aktiviert. Um Claude Code daran zu hindern, sie abzurufen, setzen Sie ENABLE_CLAUDEAI_MCP_SERVERS=false oder die Einstellung disableClaudeAiConnectors
downloads.claude.ai Plugin-Executable-Downloads; nativer Installer, nativer Auto-Updater und Versionsprüfungen
storage.googleapis.com Plugin-Installationszähler und Metadaten, die in /plugin angezeigt werden
storage.googleapis.com Nativer Installer und nativer Auto-Updater in Versionen vor 2.1.116
registry.npmjs.org Plugin-Installationen (Abrufen von npm-Quell-Plugin-Paketen und Installation von Node.js-Paketabhängigkeiten von Plugins), npx-gestartete MCP-Server und die Paketregistrierung für npm- und bun-Installationen von Claude Code selbst
bridge.claudeusercontent.com Claude in Chrome Erweiterungs-WebSocket-Bridge
*.frame.claudeusercontent.com Artifact Inhaltslesevorgänge. Die CLI ruft die Dateien eines Artifacts von diesem Host ab, wenn Claude eines öffnet, und nur wenn das Artifact-Tool verfügbar für Ihr Konto ist. Um das Tool auszuschalten und diese Anforderung zu entfernen, setzen Sie "enableArtifact": false oder CLAUDE_CODE_DISABLE_ARTIFACT=1
github.com Klonen von GitHub-gehosteten Plugin-Marktplätzen und Plugins, einschließlich des offiziellen Anthropic-Marktplatzes, über HTTPS oder SSH. Um GitHub owner/repo Quellen nur über HTTPS zu klonen, setzen Sie CLAUDE_CODE_PLUGIN_PREFER_HTTPS=1
raw.githubusercontent.com Changelog-Feed für /release-notes. In interaktiven Sitzungen ruft Claude Code ihn auch beim Start im Hintergrund ab, wenn sein zwischengespeichertes Changelog die laufende Version noch nicht abdeckt, z. B. beim ersten Start nach einem Update; nicht-interaktive und Cloud-Sitzungen rufen ihn nie ab
*-review.googlesource.com Gerrit-Änderungssuche bei googlesource.com-Checkouts. Wenn eine Claude Desktop Code-Tab-Sitzung auf einem vertrauenswürdigen Checkout startet oder fortgesetzt wird, dessen origin ein googlesource.com-Host ist, fragt Claude Code diesen Host's -review-Server anonym nach der offenen Änderung, die HEADs Change-Id entspricht, einmal pro Start oder Fortsetzung. Andere Sitzungstypen überspringen die Suche, und kein anderer Gerrit-Host wird kontaktiert. Optional: deaktivieren mit CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC
http-intake.logs.us5.datadoghq.com Operationale Telemetrie-Ereignisse, die nur gesendet werden, wenn die CLI die Anthropic API direkt nutzt, niemals für Amazon Bedrock, Google Cloud's Agent Platform oder Microsoft Foundry. Optional: deaktivieren mit DISABLE_TELEMETRY oder DO_NOT_TRACK
browser-intake-us5-datadoghq.com Operationale Fehlerberichte, die gesendet werden, wenn die CLI die Anthropic API direkt nutzt und ein serverseitiges Rollout-Gate sie aktiviert. Optional: deaktivieren mit DISABLE_ERROR_REPORTING oder DISABLE_TELEMETRY; siehe Telemetry services
formulae.brew.sh Versionsprüfungen auf Homebrew-Installationen aktualisieren. Andere Installationsmethoden kontaktieren diesen Host nicht
code.claude.com Claude Code-Dokumentationssuchen durch den integrierten claude-code-guide-Agent und vorab genehmigte WebFetch-Anfragen. Das Blockieren dieses Hosts betrifft nur Dokumentationssuchen

Wenn Sie Claude Code über npm installieren oder Ihre eigene Binärverteilung verwalten, benötigen Endbenutzer nicht die nativen Installer- und Auto-Updater-Verwendungen von downloads.claude.ai, aber npm- und bun-Installationen benötigen ihre Paketregistrierung, registry.npmjs.org, es sei denn, Ihre Organisation spiegelt sie. Die anderen Verwendungen in der Tabelle gelten unabhängig von der Installationsmethode.

Die beiden Datadog-Intake-Hosts tragen nur optionale operationale Telemetrie, und das Setzen von CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC deaktiviert beide. Sitzungen bei Drittanbietern senden niemals an diese Hosts, auch wenn eine Plattform CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST setzt und Telemetrie-Metriken standardmäßig aktiviert sind. Siehe Telemetry services für alles, was Claude Code sendet, und wie Sie es deaktivieren, bevor Sie Ihre Allowlist finalisieren.

Bei Verwendung von Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry oder einer angemeldeten Claude apps gateway Sitzung gehen Modellverkehr und Authentifizierung stattdessen zu Ihrem Anbieter oder Gateway anstelle von api.anthropic.com, claude.ai oder platform.claude.com. Das WebFetch-Tool ruft immer noch api.anthropic.com für seine Domänensicherheitsprüfung auf, es sei denn, Sie setzen skipWebFetchPreflight: true in settings.

Beim Routing durch ein LLM gateway mit ANTHROPIC_BASE_URL ruft die fast mode Verfügbarkeitsprüfung immer noch api.anthropic.com anstelle der Gateway-Basis-URL auf. Die Prüfung berücksichtigt einen konfigurierten HTTP-Proxy, daher ist ein Allowlist-Eintrag für api.anthropic.com im Proxy die Lösung, wenn eine Netzwerkblockade die Ursache ist. Eine Netzwerkblockade schlägt die Prüfung nur fehl, wenn der Host selbst durch den Proxy nicht erreichbar ist, und fast mode meldet dann einen Konnektivitätsfehler. Der gleiche Konnektivitätsfehler tritt auf, wenn die Prüfung eine vom Gateway ausgestellte Anmeldedaten präsentiert, die Anthropic ablehnt; Allowlisting hilft dort nicht, da nichts blockiert ist. Siehe use fast mode behind proxies and LLM gateways für die Variablen, die es wiederherstellen.

Organisations-IP-Allowlists und Proxy-Ausgang

Wenn Ihre Organisation IP allowlisting für Claude aktiviert hat, leiten Sie bridge.claudeusercontent.com durch den gleichen Proxy-Ausgang wie claude.ai und api.anthropic.com, z. B. indem Sie es in das gleiche Zscaler-App-Segment oder die gleiche Netskope-Steering-Richtlinie platzieren. Wenn Sie es nicht auf diese Weise leiten können, fügen Sie die Ausgangsadresse, die Ihr Proxy für diesen Host verwendet, zu Ihrer Organisations-IP-Allowlist hinzu, aber nur wenn diese Adresse Ihrer Organisation gewidmet ist: ein gemeinsamer Proxy-Ausgangsbereich lässt auch andere Kunden des Proxy-Anbieters zu.

Anthropic überprüft Verbindungen zu bridge.claudeusercontent.com gegen Ihre Organisations-IP-Allowlist unter Verwendung der Adresse, von der sie ankommen. Wenn Ihr Proxy Datenverkehr für diesen Host durch eine Adresse sendet, die nicht auf dieser Allowlist steht, kann Claude Code keine Verbindung zur Claude in Chrome Erweiterung herstellen, obwohl der Rest von Claude Code funktioniert.

GitHub-Allowlists und Firewalls

Cloud sessions in von Anthropic gehosteten Umgebungen und Code Review verbinden sich mit Ihren Repositories von verwalteter Anthropic-Infrastruktur aus; Sitzungen in einer selbstgehosteten Umgebung verbinden sich von innerhalb Ihres Netzwerks, es sei denn, der Runner entscheidet sich für den Anthropic git proxy, der von Anthropics Seite abruft.

Wenn Ihre GitHub Enterprise Cloud-Organisation den Zugriff nach IP-Adresse einschränkt, aktivieren Sie IP allow list inheritance for installed GitHub Apps und add an allow list entry für Anthropics outbound IP addresses. Die Vererbung deckt nur die Anfragen ab, die die Claude GitHub App als Installation macht, nicht die Anfragen, die sie im Namen Ihrer Benutzer macht. Für andere Firewalls siehe die Anthropic API IP addresses.

Für selbstgehostete GitHub Enterprise Server Instanzen hinter einer Firewall, allowlisten Sie Anthropics outbound IP addresses, damit Anthropic-Infrastruktur Ihren GHES-Host erreichen kann, um Repositories zu klonen und Review-Kommentare zu posten. Sitzungen in einer selbstgehosteten Umgebung erreichen Ihren GHES-Host stattdessen von innerhalb Ihres Netzwerks, daher gilt diese Exposition nur für von Anthropic gehostete Sitzungen, für gehostete Pre-Session-Flows wie den Repository-Picker und für selbstgehostete Runner, die sich für den Anthropic git proxy entscheiden, der von Anthropics Seite abruft. Der SCM connector ist nicht verfügbar, daher können die gehosteten Pre-Session-Flows keinen GHES-Host erreichen, der nur innerhalb Ihres Netzwerks erreichbar ist.

Desktop und claude.ai

Die vorherige Tabelle deckt die eigenständige CLI ab. Die Claude Desktop-App und claude.ai in einem Browser laden ihren Anwendungscode und Benutzerinhalte von zusätzlichen Anthropic CDN-Hosts, einschließlich assets-proxy.anthropic.com und der anderen *.claudeusercontent.com Ursprünge, die artifacts in diesen Apps bereitstellen. Das Zulassen von claude.ai bei gleichzeitiger Blockierung dieser Hosts führt zu einer leeren Seite statt eines Fehlers. Siehe network access requirements auf der Desktop-Seite.

Claude Desktop und claude.ai stellen außerdem einige Tool-Ergebnisse innerhalb einer Konversation als interaktive Widgets dar, etwa die MCP Apps, die einige Konnektoren bereitstellen. Diese Widgets werden von generierten Subdomains von claudemcpcontent.com geladen. Lassen Sie daher *.claudemcpcontent.com einschließlich des Platzhalters zu. Wenn Sie es blockieren, funktioniert der Rest der App weiterhin, aber diese Widgets werden nicht geladen.

Drittanbieter-Hosts für Artefakt-Schriftarten und -Bibliotheken

Ein artifact, das eine Schriftart von Google Fonts lädt, fordert auch fonts.googleapis.com und fonts.gstatic.com an. Beide Hosts sind optional. Wenn Sie sie blockieren, werden Artifacts in Fallback-Schriftarten gerendert. Blockieren Sie mit einer schnellen Ablehnung statt eines stillen Verwerfens, damit die Schriftartanfrage sofort fehlschlägt, anstatt das erste Rendering der Seite zu verzögern.

Artifacts können auch JavaScript-Bibliotheken wie React oder ein Charting-Paket von cdnjs.cloudflare.com, cdn.jsdelivr.net, cdn.tailwindcss.com, code.jquery.com und unpkg.com laden und von keinem anderen externen Host. Wenn Sie diese Hosts blockieren, funktionieren die Teile eines Artifacts, die von einer Bibliothek abhängen, nicht, und im Gegensatz zu einer blockierten Schriftart hat eine blockierte Bibliothek keinen Fallback. Blockieren Sie auch hier mit einer schnellen Ablehnung, damit eine blockierte Bibliotheksanfrage sofort fehlschlägt, anstatt zu hängen, bis sie abläuft.

Zusätzliche Ressourcen