HTTP 401 Unauthorized Fehler: Vollständige Diagnose- und Lösungsanleitung

Der HTTP 401 Unauthorized-Statuscode bedeutet, dass der Server Ihre Anfrage erhalten hat, aber die Verarbeitung verweigert, weil gültige Authentifizierungsdaten entweder fehlten, falsch oder abgelaufen waren. Im Gegensatz zu einem 403 Forbidden-Fehler — bei dem der Server Sie erkennt, aber den Zugriff aufgrund von Berechtigungen verweigert — signalisiert ein 401 speziell einen Authentifizierungsfehler: Der Server weiß nicht, wer Sie sind, oder kann dies nicht überprüfen.

Dieser Unterschied ist wichtig. Eine 401-Antwort enthält immer einen WWW-Authenticate-Header in der Serverantwort, der dem Client mitteilt, welches Authentifizierungsschema zu verwenden ist. Wenn dieser Header fehlt, haben Sie es möglicherweise mit einem falsch konfigurierten Server zu tun und nicht mit einem Anmeldedatenproblem. Den genauen Fehlermodus zu kennen, bevor Sie mit der Fehlerbehebung beginnen, spart erheblich Zeit.

Wie eine 401-Antwort tatsächlich aussieht

Der Fehler erscheint unter verschiedenen Nachrichtenvarianten, abhängig von der Serversoftware, dem Framework oder dem CDN vor der Anwendung:

• 401 Unauthorized
• HTTP Error 401 – Unauthorized
• 401 Unauthorized: Access is denied due to invalid credentials
• Authorization Required
• 401 Authorization Required (häufig in NGINX)
• HTTP 401 (API-Clients, Postman, curl)

All diese entsprechen demselben in RFC 9110 definierten Statuscode. Die Variation in der Formulierung ist rein kosmetisch — bedingt durch den Webserver, Reverse Proxy oder das Anwendungs-Framework, das die Antwort generiert.

Die technische Anatomie eines 401-Fehlers

Das Verständnis dessen, was auf Protokollebene passiert, verhindert Ratespiele. Wenn ein Client eine Anfrage an eine geschützte Ressource ohne Anmeldedaten sendet, antwortet der Server mit:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example", error="invalid_token"
Content-Type: application/json

Der WWW-Authenticate-Header ist die Herausforderung des Servers. Er teilt dem Client genau mit, welches Schema — Basic, Bearer, Digest, NTLM oder ein benutzerdefiniertes Schema — erforderlich ist. Ein Client, der diesen Header ignoriert und ohne Anpassung seiner Anfrage erneut versucht, wird endlos in einer Schleife laufen.

401 vs. 403 vs. 407: Den Unterschied kennen

Einen 403 als 401 zu identifizieren ist ein häufiger Entwicklerfehler. Wenn Ihr Server 401 zurückgibt, aber WWW-Authenticate weglässt, ist er technisch nicht konform mit RFC 9110 — und einige strenge HTTP-Clients werden die Antwort als fehlerhaft behandeln.

Grundursachen eines 401 Unauthorized-Fehlers

Probleme mit Anmeldedaten und Token

• Falscher Benutzername oder falsches Passwort — die häufigste Ursache für den browserbasierten Zugriff
• Abgelaufene Zugriffstoken — OAuth 2.0 Bearer-Token haben einen endlichen expires_in-Wert; nach Ablauf gibt jede Anfrage 401 zurück, bis das Token erneuert wird
• Widerrufene API-Schlüssel — Schlüssel können serverseitig ungültig gemacht werden, ohne dass der Client benachrichtigt wird
• JWT-Signaturabweichung — wenn das Signierungsgeheimnis rotiert und der Client ein mit dem alten Geheimnis signiertes Token hält, schlägt die Überprüfung lautlos fehl
• Zeitabweichung (Clock Skew) — JWTs enthalten iat– (ausgestellt um) und exp– (Ablauf) Claims, die gegen die Serverzeit validiert werden; eine Clientuhr, die mehr als einige Minuten abweicht, kann dazu führen, dass gültige Token abgelehnt werden

Fehlende oder fehlerhafte Authorization-Header

Jedes Authentifizierungsschema hat ein genaues Header-Format. Eine Abweichung davon — selbst durch ein einzelnes Leerzeichen oder falsche Base64-Auffüllung — erzeugt einen 401:

# Correct Basic Auth header
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

# Correct Bearer token header
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Ein häufiger Fehler ist das Senden von Authorization: bearer <token> (Kleinbuchstaben b). Obwohl RFC 6750 besagt, dass der Schemaname nicht zwischen Groß- und Kleinschreibung unterscheidet, führen viele serverseitige Bibliotheken einen strikten Zeichenfolgenvergleich durch und lehnen die Kleinschreibungsvariante ab.

Serverseitige Fehlkonfiguration

• Falsche erzwungene Authentifizierungsmethode — ein für OAuth 2.0 konfigurierter Server, der Basic Auth-Header empfängt, wird diese ablehnen
• .htaccess-Direktiven — bei Apache sperrt eine falsch konfigurierte AuthType-, AuthName– oder Require-Direktive in .htaccess jede Anfrage hinter einer Passwortabfrage
• NGINX auth_basic-Blöcke — eine auf den falschen location-Block angewendete auth_basic-Direktive kann legitime Benutzer aussperren
• Reverse Proxy entfernt Header — Load Balancer und Reverse Proxies (NGINX, HAProxy, Cloudflare) können Authorization-Header entfernen oder umschreiben, bevor sie den Ursprungsserver erreichen

Browser- und clientseitige Eingriffe

• Beschädigte Cookies — Sitzungs-Cookies, die den Authentifizierungsstatus tragen, können nach einer serverseitigen Sitzungsinvalidierung beschädigt oder nicht übereinstimmend werden
• Aggressive Browser-Erweiterungen — Werbeblocker, Datenschutzerweiterungen und VPN-Erweiterungen können Anfrage-Header ändern oder entfernen
• CORS-Preflight-Fehler — bei Cross-Origin-API-Aufrufen sendet der Browser eine OPTIONS-Preflight-Anfrage; wenn der Server nicht korrekt darauf antwortet, wird die eigentliche authentifizierte Anfrage nie gesendet

Infrastruktur- und Netzwerkfaktoren

• Firewall-Regeln blockieren Authentifizierungsendpunkte — WAFs (Web Application Firewalls) mit übermäßig aggressiven Regeln können Anfragen mit Authorization-Headern als potenzielle Injection-Angriffe markieren und ablehnen
• CDN cached authentifizierte Antworten — wenn ein CDN eine 401-Antwort cached und sie an nachfolgende Benutzer ausliefert, scheinen selbst gültige Anmeldedaten zu scheitern
• IP-basierte Ratenbegrenzung — wiederholte fehlgeschlagene Authentifizierungsversuche können eine temporäre Sperre auslösen, die für alle Anfragen von dieser IP 401 zurückgibt

So beheben Sie einen 401-Fehler: Schritt für Schritt

Für Endbenutzer und Browserzugriff

Schritt 1: Anmeldedaten genau überprüfen

Stellen Sie sicher, dass die Feststelltaste deaktiviert ist. Bestätigen Sie, dass Sie das aktuelle Passwort verwenden — nicht eines, das vor einem kürzlichen Zurücksetzen gespeichert wurde. Wenn Ihr Konto Multi-Faktor-Authentifizierung (MFA) verwendet, stellen Sie sicher, dass der Einmalcode nicht abgelaufen ist (TOTP-Codes sind standardmäßig 30 Sekunden gültig).

Schritt 2: Browser-Cookies und Cache leeren

Veraltete Sitzungs-Cookies sind eine anhaltende Quelle von 401-Schleifen. Navigieren Sie in Chrome zu chrome://settings/clearBrowserData, setzen Sie den Zeitraum auf Gesamte Zeit, aktivieren Sie Cookies und andere Websitedaten und Bilder und Dateien im Cache, und löschen Sie dann. Verwenden Sie in Firefox about:preferences#privacy und klicken Sie auf Daten löschen.

Schließen Sie nach dem Löschen alle Browser-Tabs für die betroffene Domain, bevor Sie es erneut versuchen — einige Browser behalten den In-Memory-Sitzungsstatus bei, der einen Cache-Löschvorgang überlebt, wenn der Tab geöffnet bleibt.

Schritt 3: In einem privaten/Inkognito-Fenster testen

Ein privates Fenster startet ohne Cookies, ohne gecachte Daten und mit den meisten deaktivierten Erweiterungen. Wenn der 401-Fehler im Inkognito-Modus verschwindet, ist das Problem definitiv clientseitig: entweder ein beschädigtes Cookie, eine gecachte schlechte Antwort oder eine Browser-Erweiterung.

Schritt 4: Erweiterungen selektiv deaktivieren

Navigieren Sie zu chrome://extensions/ und deaktivieren Sie alle Erweiterungen. Laden Sie die Seite neu. Wenn die Authentifizierung erfolgreich ist, aktivieren Sie Erweiterungen eine nach der anderen wieder, um den Verursacher zu isolieren. Privacy Badger, uMatrix und bestimmte VPN-Erweiterungen sind häufige Übeltäter.

Schritt 5: URL auf Fehler überprüfen

Stellen Sie sicher, dass Sie nicht zu einem Pfad navigieren, der erhöhte Berechtigungen erfordert. Eine URL wie /admin/dashboard gibt 401 zurück, wenn Ihrer Sitzung Admin-Rechte fehlen — selbst wenn Ihre grundlegende Anmeldung gültig ist. Überprüfen Sie den genauen Pfad mit dem Website-Eigentümer oder der Dokumentation.

Schritt 6: Passwort zurücksetzen

Wenn ein Ablauf der Anmeldedaten vermutet wird, verwenden Sie den Passwort vergessen-Ablauf. Löschen Sie nach dem Zurücksetzen erneut die Cookies, bevor Sie sich anmelden — das alte Sitzungs-Cookie kann mit dem neuen Anmeldedatenstatus in Konflikt geraten.

Für Entwickler und API-Integrationen

Schritt 7: Die rohe HTTP-Antwort untersuchen

Bevor Sie etwas ändern, erfassen Sie die genaue Serverantwort mit curl mit ausführlicher Ausgabe:

curl -v -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/endpoint

Das -v-Flag zeigt sowohl gesendete Anfrage-Header als auch empfangene Antwort-Header, einschließlich der WWW-Authenticate-Herausforderung. Dies teilt Ihnen genau mit, welches Schema der Server erwartet.

Schritt 8: Token-Status validieren

Für JWT-Token dekodieren Sie die Nutzlast ohne Überprüfung der Signatur, um Claims zu untersuchen:

echo "YOUR_JWT_PAYLOAD_BASE64" | base64 --decode | python3 -m json.tool

Überprüfen Sie das exp-Feld (Unix-Zeitstempel). Vergleichen Sie es mit der aktuellen Zeit:

date +%s

Wenn exp kleiner als der aktuelle Zeitstempel ist, ist das Token abgelaufen. Implementieren Sie einen Aktualisierungsablauf über den Token-Endpunkt Ihres OAuth-Anbieters, bevor das Token abläuft.

Schritt 9: Serverseitige Authentifizierungskonfiguration prüfen

Untersuchen Sie bei Apache die relevante .htaccess– oder Virtual-Host-Konfiguration:

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Bestätigen Sie, dass der AuthUserFile-Pfad existiert und vom Webserver-Prozess lesbar ist. Überprüfen Sie bei NGINX den relevanten Server- oder Location-Block:

location /secure/ {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Stellen Sie sicher, dass die .htpasswd-Datei die korrekten gehashten Anmeldedaten enthält. Verwenden Sie htpasswd -v /etc/nginx/.htpasswd username, um ein Passwort gegen den gespeicherten Hash zu testen.

Schritt 10: Server-Logs überprüfen

Server-Logs liefern die Grundwahrheit. Bei Apache:

tail -f /var/log/apache2/error.log | grep 401

Bei NGINX:

tail -f /var/log/nginx/error.log | grep 401

Überprüfen Sie für die Authentifizierung auf Anwendungsebene (Node.js, Django, Laravel) die eigene Log-Ausgabe der Anwendung. Der Log-Eintrag gibt oft an, ob der Fehler auf einen fehlenden Header, ein ungültiges Token oder einen Datenbankabfragefehler zurückzuführen ist.

Schritt 11: Reverse Proxy Header-Weiterleitung überprüfen

Wenn Ihre Anwendung hinter NGINX als Reverse Proxy sitzt, stellen Sie sicher, dass der Authorization-Header an die Upstream-Anwendung weitergeleitet wird:

location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Authorization $http_authorization;
    proxy_pass_header Authorization;
}

Ohne proxy_pass_header Authorization entfernt NGINX den Header, bevor er Ihren Anwendungsserver erreicht — was einen 401 verursacht, der wie ein Client-Fehler aussieht, aber vollständig infrastrukturbedingt ist.

Schritt 12: WAF- und Firewall-Regeln untersuchen

Wenn Sie eine WAF (ModSecurity, Cloudflare WAF, AWS WAF) betreiben, überprüfen Sie, ob eine Regel Anfragen mit Authorization-Headern abgleicht und blockiert. Setzen Sie die WAF vorübergehend in den Nur-Erkennungs-Modus und versuchen Sie es erneut. Wenn der 401-Fehler verschwindet, verfeinern Sie die betreffende Regel, anstatt die WAF vollständig zu deaktivieren.

Schritt 13: CDN-Caching-Verhalten prüfen

Stellen Sie sicher, dass Ihr CDN keine 401-Antworten cached. Legen Sie in Cloudflare eine Cache-Regel fest, um den Cache für authentifizierte Endpunkte zu umgehen. Konfigurieren Sie in AWS CloudFront das Verhalten so, dass der Authorization-Header an den Ursprung weitergeleitet wird — standardmäßig entfernt CloudFront ihn, was bedeutet, dass Ihr Ursprung nie Anmeldedaten erhält und immer 401 zurückgibt.

Robuste Authentifizierung implementieren: Best Practices für Server-Eigentümer

Wenn Sie eine Webanwendung oder API verwalten — ob in einer VPS Hosting-Umgebung oder auf einem Dedicated Server — verhindern diese Praktiken, dass 401-Fehler Ihre Benutzer überhaupt erreichen.

Token-Lebenszyklus-Management

Stellen Sie niemals Token ohne definierten Ablauf aus. Verwenden Sie für OAuth 2.0 kurzlebige Zugriffstoken (15–60 Minuten) in Kombination mit langlebigen Refresh-Token. Implementieren Sie proaktive Token-Aktualisierung: Lösen Sie eine Aktualisierung aus, wenn das Zugriffstoken weniger als 20 % seiner Lebensdauer verbleibend hat, nicht nachdem es bereits abgelaufen ist.

Access Token TTL:  15 minutes
Refresh Token TTL: 30 days (rotated on each use)
Refresh trigger:   < 3 minutes remaining on access token

Implementieren Sie für JWT-basierte Systeme eine Schlüsselrotation mit einer Übergangsfrist. Beim Rotieren des Signierungsgeheimnisses halten Sie das alte Geheimnis für eine zusätzliche Token-Lebensdauer gültig, damit laufende Token nicht sofort ungültig werden.

Aussagekräftige Fehlerantworten

Eine 401-Antwort sollte immer einen Body enthalten, der dem Client hilft zu verstehen, was als nächstes zu tun ist:

{
  "error": "invalid_token",
  "error_description": "The access token expired at 2024-01-15T10:30:00Z",
  "error_uri": "https://api.example.com/docs/authentication"
}

Vage 401-Antworten, die nur einen Statuscode zurückgeben, zwingen Entwickler dazu, den Fehlergrund zu erraten, was die Support-Last erheblich erhöht.

Authentifizierungs-Logging und Alerting

Protokollieren Sie jeden Authentifizierungsfehler mit ausreichend Kontext: Zeitstempel, IP-Adresse, User Agent, angeforderte Ressource und Fehlergrund. Richten Sie Warnmeldungen für anomale Muster ein — ein Anstieg von 401-Fehlern von einer einzelnen IP weist entweder auf eine Fehlkonfiguration oder einen Credential-Stuffing-Angriff hin. Plattformen, die auf Dedicated Servers laufen, haben vollen Zugriff auf Logs auf Systemebene und können benutzerdefinierte Alerting-Pipelines ohne Einschränkungen implementieren.

Sichere Übertragung von Anmeldedaten

Authentifizierungsdaten dürfen nur über verschlüsselte Verbindungen übertragen werden. Wenn Ihre Anwendung Benutzeranmeldungen verarbeitet, ist ein SSL-Zertifikat unabdingbar — die Übertragung von Basic Auth-Anmeldedaten über einfaches HTTP legt Base64-kodierte Benutzernamen und Passwörter im Klartext auf der Leitung offen.

API-Schlüssel-Scoping und -Rotation

Stellen Sie API-Schlüssel mit dem minimal erforderlichen Umfang aus. Implementieren Sie eine Schlüsselrotationsrichtlinie und stellen Sie Clients einen Rotationsmechanismus zur Verfügung, der es ihnen ermöglicht, Schlüssel ohne Ausfallzeiten auszutauschen. Widerrufen Sie kompromittierte Schlüssel sofort und benachrichtigen Sie betroffene Clients über einen dokumentierten Kanal.

Authentifizierungsabläufe in CI/CD testen

Integrieren Sie Authentifizierungsablauftests in Ihre Deployment-Pipeline. Eine Testsuite, die gültige Anmeldedaten, abgelaufene Token, fehlende Header und widerrufene Schlüssel überprüft, erkennt Regressionen, bevor sie die Produktion erreichen. Dies ist besonders kritisch nach Abhängigkeitsaktualisierungen, die Authentifizierungs-Middleware betreffen.

401-Fehler in spezifischen Umgebungen

WordPress

WordPress gibt 401 auf seiner REST API (/wp-json/) zurück, wenn Anwendungspasswörter falsch konfiguriert sind oder wenn ein Sicherheits-Plugin (Wordfence, iThemes Security) den REST API-Zugriff blockiert. Überprüfen Sie Settings > Permalinks und speichern Sie erneut — dies leert Rewrite-Regeln, die Authentifizierungsendpunkte beschädigen können. Wenn Sie WordPress auf einem VPS mit cPanel verwalten, stellen Sie sicher, dass mod_rewrite aktiviert ist und .htaccess beschreibbar ist.

cPanel und Web-Hosting-Kontrollpanels

Passwortgeschützte Verzeichnisse, die über cPanel konfiguriert wurden, verwenden Apaches mod_authn_file. Wenn der .htpasswd-Dateipfad in der generierten .htaccess absolut ist und sich das Dokumentenstammverzeichnis ändert (häufig nach Kontomigrationen), bricht der Pfad und jede Anfrage gibt 401 zurück. Verwenden Sie immer relative Pfade oder überprüfen Sie absolute Pfade nach jeder Migration. Umgebungen mit VPS-Kontrollpanels bieten direkten Dateisystemzugriff zur Korrektur dieser Pfade, ohne ein Support-Ticket zu öffnen.

E-Mail-Clients und SMTP-Authentifizierung

SMTP-Server geben ein protokollseitiges Äquivalent von 401 (535 Authentication credentials invalid) zurück, wenn die Anmeldedaten des E-Mail-Clients falsch sind oder wenn der Server STARTTLS erfordert und der Client eine einfache Authentifizierung versucht. Wenn Sie E-Mail-Hosting konfigurieren, stellen Sie sicher, dass Ihr Mail-Client mit der korrekten Authentifizierungsmethode (PLAIN, LOGIN oder CRAM-MD5) konfiguriert ist und dass TLS erzwungen wird, bevor Anmeldedaten übertragen werden.

Mobile Anwendungen

Mobile Apps begegnen häufig 401-Fehlern, nachdem ein Benutzer sein Passwort im Web geändert hat — das gespeicherte Refresh-Token der App wird serverseitig ungültig gemacht, aber die App hat keinen Mechanismus, dies zu erkennen, bis der nächste API-Aufruf fehlschlägt. Implementieren Sie einen globalen HTTP-Interceptor, der 401-Antworten abfängt, genau einmal eine Token-Aktualisierung versucht und, wenn die Aktualisierung ebenfalls 401 zurückgibt, den Benutzer mit einer klaren Meldung zum Anmeldebildschirm weiterleitet.

Entscheidungsmatrix: Ihren 401-Fehler diagnostizieren

Praktische Checkliste vor der Eskalation eines 401-Fehlers

Verwenden Sie diese Checkliste, bevor Sie ein Support-Ticket einreichen oder an Ihr Infrastrukturteam eskalieren:

• Die rohe HTTP-Antwort mit curl -v erfasst und den WWW-Authenticate-Header-Wert bestätigt
• Das JWT oder Token dekodiert und den exp-Claim gegen die aktuelle Serverzeit überprüft
• Bestätigt, dass das Authorization-Header-Format dem vom Server angekündigten Schema entspricht
• In einem Inkognito-Fenster mit allen deaktivierten Erweiterungen getestet
• Alle Cookies und den Cache für die betroffene Domain gelöscht
• Server-Fehler-Logs auf den spezifischen Ablehnungsgrund überprüft
• Bestätigt, dass die Reverse-Proxy-Konfiguration den Authorization-Header weiterleitet
• Bestätigt, dass das CDN die 401-Antwort nicht cached
• WAF-Regeln auf falsch-positive Übereinstimmungen mit dem Authorization-Header überprüft
• Bestätigt, dass SSL/TLS am Endpunkt aktiv ist — Anmeldedaten sollten niemals unverschlüsselt übertragen werden

FAQ

Was ist der Unterschied zwischen HTTP 401 und HTTP 403?

Ein 401 bedeutet, dass der Server nicht identifizieren kann, wer Sie sind — Authentifizierung fehlt oder ist ungültig. Ein 403 bedeutet, dass der Server weiß, wer Sie sind, aber entschieden hat, dass Sie keine Berechtigung haben, auf die Ressource zuzugreifen. Beheben Sie einen 401, indem Sie Anmeldedaten bereitstellen oder korrigieren; beheben Sie einen 403, indem Sie Zugriffssteuerungsregeln oder Berechtigungen anpassen.

Warum gibt meine API 401 zurück, obwohl ich das korrekte Token sende?

Die häufigsten Ursachen sind Token-Ablauf (überprüfen Sie den exp-Claim), Zeitabweichung zwischen Client und Server (NTP synchronisieren), ein rotiertes Signierungsgeheimnis, das vorhandene Token ungültig macht, oder der Authorization-Header wird von einem Reverse Proxy oder CDN entfernt, bevor er den Ursprungsserver erreicht.

Kann ein 401-Fehler durch eine Serverkonfiguration und nicht durch einen Client-Fehler verursacht werden?

Ja. Eine falsch konfigurierte .htaccess-Datei, ein NGINX-auth_basic-Block, der auf den falschen Standort angewendet wird, ein Reverse Proxy, der den Authorization-Header entfernt, oder eine WAF-Regel, die authentifizierte Anfragen blockiert, können alle 401-Antworten erzeugen, selbst wenn der Client vollkommen gültige Anmeldedaten sendet.

Wie verhindere ich 401-Fehler durch Token-Ablauf in einer Produktionsanwendung?

Implementieren Sie proaktive Token-Aktualisierung — überwachen Sie die verbleibende Lebensdauer des Tokens und aktualisieren Sie es vor dem Ablauf, nicht danach. Verwenden Sie für OAuth 2.0 den Refresh-Token-Endpunkt, um ein neues Zugriffstoken zu erhalten, wenn das aktuelle weniger als 20 % seiner TTL verbleibend hat. Fügen Sie einen globalen HTTP-Antwort-Interceptor hinzu, der 401-Antworten automatisch behandelt, indem er eine einzelne Token-Aktualisierung versucht, bevor er die ursprüngliche Anfrage erneut versucht.

Behebt das Löschen von Cookies immer einen 401-Fehler in einem Browser?

Nur wenn die Grundursache ein beschädigtes oder veraltetes Sitzungs-Cookie ist. Wenn der 401 durch eine serverseitige Fehlkonfiguration, einen abgelaufenen API-Schlüssel oder eine Firewall-Sperre verursacht wird, hat das Löschen von Cookies keine Wirkung. Verwenden Sie ein Inkognito-Fenster als Diagnoseschritt — wenn der 401 im Inkognito-Modus weiterhin besteht, liegt das Problem auf der Server- oder Netzwerkseite, nicht auf der Browser-Seite.