---
title: "Fehlercode 401 Unauthorized: Bedeutung und Lösungen"
description: "Fehlercode 401 unauthorized: Die Website oder API bekam keine gültigen Anmeldedaten. Besucher melden sich neu an, Entwickler prüfen Header, Schema und Token."
url: https://proxynet.io/de/blog/401-unauthorized-error
date: 2026-11-12
author: "Acar Diveroli"
category: "Anleitungen, Web Scraping"
lang: de
---

# Fehlercode 401 Unauthorized: Bedeutung und Lösungen

Sie öffnen ein Dashboard, das Sie gestern noch benutzt haben, und Chrome zeigt eine schlichte graue Seite: „Diese Seite funktioniert nicht“, ganz unten HTTP ERROR 401. Auf einem Firmenserver lautet derselbe Code „401 - Unauthorized: Access is denied due to invalid credentials.“ In Postman ist es eine rote 401 neben einem API-Aufruf, der vor einer Stunde noch funktioniert hat.

Alle drei sind ein und derselbe HTTP-Statuscode: Der Server wollte wissen, wer Sie sind, und hat keine Antwort bekommen, die er akzeptiert. Im Folgenden: was der Code bedeutet, worin er sich von 400, 403 und 407 unterscheidet, was Besucher und Entwickler tun können, und ein echter Test mit cURL.

> **Hinweis: Kurzantwort**
>
> Der Fehlercode 401 Unauthorized bedeutet, dass der Server für die angefragte Seite oder API keine gültigen Anmeldedaten erhalten hat: Sie sind nicht angemeldet, Ihre Sitzung oder Ihr Token ist abgelaufen, oder Passwort oder Schlüssel sind falsch. Welches Anmeldeverfahren der Server erwartet, nennt er im Header `WWW-Authenticate`. Als Besucher prüfen Sie die Adresse, melden sich neu an, kontrollieren, welches Konto Ihr Passwortmanager eingetragen hat, und löschen die Cookies dieser Website. Als Entwickler senden Sie einen Header `Authorization` mit dem Schema, das der Server nennt, meist `Bearer`, und ein aktuelles Token, das für diese API ausgestellt wurde.

## Was bedeutet 401 Unauthorized?

Ein 401 bedeutet, dass der Server Ihre Anfrage nicht ausgeführt hat, weil sie ohne gültige Anmeldedaten kam. Der HTTP-Standard [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.2) definiert den Code in Abschnitt 15.5.2 als Anfrage, der gültige Authentifizierungsdaten für die Zielressource fehlen. Anmeldedaten sind alles, was beweist, wer Sie sind: ein Passwort, ein Sitzungscookie, ein API-Schlüssel oder ein Token.

Der Server muss außerdem einen Header `WWW-Authenticate` senden, der dem Client sagt, wie er sich anmelden soll. Enthielt die Anfrage bereits Anmeldedaten, bedeutet der 401, dass sie abgelehnt wurden.

Der Name führt in die Irre. Authentifizierung beantwortet die Frage „Wer sind Sie?“, Autorisierung die Frage „Was dürfen Sie?“. Ein 401 betrifft die erste Frage; eine Absage bei der zweiten ist ein 403 Forbidden.

## Wie sieht ein 401-Fehler aus?

Das hängt davon ab, wer ihn anzeigt: Browser, Webserver und API formulieren ihn jeweils anders.

| Was Sie sehen | Angezeigt von | Was es bedeutet |
|---|---|---|
| „Diese Seite funktioniert nicht“, „HTTP ERROR 401“ | Chrome | Die Website hat einen 401 ohne eigene Seite geschickt |
| Ein kleines Fenster, das Benutzername und Passwort verlangt | Ihr Browser | Die Website nutzt die HTTP-Anmeldung (Basic) |
| „401 - Unauthorized: Access is denied due to invalid credentials.“ | IIS, der Webserver von Microsoft | IIS hat die Anmeldung nicht akzeptiert |
| `401` und eine kurze JSON-Meldung | Eine API, in Postman oder im Code | Schlüssel oder Token fehlt, ist falsch oder abgelaufen |

Die Seite von Chrome (hier in der deutschen Fassung) sagt nichts über die Ursache; in unserem Test zeigte Chromium, die Engine hinter Chrome, sie bei einem 401 mit leerem Antworttext.

## Was ist der Header WWW-Authenticate?

`WWW-Authenticate` ist der Antwort-Header, in dem der Server sein Anmeldeverfahren nennt, das sogenannte Schema. [Die Referenz von MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/WWW-Authenticate) zeigt die vollständige Syntax. **Basic** verlangt Benutzername und Passwort, Base64-kodiert gesendet (nicht verschlüsselt, also nur über HTTPS sicher); Browser beantworten es mit ihrem Anmeldefenster. **Bearer** verlangt ein Token, das Format, das OAuth 2.0 verwendet. **Negotiate** und **NTLM** sind die Windows-Anmeldung in Firmennetzen.

```text
WWW-Authenticate: Basic realm="Staging server", charset="UTF-8"
WWW-Authenticate: Bearer realm="example", error="invalid_token"
```

Bei Tokens lesen Sie den Wert `error`. [RFC 6750](https://www.rfc-editor.org/rfc/rfc6750.html#section-3), der Standard für Bearer-Tokens, definiert `invalid_token` für ein abgelaufenes, widerrufenes oder fehlerhaftes Token (401), `insufficient_scope` für ein Token ohne die nötige Berechtigung (403) und `invalid_request` für eine fehlerhaft aufgebaute Anfrage (400). Eine Anfrage ganz ohne Token bekommt nur die Aufforderung zur Anmeldung, ohne Fehlercode. Viele APIs lassen den Header trotz der Regel weg; dann verrät nur der Antworttext den Grund.

## Wie entsteht ein 401, Schritt für Schritt?

Ein 401 ist die erste Hälfte eines kurzen Austauschs:

1. **Die Anfrage.** Ihr Browser oder Skript fragt eine geschützte Seite ohne Anmeldedaten an oder mit solchen, die nicht mehr gelten.
2. **Die Aufforderung (Challenge).** Der Server antwortet mit 401 und nennt das Schema in `WWW-Authenticate`.
3. **Die Anmeldedaten.** Der Browser öffnet sein Anmeldefenster, die App schickt Sie zu ihrer Anmeldeseite, oder Ihr Code fordert ein Token an.
4. **Die Wiederholung.** Die Anfrage geht erneut hinaus, diesmal mit einem Header `Authorization`, etwa `Authorization: Bearer <token>`.
5. **Das Urteil.** Gültige Anmeldedaten bekommen die Seite (200 OK), ungültige einen weiteren 401, gültige ohne Berechtigung einen 403.

Die meisten Websites mit Anmeldeformular schicken einen abgemeldeten Besucher auf die Anmeldeseite, statt einen 401 zu senden. Ein 401 im Browser kommt deshalb meist aus einem Admin-Bereich, einem Firmen-Intranet oder von einer Web-App, deren Aufrufe an die eigene API abgelehnt werden.

## Was ist der Unterschied zwischen 400, 401, 403 und 407?

Die vier Codes unterscheiden sich darin, wer ablehnt und warum: 400 ist eine Anfrage, die der Server nicht lesen kann, 401 eine fehlende oder abgelehnte Anmeldung, 403 ein bekannter Nutzer ohne Berechtigung und 407 Ihr Proxy, der eigene Anmeldedaten verlangt.

| Code | Wer lehnt ab | Was es bedeutet | Was hilft |
|---|---|---|---|
| `400` | Die Website oder API | Die Anfrage ist fehlerhaft aufgebaut | Die Anfrage korrigieren |
| `401` | Die Website oder API | Keine gültigen Anmeldedaten | Anmelden oder ein gültiges Token senden |
| `403` | Die Website oder API | Bekannt, aber nicht berechtigt | Ein anderes Konto oder die Erlaubnis der Website |
| `407` | Ihr Proxy | Der Proxy will Anmeldedaten | Benutzername und Passwort des Proxys oder die IP-Liste |

Ein 401 lädt Sie ein, es mit Anmeldedaten erneut zu versuchen; ein 403 sagt, dass dieselben Anmeldedaten nicht helfen. [Fehlercode 403 Forbidden: Bedeutung und Lösungen](/de/blog/403-forbidden-error) behandelt diesen Fall.

Ein 400 kommt noch früher: Der Server konnte die Anfrage nicht lesen und hat daher nie geprüft, wer sie geschickt hat, wie unser [Leitfaden zum Fehler 400 Bad Request](/de/blog/400-bad-request-error) erklärt.

Ein Proxy, der Anmeldedaten verlangt, antwortet mit 407 Proxy Authentication Required und einem Header `Proxy-Authenticate`, nie mit 401. Die Lösung sind Benutzername und Passwort des Proxys oder Ihre IP-Adresse auf seiner Whitelist (Freigabeliste), nicht Ihr Login auf der Website. [HTTP 407 Proxy Authentication Required beheben](/de/blog/http-407-proxy-authentication-required) zeigt, wo die Proxy-Anmeldedaten in jedem Tool hingehören.

Sieht der Proxy Ihr Token? Nicht bei einer `https://`-Adresse: Der Client öffnet mit einer `CONNECT`-Anfrage einen Tunnel durch den Proxy, und der Header `Authorization` reist innerhalb der verschlüsselten Verbindung zur Website. Der Proxy sieht nur Hostname und Port; so transportiert ein [HTTPS-Proxy](https://proxynet.io/de/https-proxy) API-Aufrufe. Über einfaches `http://` geht das Token als lesbarer Text durch.

## Warum bekomme ich einen 401-Fehler?

Für Besucher bedeutet ein 401 fast immer, dass die Website Ihre Anmeldung nicht mehr erkennt oder sie nie erhalten hat:

- **Ihre Sitzung ist abgelaufen**, nach längerer Inaktivität, einer Passwortänderung oder einer Abmeldung auf einem anderen Gerät, oder das Cookie der Website (die kleine Datei, in der sie sich an Sie erinnert) ist beschädigt.
- **Ihr Passwortmanager hat ein anderes Konto eingetragen**, etwa Ihr privates auf einer Website, auf der Sie auch ein Arbeitskonto haben.
- **Sie haben das Anmeldefenster des Browsers abgebrochen** oder darin ein falsches Passwort eingegeben.
- **Der Link war für jemand anderen gedacht.** Geteilte Dashboards und Testserver verlangen womöglich ein Konto, das Sie nicht haben.
- **Eine Firmenseite erwartet Ihr Arbeitskonto** und lehnt einen privaten Computer oder einen Browser außerhalb des Firmennetzes ab.

## Fehler 401 beheben: Was Sie als Besucher tun können

Gehen Sie die Punkte der Reihe nach durch; die ersten dauern nur Sekunden.

1. **Adresse prüfen.** Ein Tippfehler oder ein altes Lesezeichen kann in einen geschützten Bereich führen; öffnen Sie die Seite über die Startseite der Website.
2. **Ab- und wieder anmelden**, damit Sie eine neue Sitzung bekommen.
3. **Das Konto prüfen.** Sehen Sie nach, welchen Benutzernamen Ihr Passwortmanager eingetragen hat, und tippen Sie die Anmeldedaten einmal von Hand ein.
4. **Die Cookies dieser Website löschen.** In Chrome: **Dreipunkt-Menü > Einstellungen > Datenschutz und Sicherheit > Drittanbieter-Cookies > Alle Websitedaten und -berechtigungen ansehen**, nach der Website suchen und **Löschen** wählen. Damit werden Sie nur bei dieser Website abgemeldet.
5. **Ein privates Fenster probieren.** In Chrome **Dreipunkt-Menü > Neues Inkognitofenster** (Strg + Umschalt + N). Es startet ohne die Cookies der Website und ohne Erweiterungen, die Sie dort nicht zugelassen haben. Funktioniert die Seite dort, hat ein Cookie oder eine Erweiterung den 401 verursacht.
6. **Das Anmeldefenster mit den Anmeldedaten beantworten, die Sie bekommen haben.** Erscheint es immer wieder, sind sie falsch; fragen Sie die Person, die Ihnen den Zugang gegeben hat.
7. **Die Website oder Ihre IT kontaktieren** und dabei die Adresse, die Uhrzeit und das verwendete Konto nennen.

Für einen 401 gibt es nur eine ehrliche Lösung: Anmeldedaten, die für Sie ausgestellt wurden. Andere Passwörter auszuprobieren oder das Konto eines anderen zu benutzen, ist unbefugter Zugriff, und wiederholte Fehlversuche können das Konto sperren.

## Fehler 401 beheben: Was Sie als Entwickler tun können

Im Code bedeutet ein 401, dass der Server nicht akzeptiert hat, was im Header `Authorization` ankam; prüfen Sie also zuerst die Anfrage und erst dann das Konto. Lesen Sie als Erstes den Wert von `WWW-Authenticate` und den Antworttext.

1. **Der Header fehlt.** Steht in der Ausgabe von `curl -v` keine Zeile `> Authorization:`, wurde nichts gesendet. Die üblichen Verdächtigen: eine leere Umgebungsvariable oder eine Weiterleitung. cURL verwirft den Header `Authorization`, wenn eine Weiterleitung zu einem anderen Host, Port oder Protokoll (http oder https) führt, es sei denn, Sie ergänzen `--location-trusted`; in unserem Test machte eine Weiterleitung von `localhost` auf `127.0.0.1` aus einem 200 einen 401.
2. **Das Schema ist falsch.** Ein Token gehört in `Authorization: Bearer <token>`, Benutzername und Passwort gehören zu `Basic`. Ein als Basic gesendetes Token, `Token`, wo die API `Bearer` erwartet, oder ein API-Schlüssel in einem Header, den die API nicht liest, enden alle mit 401. Nach dem Schema steht genau ein Leerzeichen, Anführungszeichen gibt es keine.
3. **Das Token ist abgelaufen oder widerrufen.** `error="invalid_token"` in der Challenge sagt genau das. Holen Sie ein neues Token, mit einem Refresh-Token, falls Sie eines haben, und wiederholen Sie die Anfrage einmal.
4. **Die Uhren gehen unterschiedlich.** Ein JWT (JSON Web Token) trägt seinen eigenen Ablaufzeitpunkt (`exp`) und Startzeitpunkt (`nbf`), die gegen die Uhr des Servers geprüft werden. Eine Uhr, die ein paar Minuten falsch geht, lässt ein frisches Token abgelaufen oder noch nicht gültig aussehen; der JWT-Standard sieht höchstens wenige Minuten Toleranz vor, synchronisieren Sie also beide Rechner per NTP.
5. **Das Token gehört woandershin:** ein Staging-Token, das an die Produktion geht, oder eines, das für eine andere API ausgestellt wurde. Ein JWT nennt seinen vorgesehenen Empfänger im Claim `aud` (Audience), und ein Server, der sich dort nicht findet, muss es ablehnen.
6. **Der Preflight des Browsers wird abgelehnt.** Vor einer Cross-Site-Anfrage mit Header `Authorization` sendet der Browser eine `OPTIONS`-Anfrage, den CORS-Preflight, der nie Anmeldedaten enthält. Verlangt der Server auch dort ein Token, antwortet er mit 401, und die eigentliche Anfrage geht nie hinaus. Beantworten Sie `OPTIONS` ohne Authentifizierung.
7. **Die Einrichtung des Servers selbst.** Bei IIS nennt die Zahl nach dem Punkt den Grund: 401.1 eine fehlgeschlagene Anmeldung, 401.2 die Authentifizierungseinstellungen des Servers, 401.3 Dateiberechtigungen; Microsofts [Liste der IIS-Statuscodes](https://learn.microsoft.com/de-de/troubleshoot/developer/webapps/iis/health-diagnostic-performance/http-status-code) enthält den Rest. Im IIS-Manager zeigt das Feature **Authentication** (Authentifizierung) der Website, welche Verfahren aktiviert sind.

Stößt Ihr Crawler auf einen 401, liegt die Seite hinter einem Login: Sammeln Sie nur öffentliche Seiten, oder nutzen Sie die offizielle API der Website mit einem Schlüssel, der für Sie ausgestellt wurde. Wiederholen Sie einen 401 nie in einer Schleife; ohne neue Anmeldedaten kann der Versuch nicht gelingen.

## Wie testen Sie einen 401 mit cURL?

`curl -i` gibt die Statuszeile und die Antwort-Header über dem Antworttext aus; das genügt, um einen 401 und seine Challenge zu sehen. Wir haben auf unserem eigenen Computer eine kleine Test-API in Node.js geschrieben, deren Endpunkt `/api/profile` mit 401 antwortet, solange die Anfrage nicht `demo-token-123` enthält, ein erfundenes Token. Aufgerufen haben wir sie mit dem in Windows 11 eingebauten cURL 8.22:

```bash
curl -i http://localhost:8401/api/profile
```

```text
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
Content-Type: application/json
Content-Length: 21
Date: Thu, 12 Nov 2026 01:20:35 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{"error":"no token"}
```

Dann mit dem Token:

```bash
curl -i -H "Authorization: Bearer demo-token-123" http://localhost:8401/api/profile
```

```text
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 16
Date: Thu, 12 Nov 2026 01:20:35 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{"user":"demo"}
```

Mit einem veralteten Token antwortete der Server mit 401 und `error="invalid_token"`. In Windows PowerShell 5.1 ist `curl` eine Abkürzung für Invoke-WebRequest; tippen Sie dort deshalb `curl.exe`.

## Was ist der Unterschied zwischen einem API-Schlüssel und einem OAuth-Token?

Ein API-Schlüssel ist ein langlebiges Geheimnis, das Ihre Anwendung oder Ihr Konto ausweist; ein OAuth-Zugriffstoken ist ein kurzlebiger Ausweis, der nach einer Anmeldung ausgestellt wird.

| Frage | API-Schlüssel | OAuth-Zugriffstoken |
|---|---|---|
| Ausgestellt von | Dem Dashboard des Dienstes | Einem Anmeldeserver, nach einer Anmeldung |
| Gültigkeit | Bis zum Löschen oder Rotieren | Minuten oder Stunden; ein Refresh-Token erneuert es |
| Gesendet als | Header oder Parameter, den die API vorgibt | `Authorization: Bearer <token>` |
| Typische 401-Ursache | Vertippt, gelöscht oder an der falschen Stelle | Abgelaufen oder für eine andere API ausgestellt |

Ein Token ohne den passenden Scope, also die Liste dessen, was es tun darf, bekommt einen 403 statt eines 401. Bewahren Sie Schlüssel und Tokens in Umgebungsvariablen oder einem Secrets-Manager auf, nie in einem Code-Repository.

## Wo Ihnen ein 401 begegnen kann

- Admin-Bereiche und Testserver, die mit dem Anmeldefenster des Browsers geschützt sind.
- Seiten im Firmen-Intranet, die die Windows-Anmeldung nutzen.
- APIs und Webhooks nach einer Schlüsselrotation oder dem Ablauf eines Tokens.
- Postman- oder Bruno-Collections mit einem veralteten Token.
- Crawler und Monitoring-Skripte, die Seiten hinter einem Login erreichen.

## Häufige Fehler

- **Einen 401 wie einen 403 behandeln.** Mehr Berechtigungen helfen nicht, wenn das Token fehlt.
- **In einer Schleife wiederholen**, was ein Konto sperren oder ein Rate Limit auslösen kann.
- **Echte Tokens einfügen**, in Tickets, Screenshots oder geteilte `curl -v`-Ausgaben.
- **Auf dem Server ein Token für `OPTIONS` verlangen.**
- **Einen 401 ohne `WWW-Authenticate` senden**, obwohl der Standard den Header vorschreibt.

## Entscheidungshilfe

| Ihre Lage | Was tun |
|---|---|
| Chrome zeigt „HTTP ERROR 401“ | Neu anmelden, dann die Cookies dieser Website löschen |
| Der Browser fragt immer wieder nach einem Passwort | Die Anmeldedaten mit der Person klären, die Ihnen den Zugang gab |
| „Access is denied due to invalid credentials“ | Ihr Arbeitskonto verwenden; Admins lesen den 401.x-Code |
| Keine Zeile `> Authorization:` in `curl -v` | Die Variable oder Weiterleitung korrigieren, die den Header verwirft |
| `error="invalid_token"` | Ein neues Token holen und einmal wiederholen |
| 407 statt 401 | Die Proxy-Anmeldedaten korrigieren, nicht den Login auf der Website |

## Häufige Fragen

### Warum bekomme ich 401 Unauthorized in Postman?

Meist sendet die Anfrage nicht das Token, das Sie vermuten. Im Tab **Authorization** der Anfrage zeigt die Liste **Auth type**, ob sie ihre eigene Einstellung nutzt oder eine aus ihrer Collection oder ihrem Ordner (unter **Inherited**). Kommt das Token aus einer Variablen, wählen Sie die richtige Umgebung (Environment) und prüfen Sie, ob das Token noch gültig ist.

### Was bedeutet „Access is denied due to invalid credentials“?

Das ist die Standard-401-Seite von IIS, dem Webserver von Microsoft: Er hat die Anmeldedaten, die Ihr Browser gesendet hat, nicht akzeptiert oder konnte Sie mit dem eingestellten Verfahren nicht anmelden. Besucher verwenden das richtige Arbeitskonto oder fragen die IT; Administratoren lesen die 401.x-Nummer.

### Bin ich an einem 401-Fehler schuld oder die Website?

Meist ist es ein Anmeldeproblem, das Sie selbst beheben können: eine abgelaufene Sitzung, ein veraltetes Cookie, das falsche gespeicherte Konto. Scheitern die richtigen Anmeldedaten auch mit frischen Cookies, ist die Anmeldung der Website defekt.

### Warum hat eine 401-Antwort keinen Antworttext?

Der Standard verlangt keinen; er verlangt den Header `WWW-Authenticate`, lesen Sie also die Header. Ein Browser, der einen leeren 401 bekommt, zeigt seine eigene Seite; in unserem Test zeigte Chromium „Diese Seite funktioniert nicht“.

### Kann ein VPN oder Proxy einen 401-Fehler verursachen?

Direkt selten: Ein Proxy, der Anmeldedaten verlangt, antwortet mit 407. Beide ändern aber Ihre IP-Adresse, und manche APIs akzeptieren einen Schlüssel nur von freigegebenen Adressen und lehnen andere mit 401 oder 403 ab. Für eine solche API behält ein [ISP-Proxy](https://proxynet.io/de/static-isp-residential-proxy) dieselbe Ausgangs-IP.

### Sollte mein Code einen 401 automatisch wiederholen?

Einmal, und nur nachdem er neue Anmeldedaten geholt hat, etwa ein erneuertes Token. Kommt dieselbe Challenge zurück, hören Sie auf und melden den Fehler.

## Fazit

Ein 401 Unauthorized bedeutet, dass der Server keine Anmeldedaten bekommen hat, die er akzeptiert, und `WWW-Authenticate` sagt, welche Art er will. Besucher prüfen die Adresse, melden sich neu an und löschen die Cookies der Website. Entwickler prüfen, ob der Header `Authorization` mit dem richtigen Schema und einem aktuellen Token gesendet wird. Für API-Arbeit, die eine feste Ausgangs-IP oder einen HTTPS-Tunnel braucht, vergleichen Sie die Optionen auf [unserer Proxy-Seite](/de/proxy).