Bereitstellung und Betrieb des Claude-Apps-Gateways

Diese Seite behandelt den operativen Aspekt des Betriebs des Claude-Apps-Gateways: Registrierung eines OAuth-Clients bei Ihrem Identitätsanbieter (IdP), Bereitstellung des Gateways als Container und täglicher Betrieb. Für jede Option in der Datei gateway.yaml, die das Gateway beim Start liest, siehe die Konfigurationsreferenz. Eine Produktionsbereitstellung folgt vier Schritten in der richtigen Reihenfolge, und die folgenden Abschnitte entsprechen ihnen. Die ersten beiden sind Stellen, an denen Sie Entscheidungen treffen; die zweiten beiden sind Referenzmaterial, das Sie konsultieren können, sobald es läuft.

1. Richten Sie Ihren Identitätsanbieter ein: Registrieren Sie den OAuth-Client und überprüfen Sie die IdP-spezifischen Hinweise für Okta, Entra und Google
2. Stellen Sie das Gateway bereit: Erstellen Sie ein gepinntes Container-Image und führen Sie es auf Kubernetes, Cloud Run oder Ihrer eigenen Plattform aus. Dieser Abschnitt behandelt auch Kosten-, Bypass-, Multi-Gateway- und Serverless-Entscheidungen
3. Richten Sie den Betrieb ein: Protokolle, Integritätsprüfungen, Ausfallverhalten, Geheimnisrotation und Upgrades. Referenzmaterial für die Einrichtung von Überwachung und Runbooks
4. Überprüfen Sie die Sicherheitslage: Welche Daten wohin fließen, das Bedrohungsmodell und Compliance-Antworten. Referenzmaterial für eine Sicherheitsüberprüfung

Wenn ein Anmelde- oder Startfehler auftritt, gehen Sie direkt zu Fehlerbehebung, das nach dem Fehler, den Sie sehen, indiziert ist.

​

Identitätsanbieter-Setup

Registrieren Sie eine vertrauliche OAuth/OpenID Connect (OIDC) Webanwendung mit einem einzelnen Redirect-URI, https://<gateway>/oauth/callback, und weisen Sie sie den Benutzern oder Gruppen zu, die Zugriff auf das Gateway haben sollten. Jeder OIDC-konforme IdP funktioniert: Okta, Microsoft Entra ID, Google Workspace, Keycloak, Dex, PingFederate und andere. Der IdP muss drei Anforderungen erfüllen:

• Stellt /.well-known/openid-configuration über HTTPS in der Produktion bereit; das Gateway akzeptiert einen http:// Aussteller, und ein Loopback-Aussteller erfordert zusätzlich CLAUDE_GATEWAY_ALLOW_LOOPBACK=1
• Unterstützt den Authorization-Code-Flow. PKCE (Proof Key for Code Exchange) ist standardmäßig aktiviert; deaktivieren Sie es mit oidc.use_pkce: false für IdPs, die es nicht unterstützen
• Gibt email und optional groups im id_token zurück, oder stellt sie vom Userinfo-Endpoint mit oidc.userinfo_fallback: true bereit

Für private PKI setzen Sie oidc.ca_cert_pem. Einige Anbieter handhaben E-Mail- und Gruppen-Claims unterschiedlich:

• Okta: Der Org-Autorisierungsserver unter https://example.okta.com gibt einen dünnen id_token zurück, der email und groups auslässt, daher setzen Sie oidc.userinfo_fallback: true, wenn Sie ihn als issuer verwenden. Ein benutzerdefinierter Autorisierungsserver wie https://example.okta.com/oauth2/default, der email und optional groups im id_token enthält, gibt sie direkt aus und benötigt keinen Fallback. Okta gibt groups nur aus, wenn der groups-Scope in oidc.scopes angefordert wird und der Gruppen-Claim-Filter der App dies zulässt; userinfo_fallback kann einen Claim nicht ausfüllen, nach dem der IdP nicht gefragt wurde.
• Microsoft Entra ID: issuer = https://login.microsoftonline.com/<tenant-id>/v2.0. Entra gibt Gruppen-Object-IDs statt Namen aus, daher verwenden Sie die GUIDs in managed.policies.match.groups, oder verwenden Sie App-Rollen für lesbare Namen. Wenn Ihr Mandant Rollen unter roles statt groups ausgibt, setzen Sie oidc.groups_claim: roles.
• Google Workspace: issuer = https://accounts.google.com. Googles id_token enthält keine Gruppen. Um gruppenbasierte allowed_groups oder managed.policies mit Google als IdP zu verwenden, konfigurieren Sie oidc.google_groups, das die Gruppen jedes Benutzers über die Admin SDK Directory API mit einem Service-Account mit Domain-Wide-Delegation nachschlägt. Ohne dies verwenden Sie oidc.allowed_email_domains für Mitgliedschafts-Gating und managed.policies.match.email_domain für Richtlinienzuweisung. Google ignoriert auch den Standard-Scope offline_access. Für Refresh-Tokens setzen Sie oidc.scopes: [openid, profile, email] und oidc.extra_auth_params: { access_type: offline, prompt: consent }.

Für Unterstützung bei einem oben nicht behandelten Identitätsanbieter siehe Troubleshooting.

​

Bereitstellung

Das Gateway ist eine einzelne Linux-Binärdatei. Es skaliert horizontal, da Replikationen zustandslos sind und Postgres die gemeinsame Koordinierungsebene ist. Führen Sie es so aus, wie Sie zustandslose Dienste in Ihrer Umgebung ausführen. Der Rest dieses Abschnitts beschreibt, was das Image benötigt, mit kurzen Hinweisen für Kubernetes und Cloud Run. Das Gateway ist für die Ausführung in Ihrem Netzwerk konzipiert, da es Ihre Upstream-Anmeldedaten hält und als einzelner Egress-Punkt für Inferenz fungiert. Es kann überall dort ausgeführt werden, wo Ihre Entwickler und Ihr IdP über HTTPS erreichbar sind; behandeln Sie es wie jeden anderen Dienst, der eine Produktionsanmeldedaten hält. Einige Entscheidungen prägen die Bereitstellung über den Ort hinaus, an dem sie läuft:

• Kosten: Es gibt keine separate Lizenz oder Pro-Sitz-Gebühr für das Gateway; es ist Teil der claude-Binärdatei. Sie zahlen für Inferenz über Ihr bestehendes Cloud- oder Anthropic-Engagement, plus die Berechnung für den Container und Ihren Telemetrie-Collector.
• Bypass: Das Gateway erzwingt nicht, dass die einzige Route zu einem Modell durch es führt. Ein Entwickler mit seinen eigenen Anmeldedaten kann den Anbieter immer noch direkt aufrufen, daher ist das Schließen dieses Pfads eine Netzwerkrichtlinien-Entscheidung, z. B. das Blockieren von Egress zu api.anthropic.com außer vom Gateway. Das Blockieren dieses Egress bricht auch die WebFetch-Domain-Sicherheitsprüfung, die api.anthropic.com von jeder Entwicklermaschine aufruft; setzen Sie skipWebFetchPreflight: true in der verwalteten Richtlinie, um sie zu deaktivieren.
• Mehrere Gateways: Jedes Gateway ist eine separate Bereitstellung mit seiner eigenen Konfiguration. Die CLI speichert ihren Vertrauens-Fingerprint und ihre Anmeldedaten pro Gateway-Hostname, daher können verschiedene Teams sich mit verschiedenen Gateways verbinden, ohne Konflikte. Um mehrere OIDC-Aussteller zu bedienen, führen Sie separate Instanzen aus.
• Serverless: Cloud Run funktioniert; setzen Sie min-instances: 1, um kalte OIDC-Erkennung zu vermeiden. Lambda und Cloud Functions funktionieren nicht, da das Gateway ein langlebiger HTTP-Server ist.

Jede Produktionstopologie hier platziert einen L7-Proxy, wie einen Ingress, Cloud Runs Front-End oder einen ALB, vor einfachen HTTP-Replikationen. Setzen Sie listen.trusted_proxies auf die Quellbereiche des Proxys, damit das Gateway Client-IPs aus X-Forwarded-For liest. Das Gateway ehrt den Header nur, wenn der TCP-Peer vertrauenswürdig ist; das Google Cloud-Beispiel hat konkrete Werte pro Topologie. Ohne vertrauenswürdige Proxys scheint jede Anfrage von der IP des Proxys zu kommen, was Pro-IP-Ratenlimits in einen gemeinsamen Bucket zusammenfasst und die IP des Proxys in Audit-Events aufzeichnet.

​

Container-Image

Erstellen Sie Ihr eigenes Image um die native claude-Binärdatei aus der Standard-Claude-Code-Version:

1. Laden Sie den Linux-Build für Ihre Image-Architektur aus einer gepinnten Version herunter; siehe Installieren Sie eine bestimmte Version für die Download-URL.
2. Überprüfen Sie es gegen die GPG-signierte manifest.json der Version, wie in Binäre Integrität und Code-Signierung beschrieben.
3. Kopieren Sie es in den Build-Kontext.

Spiegeln Sie die Version in Ihre interne Registry, wenn Ihre Builds den Release-Host nicht erreichen können, und pinnen Sie die Version, die Ihre Flotte ausführt. Über die Binärdatei hinaus benötigt das Image:

• Ein glibc-basiertes Image: Die einzigen dynamischen Abhängigkeiten des glibc-Builds sind glibc-Bibliotheken. Musl-basierte Images benötigen den linux-x64-musl- oder linux-arm64-musl-Build plus zusätzliche Pakete; siehe Alpine-Linux-Setup.
• Ein beschreibbares Zustandsverzeichnis: Das Gateway läuft als jeder Benutzer, aber minimale Images haben kein beschreibbares Home. Setzen Sie CLAUDE_CONFIG_DIR auf einen beschreibbaren Pfad wie /tmp/.claude.
• Der Container-Befehl: claude gateway --config /etc/claude/gateway.yaml, mit der Konfigurationsdatei schreibgeschützt eingebunden und Geheimnissen als Umgebungsvariablen bereitgestellt; das Gateway lauscht auf listen.port, Standard 8080.

​

Kubernetes

Führen Sie das Gateway als Deployment aus, wie jeden zustandslosen Dienst:

• Binden Sie die Konfiguration von einer ConfigMap und Geheimnisse von einem Secret ein; referenzieren Sie Geheimnisse in der YAML über ${file:/path/to/secret} oder als Umgebungsvariablen
• Beenden Sie TLS am Ingress und setzen Sie listen.public_url auf den Ingress-Hostnamen
• Zeigen Sie die Readiness-Probe auf GET /readyz und die Liveness-Probe auf GET /healthz

​

Cloud Run

Konfigurieren Sie den Dienst wie folgt:

• Lassen Sie listen.port bei seinem Standard von 8080, das Cloud Runs Standard-PORT entspricht, oder setzen Sie port: ${PORT}
• Setzen Sie public_url auf den extern erreichbaren Ursprung. Für die Produktion ist dies normalerweise der Hostname eines internen Load Balancers, da /login öffentliche Adressen ablehnt und die *.run.app-URL zu einer aufgelöst wird, daher funktioniert die Cloud-Run-URL allein nur für einen curl- oder Browser-Smoke-Test. Die Ausnahme ist ein Netzwerk, in dem *.run.app privat über Private Service Connect und eine Cloud-DNS-Private-Zone aufgelöst wird; in dieser Topologie ist die Cloud-Run-URL eine gültige public_url. Das Google-Cloud-Beispiel behandelt beide.
• Binden Sie die Konfiguration als Secret-Volume ein
• Setzen Sie min-instances: 1, um kalte OIDC-Erkennung bei der ersten Anfrage zu vermeiden

​

Pushen Sie die Gateway-URL zu Entwicklermaschinen

Sobald das Gateway bedient wird, pushen Sie forceLoginMethod und forceLoginGatewayUrl über verwaltete Einstellungen auf jede Entwicklermaschine, über MDM oder durch direktes Schreiben der pro-OS managed-settings.json. Ohne dies zeigt /login den Standard-Account-Picker ohne Gateway-Option. Siehe Client-seitige verwaltete Einstellungen für die Dateipfade.

​

Betrieb

Sobald das Gateway Verkehr bedient, ist der tägliche Betrieb das Lesen seiner Protokolle, das Prüfen seiner Integrität und das Rotieren seiner Geheimnisse nach Ihrem Zeitplan. Die Unterabschnitte behandeln jeweils, plus was Postgres hält und wie Upgrades und Rollbacks sich verhalten.

​

Protokolle

Das Gateway schreibt zwei Streams zu stderr, beide JSON-freundlich:

• Audit-Events: einzeilige JSON pro sicherheitsrelevantes Event. Leiten Sie stderr an Ihren Log-Aggregator. Die ausgegebenen Events umfassen config.load, session.mint, session.refresh, device.authorize, device.verify, auth.denied, access.denied, inference, managed.serve, spend.blocked und admin.denied. Felder variieren je nach Event:
  • Erfolgreiche Mint- und Refresh-Events tragen sub, email, client_ip und das Ergebnis
  • Denial-Events tragen den Grund, Pfad und Client-IP, da bei Denial keine Identität existiert
  • inference zeichnet auf, welcher Upstream die Anfrage bedient hat und den Antwortstatus
  • admin.denied zeichnet einen abgelehnten Admin-API-Auth-Versuch mit dem Grund (invalid_key oder no_credentials), Client-IP, Methode und Pfad auf, ohne das präsentierte Schlüsselmaterial
• Operationale Protokolle: lesbare [gateway]-präfixierte Zeilen für Boot, Warnungen und Upstream-Fehler. Die Umgebungsvariable CLAUDE_GATEWAY_LOG_LEVEL steuert die Ausführlichkeit und akzeptiert info, warn oder error, mit info als Standard. Sie beeinflusst keine Audit-Events, die immer ausgegeben werden.

​

Integrität

Das Gateway bedient GET /healthz als Liveness-Probe und GET /readyz als Readiness-Probe; /readyz überprüft, dass der Store erreichbar ist. Beide sind von access_control.allow_cidrs ausgenommen, daher funktionieren Proben auf einem abgesperrten Listener. Das OAuth-Discovery-Dokument unter /.well-known/oauth-authorization-server gibt auch 200 nur zurück, nachdem Konfigurationslast, OIDC-Erkennung, Upstream-Client-Konstruktion und Postgres-Migration alle erfolgreich sind, daher dient es auch als End-to-End-Boot-Prüfung. Ein laufendes Gateway bedient auch eine Beschreibung der Pfade und Anfragefiguren, die es unter <public_url>/protocol akzeptiert, abgestimmt auf die Version, die Sie ausführen. Der Inhalt ist nicht stabil über Releases hinweg.

​

Ausfallverhalten

Wenn Postgres ausfällt, bedient das Gateway selbst weiterhin angemeldete Entwickler und neue Anmeldungen schlagen fehl. Ob Entwickler tatsächlich weiterarbeiten, hängt davon ab, wie Ihr Orchestrator die Readiness handhabt:

• Bestehende Sitzungen: Bearer-Tokens validieren lokal mit dem JWT-Geheimnis, Sitzungs-Refreshes berühren den Store nicht, und der Gateway-Prozess kann immer noch Inferenz bedienen
• Neue Anmeldungen: schlagen fehl, bis Postgres wiederhergestellt ist, da der Device-Flow und seine Rate-Limit-Zähler in Postgres leben
• Spend-Limit-Durchsetzung: schlägt während des Ausfalls offen fehl, daher fließt Inferenz weiterhin; schalten Sie es auf Fail-Closed um, wenn Sie lieber blockieren als ungemessen laufen möchten
• Readiness: /readyz meldet während des Ausfalls nicht bereit, daher entfernen Orchestratoren, die Verkehr auf Readiness gating, jede Replikation auf einmal aus der Rotation. In dieser Topologie schlägt der gesamte Verkehr, einschließlich Inferenz, die das Gateway immer noch bedienen könnte, beim Load Balancer fehl, bis Postgres wiederhergestellt ist. Die Liveness-Probe auf /healthz bleibt bestehen, daher werden Replikationen nicht neu gestartet. Zeigen Sie die Readiness-Probe statt auf /healthz, wenn Sie lieber möchten, dass angemeldete Entwickler durch einen Store-Ausfall weiterarbeiten; die Kosten sind, dass neue Anmeldungen gegen eine Replikation fehlschlagen, die immer noch bereit meldet.

Wenn Ihr IdP ausfällt, funktionieren bestehende Sitzungen bis ttl_hours, und neue Anmeldungen und Refreshes schlagen fehl. Setzen Sie eine längere ttl_hours, wenn Ihr IdP häufige Wartungsfenster hat.

​

JWT-Geheimnisrotation

Rotieren Sie das Signierungsgeheimnis in drei Schritten, damit bestehende Sitzungen gültig bleiben:

1. Generieren Sie ein neues Geheimnis. Stellen Sie es dem session.jwt_secret-Array voran.
2. Rollen Sie die Bereitstellung aus. Neue Tokens signieren mit dem neuen Geheimnis; alte Tokens validieren immer noch.
3. Nach ttl_hours plus einer Marge entfernen Sie das alte Geheimnis und rollen erneut aus.

Rotation ist auch die einzige Möglichkeit, Sitzungen vor Ablauf zu erzwingen: Bearer-Tokens validieren lokal gegen das JWT-Geheimnis, daher gibt es keine Pro-Sitzungs-Sperrung. Das Ersetzen des Geheimnisses direkt, ohne das alte in dem Array zu behalten, invalidiert jede ausstehende Sitzung auf einmal. Für einzelnes Offboarding deprovisioning Sie den Benutzer in Ihrem IdP; ihre Sitzung endet innerhalb von ttl_hours.

​

Postgres

Das Gateway hält fünf Tabellen, alle erstellt durch seine Boot-Zeit-Migrationen: Eine 30-Sekunden-Schleife läuft kv-Zeilen ab ihrer TTL ab, und ein stündlicher Sweep erzwingt die Aufbewahrungsfenster auf den Spend-Tabellen, daher wächst nichts ohne Grenzen. Ohne Spend-Limits konfiguriert, wird nur kv geschrieben. Wenn Ihre Sicherheitsrichtlinie DDL von der Anwendungsrolle verbietet, erstellen Sie diese Tabellen und _migrations vorab mit einer Admin-Rolle und gewähren Sie der App-Rolle SELECT, INSERT, UPDATE, DELETE auf jeder. Mit Spend-Limits in Verwendung bedeutet eine verlorene Datenbank verlorene Spend-Verfolgung und Caps, nicht nur Entwickler-Neu-Anmeldungen, daher führen Sie regelmäßige Backups durch. Um einen abgegangenen Entwickler sofort zu löschen, statt auf Aufbewahrung zu warten, führen Sie DELETE FROM principal_emails WHERE principal = '<sub>' direkt aus; das entfernt die einzige Tabelle, die ihre E-Mail, ihren Namen und ihre Gruppen hält. spend- und admin_audit-Zeilen referenzieren nur das pseudonyme OIDC-sub.

​

Upgrades

Replikationen sind zustandslos, daher ist ein Rolling Restart jederzeit sicher. Das Gateway führt Schema-Migrationen beim Start aus, was bedeutet, dass die Bereitstellung der neuen Binärdatei die Datenbank selbst migriert. Wenn die Datenbankrolle DDL nicht ausführen kann, erstellen Sie das Schema vorab, einschließlich der _migrations-Tabelle, die auf die aktuelle Version gesät ist; andernfalls schlägt der Boot beim Versuch CREATE TABLE fehl. Migrationen sind nur Anhänge, daher ist das Rollback zu einer früheren Binärdatei, die weniger Migrationen kennt, sicher; es ignoriert die zusätzlichen Zeilen. Rollback validiert auch die YAML erneut gegen das ältere Binärdatei-Schema, daher schlägt eine Konfiguration, die einen Schlüssel angenommen hat, der von der neueren Version eingeführt wurde, beim Boot auf der älteren fehl. Entfernen Sie den neuen Schlüssel vor dem Rollback. Da Sie die Gateway-Version in Ihrem eigenen Image pinnen, erreichen Fixes in neuen Claude Code-Releases, einschließlich Sicherheits-Fixes, Ihre Bereitstellung nur, wenn Sie den Pin aktualisieren und erneut bereitstellen. Beziehen Sie das Gateway in denselben Patching-Zyklus ein, den Sie für andere Dienste verwenden, die Produktionsanmeldedaten halten.

​

Sicherheit

Dieser Abschnitt beantwortet die Fragen, die eine Sicherheitsüberprüfung stellt: Welche Daten fließen durch das Gateway und wohin sie gehen, welche Angriffe das Design abwehrt, und welche Antworten in einen Compliance-Fragebogen gehören.

​

Datenfluss

​

Bedrohungsmodell-Zusammenfassung

Das Gateway sitzt innerhalb Ihres Netzwerk-Perimeters, aber einzelne Entwickler-Laptops werden nicht als vertrauenswürdig behandelt. Das Design berücksichtigt dies auf drei Arten:

• Entwickler halten kurzlebige JWTs statt roher Upstream-Schlüssel. Das CLI-zu-Gateway-Bein verwendet den RFC-8628-Device-Grant, und der Gateway-Autorisierungs-Code-Austausch mit dem IdP führt PKCE in der Standard-Konfiguration aus, daher ist ein abgefangener IdP-Autorisierungs-Code nutzlos.
• Die Device-Verifikationsseite erzwingt Same-Origin-POST und ein Pro-IP-Rate-Limit pro RFC 8628 §5.1. Siehe User-Code-Brute-Force-Resistenz.
• Ausgehende Anfragen gehen durch einen Server-Side-Request-Forgery (SSRF)-Guard, der DNS auflöst, Link-Local- und Cloud-Metadata-Adressen plus Loopback standardmäßig blockiert und die Verbindung zur aufgelösten IP pinnt, daher können Operator-beeinflusste URLs wie der IdP und OTLP-Ziele nicht zu Cloud-Metadata-Endpoints umgeleitet werden. RFC-1918-Private-Bereiche sind absichtlich erlaubt, da IdPs und OTLP-Collector häufig auf privaten IPs leben. Für lokale Entwicklung gegen einen Loopback-IdP oder Collector setzen Sie CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 in der Gateway-Umgebung; lassen Sie es in der Produktion ungesetzt.

Wenn Sie Ihre eigenen Egress-Kontrollen hinzufügen, muss das Gateway den Metadata-Server erreichen, wenn es Instanz-Metadata-Anmeldedaten wie Workload-Identität verwendet. Zwei Bedrohungen sind außerhalb des Geltungsbereichs, da sie Ihre Infrastruktur sind, um zu sichern:

• Ein kompromittierter Gateway-Host: Der Host hält sowohl die Upstream-Anmeldedaten als auch verteilt verwaltete Einstellungen an jeden verbundenen Entwickler, daher ist die Kontrolle über die Gateway-Konfiguration vergleichbar mit der Kontrolle über Ihr MDM. Der Einmal-Genehmigungsdialog der CLI für Shell-fähige Einstellungen begrenzt stille Änderungen, ersetzt aber nicht die Host-Sicherheit.
• Ein böswilliger OIDC-Anbieter: Der Anbieter signiert die id_tokens, denen das Gateway vertraut, daher kann er jede Identität behaupten. Das Überprüfen und Sichern Ihres IdP ist Ihre Verantwortung.

​

User-Code-Brute-Force-Resistenz

Der user_code, den ein Entwickler auf der /device-Verifikationsseite eingibt, sind 8 Zeichen aus einem 20-Zeichen-Alphabet, was 20⁸ oder etwa 2,56×10¹⁰ Kombinationen ergibt, und er läuft nach 10 Minuten ab. Das Gateway wendet Pro-IP-Rate-Limits auf die Device-Grant-Endpoints an, konfigurierbar über rate_limits. Erhöhen Sie die Limits, wenn sich viele Entwickler von einer einzelnen gemeinsamen Unternehmens-NAT-Adresse anmelden. Die Limits gelten nur für den Anmeldungs-Flow, nicht für Inferenz.

​

Compliance-Haltung

• Datenresidenz: Die Datenebene des Gateways selbst sendet nichts an Anthropic, es sei denn, die Anthropic-API ist ein konfigurierter Upstream; wenn sie es ist, gilt Ihre bestehende Datenbehandlungsvereinbarung für den Inferenz-Pfad. Telemetrie, Audit, Identität und Einstellungen gehen nur an die Ziele, die Sie konfigurieren.
• Host-Prozess-Verkehr: Der Host-Prozess ist die Claude Code CLI, die Startup-Analytik und Update-Prüfungen an Anthropic senden kann. Für Strict-Egress-Bereitstellungen setzen Sie CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 in der Gateway-Container-Umgebung.
• Client-Analytik: Die CLI deaktiviert ihre eigene Nutzungsanalytik, während sie bei einem Gateway angemeldet ist, und die Fehlerberichterstattung ist standardmäßig auf Third-Party-API-Oberflächen deaktiviert.
• Client-Maschinen: Entwickler-CLIs senden immer noch WebFetch-Hostname-Prüfungen und Versions-Prüfungen an Anthropic, es sei denn, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 und skipWebFetchPreflight: true sind gesetzt. Siehe Datennutzung.
• Umfrage-Bewertungen: Die Gateway-Anmeldedaten deaktivieren die Anthropic-gebundene Bewertungs-Senke, daher werden Bewertungen nicht an Anthropic gesendet.
• Transkript-Freigabe: Das Wählen von Ja auf einer Umfrage-Transkript-Freigabe-Aufforderung schreibt eine lokale Datei unter ~/.claude/feedback-bundles/ statt zu Anthropic hochzuladen.
• Client-Updates: Update-Prüfungen sind getrennt vom Gateway-Verkehr. Pinnen Sie Versionen durch Ihre eigene Verteilung und setzen Sie DISABLE_UPDATES, wenn Laptops keine Releases abrufen dürfen. DISABLE_AUTOUPDATER stoppt nur Hintergrund-Updates, während claude update immer noch funktioniert.
• TLS: Bedienen Sie public_url über HTTPS in der Produktion, entweder vom Gateway-eigenen Listener über listen.tls oder von einem TLS-terminierenden Ingress vor einfachen HTTP-Replikationen mit listen.public_url gesetzt. Das Gateway weigert sich nicht, einfaches HTTP. Der IdP muss HTTPS in der Produktion bedienen, und Postgres unterstützt ?sslmode=require. Setzen Sie Strict-Transport-Security bei Ihrem Ingress.
• Vulnerability-Offenlegung: Folgen Sie Sicherheitsprobleme melden

​

Fehlerbehebung

Für Fragen und Feedback verwenden Sie Claude-Code-Support, oder öffnen Sie ein Issue im Claude-Code-GitHub-Repository. Wenn Sie ein Problem melden, beziehen Sie ein:

• Gateway-Problem: Das Gateway-Stderr für das relevante Fenster, Ihre gateway.yaml mit Geheimnissen redigiert, die Gateway-Version, auf der Landingpage unter / und im x-cc-gateway-version-Response-Header auf /managed/settings angezeigt, und was sich kürzlich geändert hat
• Anmeldungs-Problem: Der Entwickler führt claude --debug-file ./claude-debug.txt aus, reproduziert und sendet diese Datei plus das Gateway-Audit-Protokoll für dasselbe Fenster
• Inferenz-Problem: Das angeforderte Modell, die konfigurierten Upstreams und das Gateway-Audit-Protokoll für die Anfrage, das aufzeichnet, welcher Upstream sie bedient hat und den Response-Status

​

Verwandt

• Claude-Apps-Gateway-Übersicht: Schnellstart und Entwickler-Verbindung
• Konfigurationsreferenz: Jede gateway.yaml-Option