HTTP 401 Fehler (Unauthorized): Bedeutung & Lösung

Was ist ein 401 Unauthorized Fehler?

Ein 401-Fehler (Unauthorized) bedeutet: Der Server verlangt einen Identitätsnachweis, und Ihre Anfrage hat ihn nicht geliefert oder Anmeldedaten mitgeschickt, die abgelehnt wurden. Kein Passwort, ein falsches Passwort, ein abgelaufenes Token oder ein fehlender API-Schlüssel enden alle gleich.

Der HTTP-Standard beschreibt ihn als Anfrage, der „gültige Authentifizierungsdaten für die Zielressource fehlen“, und ein Server, der ein 401 sendet, MUSS einen WWW-Authenticate-Header mitschicken, der angibt, welches Anmeldeverfahren er akzeptiert (RFC 9110 §15.5.2).

Einfach gesagt fragt der Server „Wer sind Sie?“, bevor er Sie hineinlässt.

Wie ein 401-Fehler aussieht

Welche Seite Sie sehen, hängt vom Server und von der App ab:

• 401 Unauthorized — die Standard-Statuszeile und die Formulierung der meisten Apps
• 401 Authorization Required — der Titel der eingebauten 401-Seite von nginx, darunter „nginx“ (meist mit Versionsnummer) (nginx-Quellcode); alte Apache-2.2-Server verwenden dieselben Worte
• Unauthorized · This server could not verify that you are authorized to access the document requested — die Standardseite von Apache
• 401 - Unauthorized: Access is denied due to invalid credentials — IIS; die Detailseite (nur auf dem Server selbst sichtbar) und das IIS-Log nennen den Grund als 401.1, 401.2 oder 401.3: Anmeldung fehlgeschlagen, Serverkonfiguration oder Dateiberechtigungen
• Ein Anmeldefenster im Browser — wenn der Server HTTP Basic oder Digest verlangt, oder (bei IIS und in Firmen-Intranets) NTLM oder Negotiate
• Diese Seite funktioniert nicht · HTTP ERROR 401 — Chrome, wenn die 401-Antwort keine eigene Seite mitbringt
• JSON einer API, zum Beispiel {"error":{"message":"Missing Authentication header","code":401}}

Das Anmeldefenster zeigen Browser nur bei diesen Anmeldeverfahren. Token-basierte APIs („Bearer“) lösen es nie aus; ihr 401 kommt als JSON zurück, das die App verarbeitet. Websites mit Login-Formular schicken einen abgemeldeten Besucher meist per 302-Weiterleitung auf die Login-Seite, statt ein 401 zu senden.

„401 Authorization Required“ bei nginx

Dieser Titel stammt von der eingebauten 401-Seite von nginx. Sie sehen ihn, wenn ein Pfad mit auth_basic geschützt ist und die Anfrage keinen oder einen falschen Benutzernamen samt Passwort enthielt; auch wenn Sie das Anmeldefenster des Browsers abbrechen, erscheint diese Seite.

Als Besucher laden Sie die Seite neu und geben den Benutzernamen und das Passwort ein, die der Betreiber der Website Ihnen genannt hat. Beides ist unabhängig von Konten auf der Website: Basic-Authentifizierung prüft eine Passwortdatei auf dem Server.

Als Betreiber richten Sie den Schutz so ein und halten einen Pfad für alle offen:

# Create the password file (htpasswd comes with apache2-utils or httpd-tools)
#   sudo htpasswd -c /etc/nginx/.htpasswd alice   # -c creates the file: leave it out when adding users

location /admin/ {
    auth_basic           "Admin area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

# Inside a protected server block, open one path to everyone
location /public/ {
    auth_basic off;
}

# Test, then reload
#   curl -I -u alice:PASSWORD https://example.com/admin/
#   sudo nginx -t && sudo systemctl reload nginx

Trotz richtigem Passwort weiter 401? Prüfen Sie, ob der Benutzer in der Datei steht (htpasswd -c überschreibt die Datei und entfernt frühere Benutzer) und ob die App hinter nginx den Authorization-Header ebenfalls braucht: Der Basic-Login von nginx und die Bearer-Tokens einer App nutzen beide diesen Header, daher erhält die App die Zugangsdaten von nginx und lehnt sie ab.

401 vs 403: Was ist der Unterschied?

Die Statuscodes 401 und 403 werden oft verwechselt. Kurz gesagt: 401 bedeutet „Ich weiß nicht, wer Sie sind“, 403 bedeutet „Ich lasse Sie nicht hinein“, ganz gleich, ob Ihre Identität das Problem ist.

Eine praktische Regel: Wenn die Angabe des richtigen Benutzernamens und Passworts (oder API-Schlüssels) das Problem beheben würde, sollte der Server 401 zurückgeben. Wenn der Benutzer bereits authentifiziert ist, aber einfach keinen Zugriff auf diese Ressource hat, sollte der Server 403 Forbidden zurückgeben.

Häufige Ursachen für 401-Fehler

Die Ursachen, von der Seite des Besuchers bis zur Seite des Servers:

• Falscher Benutzername oder falsches Passwort — die einfachste Ursache, besonders nach dem Zurücksetzen des Passworts
• Abgelaufenes Authentifizierungs-Token — JWTs, OAuth-Zugriffstoken und Session-Cookies laufen alle irgendwann ab
• Fehlender Authorization-Header — die Anfrage enthielt überhaupt keine Anmeldedaten
• Ungültiger API-Schlüssel — der Schlüssel wurde widerrufen, rotiert oder falsch kopiert
• Falsches Auth-Schema — der Server erwartet ein Bearer-Token, erhält aber Basic Auth, oder umgekehrt
• Zeitabweichung — der Server, der ein JWT prüft, und der, der es ausgestellt hat (oder Ihr Rechner, wenn er das JWT signiert), sind sich über die Uhrzeit uneins; viele Bibliotheken erlauben gar keine Toleranz
• Ein CORS-Preflight — die OPTIONS-Prüfung des Browsers enthält nie Anmeldedaten, daher antwortet ein Server, der sie verlangt, mit 401 und die eigentliche Anfrage wird nie gesendet
• Eine veraltete Sitzung — der Browser sendet ein Session-Cookie, das der Server bereits beendet hat
• Etwas dazwischen verwirft den Header — Apache verbirgt Authorization vor PHP-FPM und CGI-Skripten, wenn nichts anderes konfiguriert ist, CloudFront entfernt ihn standardmäßig bei GET- und HEAD-Anfragen, und nginx-Basic-Auth vor einer App übernimmt ihn
• Gesperrte oder widerrufene Anmeldedaten — zu viele Fehlversuche können ein Konto sperren (manche APIs antworten darauf stattdessen mit 429 Too Many Requests)

So beheben Sie 401 als Besucher

Wenn Sie auf einer Website, die Sie besuchen möchten, einen 401-Fehler erhalten, hängt das Problem fast immer mit Ihren Anmeldedaten zusammen. Befolgen Sie diese Schritte der Reihe nach.

1. Überprüfen Sie Ihre Anmeldedaten

Die häufigste Ursache für einen 401-Fehler sind einfach falsche Anmeldedaten. Wenn die Website ein Anmelde-Popup oder -Formular anzeigt, überprüfen Sie Ihren Benutzernamen und Ihr Passwort noch einmal.

Häufige Fehler: Die Feststelltaste ist aktiviert, Sie verwenden ein altes Passwort (insbesondere nach einer kürzlichen Änderung) oder Sie melden sich beim falschen Konto an. Wenn Sie einen Passwort-Manager verwenden, lassen Sie die Anmeldedaten automatisch ausfüllen, um Tippfehler zu vermeiden.

2. Browser-Cache und Cookies löschen

Ihr Browser sendet möglicherweise ein abgelaufenes Session-Cookie. Wenn Sie die Cookies der Website löschen, verlangt sie eine frische Anmeldung.

In Chrome mit deutscher Oberfläche öffnen Sie mit Strg+Umschalt+Entf (Mac: Cmd+Umschalt+Entf) „Browserdaten löschen“, wählen als Zeitraum statt „Letzte Stunde“ den Eintrag „Gesamte Zeit“, haken „Cookies und andere Websitedaten“ sowie „Im Cache gespeicherte Bilder und Dateien“ an und klicken auf „Daten löschen“. Dadurch werden Sie auf allen Websites abgemeldet. Nur für eine Website: links neben der Adresse „Website-Informationen anzeigen“ → „Cookies und Websitedaten“ → „Websitedaten auf dem Gerät verwalten“. Die Schritte für andere Browser (englische Bezeichnungen):

Chrome, Edge, Firefox: Ctrl+Shift+Delete (Cmd+Shift+Delete on a Mac)
  → Time range: All time → Cookies and site data + Cached files → Delete / Clear
  (this signs you out of every site; the per-site option below doesn't)
Safari: Settings → Privacy → Manage Website Data → the site → Remove
One site in Chrome: the icon left of the address → Site settings → Delete data

Schließen Sie nach dem Löschen den Browser vollständig (nicht nur den Tab), öffnen Sie ihn erneut und navigieren Sie wieder zur Seite. Sie sollten eine frische Anmeldeaufforderung sehen.

3. Inkognito- oder privaten Modus verwenden

Öffnen Sie die URL in einem Inkognito-Fenster (Chrome) oder einem privaten Fenster (Firefox/Safari). Dadurch werden alle zwischengespeicherten Cookies, Erweiterungen und gespeicherten Anmeldedaten umgangen.

Wenn die Seite im Inkognito-Modus funktioniert, aber nicht in Ihrem normalen Browser, liegt das Problem an einem zwischengespeicherten Cookie oder einer Browser-Erweiterung, die die Authentifizierung stört. Deaktivieren Sie die Erweiterungen einzeln, um die Ursache zu finden.

4. URL überprüfen

Stellen Sie sicher, dass Sie die richtige URL besuchen. Einige Server geben 401 für Pfade zurück, die eine Authentifizierung erfordern, auch wenn der Pfad selbst falsch ist. Möglicherweise versuchen Sie, auf einen eingeschränkten Bereich zuzugreifen, den Sie nicht besuchen sollten.

Prüfen Sie, ob es eine öffentliche Version der Seite unter einer anderen URL gibt. Zum Beispiel könnte example.com/admin/ 401 zurückgeben, während example.com/ öffentlich zugänglich ist.

Sie sind nicht sicher, ob die Website überhaupt funktioniert? Der Website-Down-Checker ruft sie von 11 Standorten aus auf, sodass Sie ein Login-Problem von einem Ausfall unterscheiden können.

So beheben Sie 401 als Entwickler

Für Entwickler, die mit APIs arbeiten, drehen sich 401-Fehler normalerweise um den Authorization-Header, das Token-Format oder den Lebenszyklus der Anmeldedaten. Dies sind die gängigsten Lösungen.

5. Authorization-Header überprüfen

Der häufigste Entwicklerfehler ist ein fehlerhafter Authorization-Header. Wenn der Server einen WWW-Authenticate-Header sendet, nennt er das erwartete Schema; viele JSON-APIs (zum Beispiel die von GitHub und OpenRouter) lassen ihn weg und erklären das Problem stattdessen im Antworttext.

Prüfen Sie, ob Ihr Header dem erforderlichen Format entspricht. Die gängigsten Schemata sind Bearer (für Tokens) und Basic (Benutzername:Passwort, Base64-kodiert).

# Bearer token authentication (most APIs)
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." https://api.example.com/data

# Basic authentication (username:password in Base64)
curl -u "username:password" https://api.example.com/data
# Equivalent to:
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

# Common mistakes that cause 401:
# Missing "Bearer " prefix:  Authorization: eyJhbGci...  ← WRONG
# Extra space:               Authorization: Bearer  eyJ... ← many servers reject it
# Wrong scheme:              Authorization: Basic eyJhbGci... ← WRONG

Lesen Sie dann den WWW-Authenticate-Header der 401-Antwort: Er nennt das Schema, das der Server erwartet. Der HTTP-Header-Checker von DNS Robot zeigt die vollständige Antwort.

6. API-Schlüssel-Gültigkeit prüfen

API-Schlüssel funktionieren nicht mehr, wenn der Schlüssel rotiert oder widerrufen wurde, das Konto gesperrt oder herabgestuft ist oder ein Testschlüssel gegen die Produktion verwendet wird. (Ein Ratenlimit antwortet mit 429, und ein Schlüssel ohne Zugriff auf einen Endpunkt erhält meist 403.)

Prüfen Sie im Dashboard des Anbieters, ob der Schlüssel noch aktiv ist, und testen Sie ihn dann direkt:

# Test a key: print only the status code (a real GET; some APIs reject HEAD)
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer YOUR_API_KEY" https://api.example.com/me
# 200 = the key works
# 401 = the key is missing, wrong, revoked or expired
# 403 = the key works but isn't allowed to use this endpoint

# Common slips:
# 1. A space or newline after the key in .env:   API_KEY="abc123 "
# 2. The test key in production, or the reverse
# 3. An empty variable, so the header is just "Authorization: Bearer"

7. Token-Ablauf und -Erneuerung behandeln

JWTs und OAuth-Zugriffstoken haben eine begrenzte Lebensdauer, typischerweise 15 Minuten bis 24 Stunden. Nach dem Ablauf gibt jeder API-Aufruf 401 zurück, bis Sie ein neues Token erhalten.

Haben Sie ein Refresh-Token (OAuth 2.0 und die meisten JWT-Setups), tauschen Sie es gegen ein neues Zugriffstoken; ohne Refresh-Token melden Sie sich neu an.

# Read a JWT's payload (tokens use base64url, so plain base64 -d often fails)
python3 -c 'import sys,base64,json; p=sys.argv[1].split(".")[1]; print(json.dumps(json.loads(base64.urlsafe_b64decode(p+"==")),indent=2))' "$TOKEN"
# "exp" is a Unix timestamp; compare it with: date +%s

# OAuth 2.0: get a new access token with the refresh token
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=YOUR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID"

8. CORS-Preflight-Probleme beheben

Ruft eine Webseite eine API auf einer anderen Domain mit einem Authorization-Header auf, sendet der Browser zuerst eine OPTIONS-Preflight-Anfrage, und dieser Preflight enthält nie Anmeldedaten. Verlangt der Server Authentifizierung für OPTIONS, antwortet er mit 401, der Preflight scheitert, und der Browser meldet einen CORS-Fehler: Die eigentliche Anfrage wird nie gesendet.

Die Lösung: OPTIONS-Anfragen auf CORS-fähigen Endpunkten ohne Authentifizierung durchlassen.

# Nginx — allow OPTIONS requests without auth
location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin https://app.example.com;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "Authorization, Content-Type";
        add_header Access-Control-Max-Age 86400;
        return 204;
    }

    # CORS header on every other answer, the 401 included, or the browser reports a CORS error
    add_header Access-Control-Allow-Origin https://app.example.com always;

    # Normal auth for other methods
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

So beheben Sie 401 als Website-Betreiber

Wenn Ihre Besucher oder Benutzer 401-Fehler melden, liegt das Problem in der Authentifizierungskonfiguration Ihres Servers. Gehen Sie diese Prüfungen durch.

9. Server-Authentifizierungskonfiguration überprüfen

Stellen Sie sicher, dass die Authentifizierung nur für die Routen aktiviert ist, die sie brauchen. Ein häufiger Fehler ist es, ein ganzes Verzeichnis oder die gesamte Website zu schützen, obwohl nur bestimmte Pfade eine Anmeldung verlangen sollten.

Prüfen Sie bei nginx Ihre auth_basic-Direktiven, bei Apache AuthType und Require. Kontrollieren Sie bei Node.js/Express die Reihenfolge der Middleware: Ein app.use(auth), das vor Ihren öffentlichen Routen registriert wird, schützt auch diese. Registrieren Sie die öffentlichen Routen daher zuerst oder hängen Sie die Authentifizierung nur an den geschützten Router.

# Nginx — WRONG: protects everything, including public pages
server {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # All pages now require login — including your homepage!
}

# Nginx — CORRECT: only protect admin routes
server {
    location / {
        # Public — no auth required
    }
    location /admin/ {
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

10. .htaccess-Authentifizierungsregeln prüfen

Bei Apache können .htaccess-Dateien Basic- oder Digest-Authentifizierung für ein Verzeichnis einschalten. Hat ein öffentliches Verzeichnis eine .htaccess mit den Direktiven AuthType und Require, erhält jeder Besucher eine 401-Anmeldeaufforderung.

Suchen Sie nach .htaccess-Dateien im betroffenen Verzeichnis und in allen übergeordneten Verzeichnissen — Apache wendet die Regeln jeder .htaccess im Pfad an.

# Find all .htaccess files with auth rules
find /var/www/html -name '.htaccess' -exec grep -l 'AuthType\|AuthUserFile\|Require valid-user' {} \;

# Example .htaccess that causes 401 for everyone:
# AuthType Basic
# AuthName "Restricted Area"
# AuthUserFile /etc/apache2/.htpasswd
# Require valid-user

# Fix: remove auth lines from public directories,
# or move them to the specific /admin/.htaccess only

11. Sicherstellen, dass der Authorization-Header Ihre App erreicht

Der Client sendet korrekte Anmeldedaten, aber die App sieht sie nie. Hier geht der Header verloren:

nginx leitet Authorization standardmäßig an das Backend weiter, zusätzliche Zeilen sind also nicht nötig; verwendet derselbe Pfad jedoch auth_basic, übernimmt der Login von nginx den Header (siehe den nginx-Abschnitt oben). Apache verbirgt Authorization vor PHP-FPM und CGI-Skripten, wenn Sie nicht CGIPassAuth einschalten (Apache 2.4.13+), die klassische Ursache für 401-Fehler bei WordPress- und Laravel-APIs hinter Apache.

# Apache 2.4.13+ (inside a <Directory> block, or .htaccess): pass Authorization to PHP-FPM and CGI
CGIPassAuth On

# Older Apache: copy it into an environment variable instead
SetEnvIf Authorization "(.+)" HTTP_AUTHORIZATION=$1

401-Fehler mit HTTP-Headern debuggen

Am schnellsten diagnostizieren Sie ein 401, indem Sie die Antwort lesen: Der WWW-Authenticate-Header nennt, sofern der Server ihn sendet, welche Anmeldung er verlangt, und JSON-APIs erklären den Fehler meist im Antworttext.

Nutzen Sie den HTTP-Header-Checker von DNS Robot (erscheint das 401 erst nach einer Weiterleitung, zeigt der Redirect Checker, welcher Hop es liefert) oder curl im Terminal:

# Print the response headers of a real GET
curl -sS -D - -o /dev/null https://api.example.com/protected-endpoint

# A 401 often carries one of:
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# WWW-Authenticate: Basic realm="Admin Area"

# It tells you:
# - the scheme (Bearer, Basic, Digest, Negotiate)
# - the realm (which area is protected)
# - for Bearer tokens, the error: invalid_request, invalid_token or insufficient_scope

Steht in WWW-Authenticate Bearer, brauchen Sie ein Token; bei Basic einen Benutzernamen und ein Passwort. error="invalid_token" bedeutet, dass das Token abgelaufen, widerrufen, fehlerhaft oder anderweitig ungültig ist. Gar kein Header? Lesen Sie den Antworttext: Viele APIs nennen den Grund dort.

Beeinflusst ein 401-Fehler die SEO?

Ein 401 auf einer öffentlichen Seite nimmt sie aus Google heraus. Google behandelt alle 4xx-Codes außer 429 gleich: Der Crawler meldet, dass der Inhalt nicht existiert, und eine indexierte URL wird entfernt (Googles Crawler-Dokumentation).

401-Fehler auf Seiten, die eine Anmeldung verlangen sollen (Admin-Bereiche, Dashboards, APIs), sind normal: Google bestraft eine Website dafür nicht. Setzen Sie 401 oder 403 aber nicht ein, um Googlebot zu bremsen; laut Google haben sie keinen Einfluss auf die Crawling-Rate.

Das Problem ist ein 401 auf Seiten, die öffentlich sein sollten, meist durch Authentifizierung für die gesamte Website oder durch eine CDN- oder Proxy-Regel, die für öffentliche Pfade Anmeldedaten verlangt.

So verhindern Sie 401-Fehler

Vorbeugung erspart Ihnen späteres Debugging. Befolgen Sie diese Praktiken, um 401-Fehler in Ihren Anwendungen und Websites zu minimieren.

• Automatische Token-Erneuerung einbauen — nutzen Sie Refresh-Tokens, um unbemerkt neue Zugriffstoken zu holen, bevor die alten ablaufen
• Schutz nur dort, wo er nötig ist — schützen Sie nur Routen, die wirklich eine Authentifizierung brauchen, und lassen Sie öffentliche Seiten offen
• Klare Fehlermeldungen liefern — senden Sie zum 401 einen hilfreichen JSON-Fehlertext, nicht nur den Statuscode
• Auth-Fehler überwachen — richten Sie Warnungen für Spitzen bei 401-Antworten ein; sie können auf Probleme mit Anmeldedaten oder auf Angriffe hindeuten
• Serveruhren synchronisieren — halten Sie alle Server per NTP auf wenige Sekunden genau an UTC, damit JWTs nicht wegen Zeitabweichung abgelehnt werden
• Mit dem HTTP-Header-Checker testen — prüfen Sie regelmäßig, dass öffentliche Seiten 200 und geschützte Seiten wie erwartet 401 zurückgeben
• Das Auth-Schema dokumentieren — beschreiben Sie das erwartete Format des Authorization-Headers in Ihrer API-Dokumentation
• CORS-Preflight berücksichtigen — erlauben Sie bei API-Endpunkten OPTIONS-Anfragen immer ohne Authentifizierung