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:
- Un plugin de caché u optimización de WordPress habilita la compresión gzip a nivel de aplicación
- El servidor web (IIS, Nginx, Apache) también está configurado para comprimir las respuestas
- El servidor comprime el contenido ya comprimido, produciendo datos gzip no válidos
- 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
- Presione
F12para abrir las Herramientas de desarrollo de Chrome - Vaya a la pestaña Red
- Recargue la página que produce el error
- Haga clic en la solicitud fallida
- Examine los Encabezados de respuesta:
- Busque
Content-Encoding: gzip - Verifique
Transfer-Encoding
- Busque
- 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:
- Abra el Administrador de IIS
- Seleccione el sitio o nodo del servidor
- Haga doble clic en Compresión
- Desmarque Habilitar compresión de contenido dinámico
- 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:
- Desactive gzip en los plugins de WordPress (W3 Total Cache, WP Super Cache, etc.)
- 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
- Vaya a Rendimiento > Caché del navegador
- En Compresión HTTP, desmarque Habilitar compresión HTTP (gzip)
- Guarde la configuración
- Deje que el servidor web maneje la compresión en su lugar
WP Super Cache
- Vaya a Ajustes > WP Super Cache > Avanzado
- Desmarque Comprimir páginas para que se sirvan más rápido a los visitantes
- 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
- Presione
Ctrl+Shift+Deleteen Chrome - Seleccione Imágenes y archivos en caché
- Establezca el rango de tiempo en Todo el tiempo
- Haga clic en Borrar datos
Desactivar extensiones del navegador
Algunas extensiones (bloqueadores de anuncios, herramientas de privacidad) pueden interferir con el manejo de respuestas:
- Abra
chrome://extensions/ - Desactive todas las extensiones
- Recargue la página que falla
- 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.