El error ERR_CONTENT_DECODING_FAILED (a veces mostrado como Error 330 en versiones anteriores de Chrome) aparece cuando Google Chrome no puede decodificar el contenido recibido de un servidor web. Esto generalmente significa que los encabezados de respuesta HTTP del servidor indican que el contenido está comprimido (usualmente con gzip), pero el cuerpo de la respuesta real no está comprimido, está comprimido de manera diferente o está corrupto. Este artículo explica las causas raíz, cómo diagnosticar el problema y cómo solucionarlo en diferentes plataformas de servidor web.

Comprendiendo el error

Cuando un navegador envía una solicitud a un servidor web, incluye un encabezado Accept-Encoding indicando qué métodos de compresión admite:

Accept-Encoding: gzip, deflate, br

Si el servidor decide comprimir la respuesta, incluye un encabezado Content-Encoding en la respuesta:

Content-Encoding: gzip

El navegador entonces espera descomprimir el cuerpo de la respuesta usando el algoritmo especificado. ERR_CONTENT_DECODING_FAILED ocurre cuando hay una discrepancia: el encabezado dice gzip pero el cuerpo no es datos gzip válidos.

Causas comunes

Doble compresión (la más común)

Esta es la causa más frecuente, especialmente con plataformas CMS como WordPress. Sucede cuando:

  1. Un plugin de caché u optimización de WordPress habilita la compresión gzip a nivel de aplicación
  2. El servidor web (IIS, Nginx, Apache) también está configurado para comprimir las respuestas
  3. El servidor comprime el contenido ya comprimido, produciendo datos gzip no válidos
  4. Chrome recibe los datos doblemente comprimidos y no puede decodificarlos

Interferencia de proxy o CDN

Un proxy inverso o CDN entre el cliente y el servidor de origen puede:

  • Eliminar el contenido comprimido pero dejar intacto el encabezado Content-Encoding: gzip
  • Recomprimir una respuesta ya comprimida
  • Almacenar en caché una respuesta comprimida y servirla con encabezados incorrectos

Respuesta corrupta

Problemas de red, respuestas truncadas o errores del lado del servidor pueden producir una respuesta donde el encabezado Content-Encoding está establecido pero el cuerpo está incompleto o corrupto.

Software antivirus o de seguridad

El software antivirus de escritorio que inspecciona el tráfico HTTPS puede a veces modificar los cuerpos de las respuestas sin actualizar los encabezados de codificación de contenido, causando que el navegador falle al decodificar.

Diagnosticando el problema

Usando las herramientas de desarrollo de Chrome

  1. Presione F12 para abrir las Herramientas de desarrollo de Chrome
  2. Vaya a la pestaña Red
  3. Recargue la página que produce el error
  4. Haga clic en la solicitud fallida
  5. Examine los Encabezados de respuesta:
    • Busque Content-Encoding: gzip
    • Verifique Transfer-Encoding
  6. Haga clic en la pestaña Respuesta — si la respuesta está ilegible o vacía, la codificación es incorrecta

Usando curl desde la línea de comandos

# 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

Verificando con un navegador diferente

Si la página carga en Firefox o Edge pero no en Chrome, el problema puede estar relacionado con la caché de Chrome o una extensión específica de Chrome. Si falla en todos los navegadores, el problema es del lado del servidor.

Solucionando el problema en IIS

Desactivar la doble compresión

Si un plugin de WordPress o la aplicación PHP maneja la compresión, desactive la compresión dinámica de IIS:

Usando el Administrador de IIS:

  1. Abra el Administrador de IIS
  2. Seleccione el sitio o nodo del servidor
  3. Haga doble clic en Compresión
  4. Desmarque Habilitar compresión de contenido dinámico
  5. Haga clic en Aplicar

Usando web.config:

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

O deje que IIS maneje toda la compresión

Alternativamente, desactive la compresión en la aplicación y deje que IIS la gestione:

  1. Desactive gzip en los plugins de WordPress (W3 Total Cache, WP Super Cache, etc.)
  2. Habilite tanto la compresión estática como dinámica en 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>

Solucionando el problema en Nginx

Verificar la configuración de gzip

Verifique su configuración de Nginx para los ajustes correctos de gzip:

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;
}

Evitar comprimir contenido ya comprimido

Si su aplicación (PHP, Node.js) envía respuestas pre-comprimidas, indique a Nginx que no las comprima nuevamente:

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

O use gzip_proxied para controlar cuándo Nginx comprime las respuestas del proxy:

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

Solucionando el problema en Apache

Verificar la configuración conflictiva de mod_deflate

# 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>

Si un plugin PHP también está comprimiendo la salida, desactive mod_deflate o desactive la compresión del plugin.

Soluciones específicas para WordPress

Dado que este error ocurre frecuentemente con instalaciones de WordPress, aquí hay soluciones específicas:

W3 Total Cache

  1. Vaya a Rendimiento > Caché del navegador
  2. En Compresión HTTP, desmarque Habilitar compresión HTTP (gzip)
  3. Guarde la configuración
  4. Deje que el servidor web maneje la compresión en su lugar

WP Super Cache

  1. Vaya a Ajustes > WP Super Cache > Avanzado
  2. Desmarque Comprimir páginas para que se sirvan más rápido a los visitantes
  3. Guarde la configuración

Ajuste en wp-config.php

Puede agregar esto a wp-config.php para evitar que WordPress envíe salida comprimida:

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

Solución de problemas del lado del cliente

Si está experimentando este error como usuario (no como administrador del servidor):

Borrar la caché del navegador

  1. Presione Ctrl+Shift+Delete en Chrome
  2. Seleccione Imágenes y archivos en caché
  3. Establezca el rango de tiempo en Todo el tiempo
  4. Haga clic en Borrar datos

Desactivar extensiones del navegador

Algunas extensiones (bloqueadores de anuncios, herramientas de privacidad) pueden interferir con el manejo de respuestas:

  1. Abra chrome://extensions/
  2. Desactive todas las extensiones
  3. Recargue la página que falla
  4. Si funciona, reactive las extensiones una por una para encontrar la culpable

Verificar el escaneo HTTPS del antivirus

Si su antivirus escanea el tráfico HTTPS, intente desactivar temporalmente esa función para ver si resuelve el error.

Vaciar la caché DNS

ipconfig /flushdns

En macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Resumen

El error ERR_CONTENT_DECODING_FAILED en Chrome es causado por una discrepancia entre el encabezado Content-Encoding y el cuerpo real de la respuesta. La causa más común es la doble compresión, donde tanto un plugin del CMS como el servidor web intentan comprimir la respuesta con gzip. La solución es sencilla: asegúrese de que solo una capa maneje la compresión. Use las Herramientas de desarrollo de Chrome y curl para diagnosticar qué capa está causando el conflicto, luego ajuste la configuración de IIS, Nginx o Apache según corresponda. Para WordPress específicamente, desactive la compresión en los plugins de caché y deje que el servidor web la maneje.