ERR_CONTENT_DECODING_FAILED 错误源于响应头声明gzip但实际内容非有效gzip数据，需依次排查服务器压缩配置、PHP输出设置、框架Gzip开关、静态资源压缩流程及Netty等自定义服务压缩处理器误用。
当浏览器控制台显示 ERR_CONTENT_DECODING_FAILED 错误时，通常表明 HTTP 响应头中声明了 Content-Encoding: gzip，但实际响应体内容并非有效的 gzip 编码数据。以下是针对该问题的多种排查与修复方法：
一、检查并关闭服务器端 gzip 压缩配置
该方法适用于 Nginx、Apache 或其他反向代理/Web 服务器未正确处理压缩逻辑的情形。若 gzip 配置开启但后端未真实压缩，或压缩中途被截断、污染，浏览器将因解码失败而报错。
1、打开 Nginx 配置文件 nginx.conf，查找 gzip 相关指令。
2、将 gzip on; 修改为 gzip off;。
3、执行 nginx -t 验证语法，再运行 nginx -s reload 重载配置。
4、若使用 Apache，检查 .htaccess 或 httpd.conf 中是否启用 mod_deflate，并临时注释 SetOutputFilter DEFLATE 等相关行。
二、调整 PHP 输出压缩设置
PHP 层可能通过 zlib.output_compression 或 ob_gzhandler 启用压缩，但若页面存在 BOM 头、提前输出（如空格、echo）、或输出缓冲未对齐，会导致 gzip 流损坏。
1、编辑 php.ini，定位 zlib.output_compression 行，将其设为 On。
2、若已为 On 但仍报错，尝试改为 Off 并重启 php-fpm。
3、检查入口文件（如 index.php）顶部是否存在 UTF-8 BOM 字节，使用十六进制编辑器确认并清除。
4、确保所有 PHP 文件以无 BOM 的 UTF-8 格式保存，且在调用 ob_start('ob_gzhandler') 前无任何输出（包括空白行、空格、错误提示）。
三、禁用框架内置 Gzip 功能
常见 CMS 或框架（如 PHPCMS、Discuz、ThinkPHP）自带 Gzip 开关，其逻辑常与底层压缩模块冲突，导致响应头与响应体不一致。
1、PHPCMS：编辑 caches/configs/system.php，将 'gzip' => 1 改为'gzip' => 0。
2、Discuz：修改 forumdata/cache/cache_settings.php，将 'gzipcompress' => 1 改为'gzipcompress' => 0。
3、ThinkPHP：关闭调试模式（APP_DEBUG = false），或检查 config/app.php 中是否启用了 output_compress，设为 false。
四、验证静态资源压缩流程完整性
若服务端手动对文件进行 gzencode 后写入磁盘再读取返回，必须确保整个链路保持二进制一致性——即生成、存储、传输均不改变原始压缩字节流，否则浏览器收到的将不是合法 gzip 数据。
1、确认生成压缩文件时使用的是 gzencode($data, 9)，而非 base64_encode 或其他编码封装。
2、检查文件读取方式是否为二进制模式：使用 file_get_contents() 而非 fopen + fgets 混合读取。
3、返回响应前，必须显式设置 Header：Content-Encoding: gzip，并确保响应体为原始 gzencode 输出字节，禁止对该字节流再次进行 UTF-8 解码、trim()、或字符串拼接。
五、排查 Netty 等自定义 HTTP 服务中的压缩处理器误用
在基于 Netty 构建的 HTTP 服务中，HttpContentCompressor 仅对继承 HttpObject 的消息类型生效；若文件下载使用 DefaultFileRegion 等非 HttpObject 类型，则响应头被标记为 gzip，但响应体未压缩，造成解码失败。
1、检查 ChannelPipeline 中是否添加了 HttpContentCompressor。
2、若需支持文件下载，应移除 HttpContentCompressor，改用响应头手动控制压缩（如仅对 text/html 应用）。
3、或改用 HttpChunkedInput 封装文件流，使其通过 HttpContentCompressor 编码路径。
4、验证响应头中 Content-Encoding 字段是否与实际响应体编码方式严格匹配，二者必须完全一致，不可存在条件分支错配。