Was verursacht ERR_CONTENT_DECODING_FAILED in Chrome?

Dieser Fehler tritt auf, wenn die HTTP-Antwort-Header angeben, dass der Inhalt gzip-kodiert ist (Content-Encoding: gzip), der tatsächliche Antwortkörper jedoch keine gültigen gzip-Daten enthält. Häufige Ursachen sind ein Webanwendungs-Plugin, das Inhalte komprimiert, während der Webserver ebenfalls gzip-Komprimierung anwendet (doppelte Kodierung), falsch konfigurierte Reverse-Proxys, die die Komprimierung entfernen, aber die Header nicht aktualisieren, oder beschädigte zwischengespeicherte Antworten.

Wie behebe ich ERR_CONTENT_DECODING_FAILED auf IIS?

Überprüfen Sie im IIS-Manager Ihre Komprimierungseinstellungen in der Funktionsansicht auf Serverebene. Wenn ein WordPress-Plugin oder die Anwendung die Komprimierung verwaltet, deaktivieren Sie die dynamische IIS-Komprimierung, um doppelte Kodierung zu vermeiden. Alternativ deaktivieren Sie die Komprimierung in der Anwendung und lassen IIS sie verwalten. Sie können auch die web.config auf widersprüchliche httpCompression-Einstellungen überprüfen.

Behebt das Leeren des Browser-Caches ERR_CONTENT_DECODING_FAILED?

Das Leeren des Caches behebt den Fehler nur, wenn das Problem eine beschädigte zwischengespeicherte Antwort war. Wenn der Server aktiv falsch konfiguriert ist, wird der Fehler bei der nächsten Anfrage erneut auftreten. Leeren Sie den Cache, um Beschädigung auszuschließen (Strg+Umschalt+Entf in Chrome), und prüfen Sie dann, ob der Fehler weiterhin besteht. Wenn ja, muss die Server- oder Proxy-Konfiguration korrigiert werden.

Was bedeutet Fehler 330 (net::ERR_CONTENT_DECODING_FAILED) in Google Chrome

Der Fehler ERR_CONTENT_DECODING_FAILED (manchmal als Fehler 330 in älteren Chrome-Versionen angezeigt) erscheint, wenn Google Chrome den vom Webserver empfangenen Inhalt nicht dekodieren kann. Dies bedeutet typischerweise, dass die HTTP-Antwort-Header des Servers angeben, dass der Inhalt komprimiert ist (normalerweise mit gzip), der tatsächliche Antwortkörper jedoch entweder nicht komprimiert, anders komprimiert oder beschädigt ist. Dieser Artikel erklärt die Grundursachen, wie das Problem diagnostiziert wird und wie es auf verschiedenen Webserver-Plattformen behoben werden kann.

Den Fehler verstehen

Wenn ein Browser eine Anfrage an einen Webserver sendet, enthält er einen Accept-Encoding-Header, der angibt, welche Komprimierungsmethoden er unterstützt:

Accept-Encoding: gzip, deflate, br

Wenn der Server beschließt, die Antwort zu komprimieren, fügt er einen Content-Encoding-Header in die Antwort ein:

Content-Encoding: gzip

Der Browser erwartet dann, den Antwortkörper mit dem angegebenen Algorithmus zu dekomprimieren. ERR_CONTENT_DECODING_FAILED tritt auf, wenn eine Diskrepanz besteht — der Header sagt gzip, aber der Körper enthält keine gültigen gzip-Daten.

Häufige Ursachen

Doppelte Komprimierung (am häufigsten)

Dies ist die häufigste Ursache, besonders bei CMS-Plattformen wie WordPress. Es passiert, wenn:

Ein WordPress-Caching- oder Optimierungs-Plugin die gzip-Komprimierung auf Anwendungsebene aktiviert
Der Webserver (IIS, Nginx, Apache) ebenfalls für die Komprimierung von Antworten konfiguriert ist
Der Server den bereits komprimierten Inhalt erneut komprimiert und ungültige gzip-Daten erzeugt
Chrome die doppelt komprimierten Daten empfängt und sie nicht dekodieren kann

Proxy- oder CDN-Interferenz

Ein Reverse-Proxy oder CDN zwischen Client und Ursprungsserver kann:

Den komprimierten Inhalt entfernen, aber den Content-Encoding: gzip-Header beibehalten
Eine bereits komprimierte Antwort erneut komprimieren
Eine komprimierte Antwort zwischenspeichern und mit falschen Headern ausliefern

Beschädigte Antwort

Netzwerkprobleme, abgeschnittene Antworten oder serverseitige Fehler können eine Antwort erzeugen, bei der der Content-Encoding-Header gesetzt ist, der Körper aber unvollständig oder beschädigt ist.

Antivirus- oder Sicherheitssoftware

Desktop-Antivirensoftware, die HTTPS-Datenverkehr überprüft, kann manchmal Antwortkörper modifizieren, ohne die Content-Encoding-Header zu aktualisieren, was dazu führt, dass der Browser beim Dekodieren scheitert.

Das Problem diagnostizieren

Chrome-Entwicklertools verwenden

Drücken Sie F12, um die Chrome-Entwicklertools zu öffnen
Gehen Sie zum Tab Netzwerk
Laden Sie die Seite neu, die den Fehler verursacht
Klicken Sie auf die fehlgeschlagene Anfrage
Untersuchen Sie die Antwort-Header:
- Suchen Sie nach Content-Encoding: gzip
- Überprüfen Sie Transfer-Encoding
Klicken Sie auf den Tab Antwort — wenn die Antwort unleserlich oder leer ist, stimmt die Kodierung nicht

curl von der Kommandozeile verwenden

# Request with gzip encoding and see response headers
curl -H "Accept-Encoding: gzip" -I https://example.com

# Download the response and check if it is valid gzip
curl -H "Accept-Encoding: gzip" -o response.gz https://example.com
file response.gz    # Should report "gzip compressed data"
gunzip response.gz  # Should decompress without errors

# Request without compression to see if the page works
curl --compressed -v https://example.com

Mit einem anderen Browser überprüfen

Wenn die Seite in Firefox oder Edge geladen wird, aber nicht in Chrome, kann das Problem mit dem Chrome-Cache oder einer Chrome-spezifischen Erweiterung zusammenhängen. Wenn es in allen Browsern fehlschlägt, liegt das Problem auf der Serverseite.

Das Problem auf IIS beheben

Doppelte Komprimierung deaktivieren

Wenn ein WordPress-Plugin oder die PHP-Anwendung die Komprimierung verwaltet, deaktivieren Sie die dynamische IIS-Komprimierung:

Über den IIS-Manager:

Öffnen Sie den IIS-Manager
Wählen Sie die Site oder den Serverknoten
Doppelklicken Sie auf Komprimierung
Deaktivieren Sie Dynamische Inhaltskomprimierung aktivieren
Klicken Sie auf Übernehmen

Über web.config:

<configuration>
  <system.webServer>
    <urlCompression doStaticCompression="true"
                    doDynamicCompression="false" />
  </system.webServer>
</configuration>

Oder lassen Sie IIS die gesamte Komprimierung verwalten

Alternativ deaktivieren Sie die Komprimierung in der Anwendung und lassen IIS sie verwalten:

Deaktivieren Sie gzip in WordPress-Plugins (W3 Total Cache, WP Super Cache usw.)
Aktivieren Sie sowohl statische als auch dynamische Komprimierung in IIS:

<configuration>
  <system.webServer>
    <urlCompression doStaticCompression="true"
                    doDynamicCompression="true" />
    <httpCompression>
      <dynamicTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="application/javascript" enabled="true" />
        <add mimeType="application/json" enabled="true" />
        <add mimeType="*/*" enabled="false" />
      </dynamicTypes>
      <staticTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="application/javascript" enabled="true" />
        <add mimeType="*/*" enabled="false" />
      </staticTypes>
    </httpCompression>
  </system.webServer>
</configuration>

Das Problem auf Nginx beheben

gzip-Konfiguration überprüfen

Überprüfen Sie Ihre Nginx-Konfiguration auf korrekte gzip-Einstellungen:

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_min_length 1000;

    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/json
        application/javascript
        application/xml
        application/xml+rss
        application/x-javascript
        image/svg+xml;
}

Vermeiden Sie die Komprimierung bereits komprimierter Inhalte

Wenn Ihre Anwendung (PHP, Node.js) vorkomprimierte Antworten sendet, weisen Sie Nginx an, diese nicht erneut zu komprimieren:

location ~ \.php$ {
    # Pass through without additional compression
    gzip off;
    proxy_pass http://backend;
}

Oder verwenden Sie gzip_proxied, um zu steuern, wann Nginx Proxy-Antworten komprimiert:

# Only compress if the backend did not already compress
gzip_proxied no-cache no-store private expired auth;

Das Problem auf Apache beheben

Konfligierende mod_deflate-Konfiguration überprüfen

# In .htaccess or httpd.conf
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml
    AddOutputFilterByType DEFLATE text/css text/javascript
    AddOutputFilterByType DEFLATE application/json application/javascript
    AddOutputFilterByType DEFLATE application/xml application/xhtml+xml

    # Do not compress images or already-compressed files
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|gz|zip|bz2)$ no-gzip
</IfModule>

Wenn ein PHP-Plugin ebenfalls die Ausgabe komprimiert, deaktivieren Sie entweder mod_deflate oder die Komprimierung des Plugins.

WordPress-spezifische Lösungen

Da dieser Fehler häufig bei WordPress-Installationen auftritt, hier gezielte Korrekturen:

W3 Total Cache

Gehen Sie zu Leistung > Browser-Cache
Unter HTTP-Komprimierung deaktivieren Sie HTTP (gzip) Komprimierung aktivieren
Speichern Sie die Einstellungen
Lassen Sie stattdessen den Webserver die Komprimierung verwalten

WP Super Cache

Gehen Sie zu Einstellungen > WP Super Cache > Erweitert
Deaktivieren Sie Seiten komprimieren, damit sie schneller an Besucher ausgeliefert werden
Speichern Sie die Einstellungen

wp-config.php-Anpassung

Sie können dies zur wp-config.php hinzufügen, um zu verhindern, dass WordPress komprimierte Ausgabe sendet:

// Disable WordPress gzip output
@ini_set('zlib.output_compression', 'Off');

Clientseitige Fehlerbehebung

Wenn Sie diesen Fehler als Benutzer erleben (nicht als Serveradministrator):

Browser-Cache leeren

Drücken Sie Strg+Umschalt+Entf in Chrome
Wählen Sie Bilder und Dateien im Cache
Setzen Sie den Zeitraum auf Gesamte Zeit
Klicken Sie auf Daten löschen

Browser-Erweiterungen deaktivieren

Einige Erweiterungen (Werbeblocker, Datenschutz-Tools) können die Antwortverarbeitung stören:

Öffnen Sie chrome://extensions/
Deaktivieren Sie alle Erweiterungen
Laden Sie die fehlgeschlagene Seite neu
Wenn es funktioniert, aktivieren Sie die Erweiterungen einzeln wieder, um den Verursacher zu finden

HTTPS-Überprüfung des Antivirenprogramms prüfen

Wenn Ihr Antivirenprogramm HTTPS-Datenverkehr überprüft, versuchen Sie, diese Funktion vorübergehend zu deaktivieren, um zu sehen, ob der Fehler behoben wird.

DNS-Cache leeren

ipconfig /flushdns

Auf macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Zusammenfassung

Der Fehler ERR_CONTENT_DECODING_FAILED in Chrome wird durch eine Diskrepanz zwischen dem Content-Encoding-Header und dem tatsächlichen Antwortkörper verursacht. Die häufigste Ursache ist doppelte Komprimierung, bei der sowohl ein CMS-Plugin als auch der Webserver versuchen, die Antwort mit gzip zu komprimieren. Die Lösung ist einfach: Stellen Sie sicher, dass nur eine Schicht die Komprimierung übernimmt. Verwenden Sie die Chrome-Entwicklertools und curl, um zu diagnostizieren, welche Schicht den Konflikt verursacht, und passen Sie dann Ihre IIS-, Nginx- oder Apache-Konfiguration entsprechend an. Speziell für WordPress deaktivieren Sie die Komprimierung in Caching-Plugins und lassen den Webserver sie verwalten.