Claude Code: Fehler 403 durch Region, Gateway, TLS oder Anmeldung?

Ein HTTP 403 in Claude Code beweist für sich genommen nicht, dass dein Konto gesperrt ist. Nutze Claude Code 2.1.318 oder neuer, um die hier beschriebenen Korrekturen für Diagnose, Gateways und Zertifikate einzuschließen. Prüfe anschließend die zum Fehler passende Ursache, statt dich wiederholt anzumelden.

Die Versionshinweise zu 2.1.317 unterscheiden Regions- oder Netzwerksperren von Anmeldefehlern. Die Versionshinweise zu 2.1.318 verbessern den Umgang mit fehlerhaften Zertifikatsdateien und machen abgelaufene gespeicherte Anmeldungen deutlicher erkennbar. Diese Änderungen helfen, Fehler einzuordnen. Sie heben keine Zugriffsbeschränkungen auf und reparieren nicht jede Gateway-Konfiguration.

Beginne mit der korrigierten Version und einer kleinen Anfrage

Stand 2026-11-10 ist 2.1.318 die Mindestversion, die alle hier behandelten Korrekturen enthält. Das bedeutet nicht, dass sie die neueste Version ist. Die einzelnen Korrekturen erschienen erstmals in den folgenden Versionen.

Symptom	Erste Version mit der jeweiligen Korrektur	Erste Prüfung
Ein HTTP 403 durch eine Regions- oder Netzwerksperre erscheint als Anmeldefehler	2.1.317	Lies die Erklärung zur Sperre und identifiziere den antwortenden Dienst
VS Code öffnet nach einer Regions- oder Netzwerksperre den Anmeldebildschirm	2.1.317	Wiederhole die Anfrage in der betroffenen VS-Code-Oberfläche
Auto scheitert in jeder Runde, wenn das als Base URL konfigurierte Gateway die Sicherheitsprüfung mit 403 oder 422 ablehnt	2.1.317	Vergleiche Manual und Auto; die Ausnahme für 403 mit `apiKeyHelper` bleibt bestehen
Nach der Erneuerung des Stammzertifikats eines Proxys mit TLS-Inspektion erscheint `unable to get local issuer certificate`	2.1.317	Prüfe die freigegebene Zertifikatskette und die Client-Version
Eine leere `NODE_EXTRA_CA_CERTS`-Datei, ein anderes Format als PEM oder ein beschädigtes erstes Zertifikat führt zu Verbindungsfehlern	2.1.318	Korrigiere die Zertifikatsdatei und prüfe die Startwarnungen
Ein erforderliches Claude apps gateway ist nicht erreichbar	2.1.317	Prüfe den Netzwerkpfad und das Vertrauen in das Zertifikat
Die gespeicherte claude.ai-Anmeldung erreicht ihr Ablaufdatum	2.1.318	Erneuere die aktive Anmeldung, statt das Netzwerk zu ändern

Prüfe in Bash den Kommandozeilenclient, den du tatsächlich verwendest:

claude --version
claude auth status

Die CLI-Referenz beschreibt claude auth status als Bericht zum Authentifizierungsstatus. Das Ergebnis zeigt den Zustand der konfigurierten Authentifizierung. Es beweist nicht, dass Modellanfragen funktionieren.

Verwende die für deine Installation vorgesehene Aktualisierungsmethode. Führe bei einer nativen Installation Folgendes aus:

claude update
claude --version

Für Installationen über Paketmanager oder zentral verwaltete Installationen gelten die Installations- und Update-Anweisungen. Prüfe, ob die angezeigte Version die benötigte Mindestversion erreicht. Wiederhole den Test in der Oberfläche, in der der Fehler auftrat. Ein erfolgreicher Terminaltest bestätigt nicht, dass die Verbindung aus VS Code funktioniert.

Sende anschließend eine kleine Anfrage aus derselben Bash-Umgebung:

claude -p 'Reply with exactly OK. Do not use tools.'

Das erwartete Ergebnis ist OK ohne Verbindungs- oder Authentifizierungsfehler. Damit prüfst du eine einfache Modellanfrage. Der Test prüft weder den Prüfpfad von Auto noch die Kompatibilität mit allen Funktionen.

Eine Regions- oder Netzwerksperre ist keine abgelaufene Anmeldung

Untersuche das Netzwerk oder den Grund für die Zugriffsverweigerung, wenn der Fehler auf eine Sperre hinweist. Eine erneute Authentifizierung ist bei diesem Symptom nicht der erste Lösungsweg.

Im Änderungsprotokoll zu 2.1.317 steht, übersetzt:

Behoben wurde, dass eine Regions- oder Netzwerksperre (HTTP 403) als Anmeldefehler angezeigt wurde. Die Fehlermeldung erklärt jetzt die Sperre.

Dieselbe Version behebt separat, dass VS Code in diesem Fall den Anmeldebildschirm öffnet. Keiner der Einträge besagt, dass ein Update die blockierte Anfrage zulässt.

Starte Claude Code und führe /status aus. Prüfe anhand der Gateway-Verbindungsanleitung die aktive Route und die Quelle der Zugangsdaten. Kläre vor der Kontoprüfung, ob die Anfrage direkt an Anthropic oder an dein konfiguriertes Gateway geht.

Lass in einem Firmennetz die Proxy-Einstellungen des betroffenen Prozesses von der IT prüfen. Dazu gehören HTTPS_PROXY und HTTP_PROXY, die im Leitfaden zur Netzwerkkonfiguration dokumentiert sind. Ist eine Regionssperre bestätigt, kläre die Verfügbarkeit des Dienstes mit dem Anbieter, statt wiederholt Zugangsdaten zu erneuern.

Bewahre den Antwortinhalt, den Zielhostnamen, den Zeitstempel und die Anfrage-ID auf, sofern sie verfügbar ist. Sende keine vollständigen Umgebungsvariablen-Ausgaben, Zugangsdaten oder vollständigen Prompts in einem Supportticket.

Eine ausdrückliche Meldung über eine Kontosperre gehört zum Kontosupport. Die Anthropic-Fehlerreferenz beschreibt diesen Zustand als gesperrtes Konto. Eine andere mögliche Ursache ist fehlender Modellzugriff. Der Leitfaden zu Installation und Authentifizierung dokumentiert 403-Fehler nach erfolgreicher Authentifizierung, wenn das Konto das angeforderte Modell nicht nutzen darf.

Sende zur Prüfung erneut eine kleine Anfrage über die vorgesehene, freigegebene Route. Liefert sie weiterhin 403, nutze die aktuelle Fehlererklärung und die Protokolle des Anbieters, um den Ablehnungsgrund zu bestimmen. Schließe nicht allein aus dem Statuscode auf eine Kontosperre.

Auto scheitert über ein Gateway in jeder Runde

Untersuche die Sicherheitsprüfung, wenn Manual funktioniert, Auto aber über dasselbe Gateway wiederholt scheitert. Die Korrektur in 2.1.317 gilt für einen bestimmten Fall. Der Eintrag lautet übersetzt:

Behoben wurde, dass Auto in jeder Runde scheitert, wenn ein als Basis-URL gesetztes LLM-Gateway auf die serverseitige Sicherheitsprüfung mit 403 oder 422 antwortet. Ein 403 mit apiKeyHelper bleibt unverändert.

Die Ausnahme ist wichtig. Ein 403 bei aktivem apiKeyHelper fällt nicht unter diese Änderung. Lass den Gateway-Verantwortlichen die Zugangsdaten und den Autorisierungsablauf prüfen, ohne die geheimen Ausgaben des Hilfsprogramms offenzulegen.

Der Kompatibilitätsleitfaden für Gateways nennt einen anthropic-beta-Wert und das Anfragefeld safeguards für die serverseitige Prüfung. Lehnt das Gateway diese Funktion ab, ist eine andere Untersuchung nötig als bei abgelehnten Zugangsdaten. Der Statuscode allein zeigt nicht, welcher Fall vorliegt.

Vergleiche zwei Sitzungen in einer Arbeitskopie eines vertrauenswürdigen Git-Repositorys. Behalte Modell, Endpoint, Zugangsdaten und Aufgabe bei.

Starte claude --permission-mode default. Bitte Claude, mit Bash git status --short auszuführen und das Ergebnis zu melden, ohne Dateien zu ändern. Bestätige die Berechtigungsabfrage, falls sie erscheint.

Beende diese Sitzung, starte claude --permission-mode auto und wiederhole dieselbe Aufgabe. Prüfe anhand der Bedienung der Berechtigungsmodi, ob der angeforderte Modus aktiv ist. Eine Sitzung, die nicht in Auto gewechselt ist, bestätigt nicht die Funktion von Auto.

Scheitert nur die Auto-Sitzung, ordne ihre fehlgeschlagene Anfrage den Gateway-Protokollen zu. Bitte den Betreiber, die Ablehnung anhand des Kompatibilitätsleitfadens zu untersuchen. Der Vergleich grenzt die Suche ein. Er beweist nicht, welche konkrete Gateway-Regel den Fehler verursacht.

Mit Zustimmung deines Administrators kannst du vorübergehend Claude Codes eigene Klassifikator-Anfragen statt der serverseitigen Prüfung verwenden. Der Klassifikator bewertet die Aktionen:

CLAUDE_CODE_AUTO_MODE_SERVER=0 claude --permission-mode auto

Die Referenz der Umgebungsvariablen dokumentiert diesen Schalter. Er ändert, wo die Prüfung stattfindet, und schaltet die Berechtigungsprüfung nicht aus. Der Klassifikator stellt weiterhin Modellanfragen. Prüfe deren Verbrauch und Latenz, bevor du die Einstellung beibehältst.

Funktioniert diese Sitzung, während Auto ohne die Einstellung scheitert, untersuche die Kompatibilität mit der serverseitigen Prüfung. Scheitern beide, untersuche den gemeldeten Fehler bei Zugangsdaten, Modell oder Gateway. Setze nicht voraus, dass diese Korrektur auf deinen Fall zutrifft.

Die Unterschiede bei der Abrechnung erklärt der Artikel zu serverseitigem Klassifikator und Ausweichverhalten. Betrachte die separaten Klassifikator-Anfragen nicht als Offline- oder zwangsläufig kostenlose Alternative.

Korrigiere das Zertifikatsvertrauen, nicht die Authentifizierung

Behandle unable to get local issuer certificate als Problem mit dem Vertrauen in Zertifikate. Dieser Fehler liegt auf einer anderen Ebene als eine HTTP-Antwort zur Autorisierung.

Im Änderungsprotokoll zu 2.1.317 steht, übersetzt:

Behoben wurden API-Anfragen, die hinter manchen Proxys mit TLS-Inspektion nach der Erneuerung eines Stammzertifikats mit “unable to get local issuer certificate” scheiterten.

Die Korrektur betrifft das beschriebene Problem nach der Zertifikatserneuerung. Sie belegt nicht, dass jeder Fehler beim Ausstellerzertifikat dieselbe Ursache hat.

Prüfe zuerst die Client-Version. Frage anschließend die IT, ob das Stammzertifikat des Proxys geändert wurde und welchem Zertifikatsbündel der Zertifizierungsstellen der Client vertrauen soll. Nutze ein freigegebenes PEM-Bündel, nicht ein Zertifikat aus einer ungeprüften Quelle.

Benötigt deine Umgebung ein eigenes Bündel, speichere die von der IT bereitgestellte Datei als $HOME/company-ca.pem. Starte einen neuen Claude-Code-Prozess aus derselben Bash-Shell:

export NODE_EXTRA_CA_CERTS="$HOME/company-ca.pem"
claude -p 'Reply with exactly OK. Do not use tools.'

Das entspricht der dokumentierten Konfiguration eigener CA-Zertifikate. Der Beispielpfad ist ein lokaler Dateiname, den du wählst. Die Zertifikate selbst müssen von deiner Organisation stammen.

Der Test ist erfolgreich, wenn die Anfrage ohne den Fehler beim Ausstellerzertifikat abgeschlossen wird. Scheitert sie weiter, lass die IT das bereitgestellte Bündel und die über den Proxy präsentierte Zertifikatskette prüfen.

Setze nicht NODE_TLS_REJECT_UNAUTHORIZED=0. Anthropic warnt in den Hinweisen zu Zertifikatsfehlern, dass diese Einstellung die Zertifikatsprüfung deaktiviert.

Leere oder beschädigte NODE_EXTRA_CA_CERTS-Dateien

Nutze 2.1.318 oder neuer, wenn die Datei mit zusätzlichen CA-Zertifikaten selbst fehlerhaft ist. Im Änderungsprotokoll steht, übersetzt:

Behoben wurde, dass jede Verbindung scheitert, wenn die Datei NODE_EXTRA_CA_CERTS leer ist, nicht im PEM-Format vorliegt oder mit einem beschädigten Zertifikat beginnt. Lesbare Zertifikate werden jetzt verwendet; auf stderr erscheint eine Warnung.

Prüfe neben dem Verbindungsergebnis auch die Warnungen. Die Korrektur nutzt lesbare Zertifikate. Sie repariert weder die Datei noch ergänzt sie ein fehlendes Zertifikat, das dein Proxy benötigt.

Ersetze ein leeres oder beschädigtes Bündel durch die freigegebene PEM-Datei. Entferne eine unbeabsichtigte NODE_EXTRA_CA_CERTS-Einstellung erst, nachdem du bestätigt hast, dass die Umgebung sie nicht benötigt. Starte anschließend einen neuen Prozess und wiederhole die kleine Anfrage.

Funktioniert die Anfrage, aber die Warnung zur Zertifikatsdatei bleibt, korrigiere das Bündel, bevor du die Konfiguration als abgeschlossen betrachtest.

Ein erforderliches Claude apps gateway ist nicht erreichbar

Stelle die Verbindung zum erforderlichen Gateway wieder her, bevor du eine funktionierende Anmeldung änderst. Der Eintrag zu 2.1.317 lautet übersetzt:

Verbessert wurde die Startfehlermeldung, wenn ein erforderliches Claude apps gateway nicht erreichbar ist. Sie verweist auf das Netzwerk statt auf die Anmeldung und meldet, wenn das TLS-Zertifikat des Gateways nicht überprüft werden kann.

Dieser Eintrag betrifft ein erforderliches Claude apps gateway. Übertrage ihn nicht automatisch auf jeden Drittanbieter-Endpoint in ANTHROPIC_BASE_URL.

Gib dem Gateway-Administrator den betroffenen Hostnamen und die um sensible Daten bereinigte Fehlermeldung. Bitte ihn, Erreichbarkeit, DNS, Proxy-Regeln und Zertifikatsvertrauen zu prüfen. Nennt die Meldung die Zertifikatsprüfung, folge den CA-Prüfschritten, statt die Zugangsdaten zurückzusetzen.

Die Prüfung erfolgt in zwei Stufen: Claude Code muss den Gateway-Startfehler überwinden und anschließend die kleine Modellanfrage abschließen. Ein danach auftretender Authentifizierungsfehler ist ein separates Ergebnis, das du untersuchen musst.

Erneuere die Anmeldung nur bei abgelaufenen Zugangsdaten

Erneuere die gespeicherte claude.ai-Anmeldung, wenn die Fehlermeldung ausdrücklich deren Ablauf nennt. Die Versionshinweise zu 2.1.318 unterscheiden diesen Fall von einer Netzwerksperre. Übersetzt:

Behoben wurde der Anmeldefehler, wenn eine gespeicherte claude.ai-Anmeldung ihr Zeitlimit erreicht. Die Meldung nennt jetzt den Ablauf und verweist in claude -p auf claude auth login und claude setup-token.

Soll dein interaktiver Arbeitsablauf die claude.ai-Anmeldung verwenden, führe diese Befehle in Bash aus:

claude auth login
claude auth status
claude -p 'Reply with exactly OK. Do not use tools.'

Schließe die Anmeldung ab, bevor du den Status prüfst und die Anfrage sendest. Erwartet werden der vorgesehene Authentifizierungsstatus und anschließend eine erfolgreiche Antwort.

Die Version nennt auch claude setup-token, um den Zugriff bei nicht interaktiven Abläufen wiederherzustellen. Folge dafür der Authentifizierungsanleitung, statt ein Token in ein Skript einzubetten.

Vom Gateway ausgestellte Zugangsdaten musst du über ihren Aussteller wiederherstellen. Eine Anmeldung bei claude.ai prüft diese Zugangsdaten nicht. Tritt danach weiterhin ein Regions-, Netzwerk- oder Gateway-Fehler auf, kehre zu den passenden Prüfschritten zurück, statt die Anmeldung zu wiederholen.

Prüfe ANTHROPIC_BASE_URL und die aktiven Zugangsdaten

Prüfe die Route innerhalb der fehlerhaften Sitzung, bevor du weitere Einstellungen änderst. Die Verbindungsanleitung empfiehlt /status, um die tatsächlich verwendete Base URL und die Quelle der Zugangsdaten anzuzeigen.

Nutze die vom Gateway dokumentierte Anthropic-kompatible Basisadresse. Der Protokollleitfaden ordnet ANTHROPIC_BASE_URL dem Format Anthropic Messages und /v1/messages zu. Kopiere keine OpenAI-kompatible URL in diese Konfiguration, ohne das Protokoll zu prüfen. Der Leitfaden zur Fehlersuche bei Base URL und Endpoint erklärt den Unterschied.

Wähle die Zugangsdatenvariable passend zum Header, den das Gateway erwartet. Anthropic dokumentiert ANTHROPIC_AUTH_TOKEN für Authorization: Bearer und ANTHROPIC_API_KEY für X-Api-Key. Folge den Gateway-Anweisungen, statt dieselben Zugangsdaten in jede verfügbare Variable einzutragen.

Für eine bestehende Verbindung über die BetterToken-API verwenden die Claude-Code-Anweisungen https://bettertoken.ai ohne /v1 sowie ANTHROPIC_AUTH_TOKEN. Stand 2026-11-10 führt der Katalog claude-sonnet-5-5. Das ist ein separater API-Zugang, kein Claude-Abonnement und keine Garantie, dass jede Claude-Code-Funktion funktioniert.

Weicht die aktive Route von deiner vorgesehenen Konfiguration ab, folge der Anleitung zur Prüfung des aktiven Claude-Code-Anbieters. Gleiche eine kleine Anfrage mit den Protokollen des vorgesehenen Anbieters ab und wiederhole dann die zuvor fehlgeschlagene Aktion. Eine einfache Antwort reicht für einen grundlegenden Verbindungstest. Bei einem Auto-Problem muss zusätzlich der Vergleich mit Auto erfolgreich sein.