composer如何处理“Failed to decode response”错误？（网络中间件干扰排查）

“failed to decode response”错误源于网络中间件篡改响应体导致json解析失败，而非composer自身问题；常见原因包括代理、防火墙、抓包工具或安全软件注入html/重定向页，需通过curl验证响应内容并绕过中间件排查。

为什么 composer install 突然报 “Failed to decode response”？

这错误不是 Composer 自身解析失败，而是它收到的 http 响应体根本不是合法 json —— 通常因为网络中间件（比如公司代理、防火墙、CDN 或本地调试工具）偷偷改写了响应内容，比如注入 HTML 脚本、重定向跳转页、或返回了 502/504 的文本错误页。

典型现象：composer install 卡在 Downloading https://packagist.org/packages.json 后抛出该错误，但用 curl -I https://packagist.org/packages.json 看状态码却是 200；或者你手动 curl 下来的响应开头是 而非 <code>{。

• 检查是否启用了全局代理：运行 echo $HTTP_PROXY 和 echo $HTTPS_PROXY，非必要时清空它们（unset HTTP_PROXY HTTPS_PROXY）
• 确认没开着 Charles / fiddler / mitmproxy 等抓包工具 —— 它们常会替换证书并篡改响应体
• 如果公司网络强制走透明代理，尝试加 -vvv 参数运行 composer install，看实际请求发到了哪个 URL（可能被 302 到内部镜像，而该镜像返回了非 JSON 内容）

如何验证 Packagist 响应是否被污染？

绕过 Composer，直接用最简方式复现问题，定位污染源：

• 执行 curl -ssl -D - https://packagist.org/packages.json | head -n 20，观察响应头和前几行正文。正常应看到 HTTP/2 200 + Content-Type: application/json + 开头为 {
• 若看到 HTTP/1.1 302 Found 或响应体含 ，说明中间有重定向或注入行为
• 对比 curl --noproxy "*" -sSL https://packagist.org/packages.json | head -c 50，加 --noproxy "*" 可绕过系统代理，快速判断是否代理导致

临时绕过中间件的几种实操方式

不改网络环境也能让 Composer 继续工作，关键是让它拿到原始 JSON 响应：

• 强制使用 Packagist 官方镜像（跳过公司镜像）：composer config -g repo.packagist composer https://packagist.org
• 换用可信 DNS，避免 DNS 劫持影响域名解析（如设 1.1.1.1 或 8.8.8.8）
• 如果确定是 TLS 中间人（MITM）干扰，可临时禁用证书校验（仅限排查，勿长期使用）：export COMPOSER_DISABLE_TLS=1，再运行命令（注意：这会让流量降级为 HTTP，仅用于验证是否为证书层问题）
• 某些企业网络会拦截 packages.json 但放行 ZIP 包下载，可尝试 composer install --no-plugins --no-scripts 先拉依赖，再单独处理脚本

为什么改 cafile 或升级 OpenSSL 通常没用？

这个错误跟证书验证失败（如 cURL Error 60）是两回事。Failed to decode response 发生在响应已成功接收之后，Composer 尝试 json_decode() 时崩溃。所以：

• 修改 openssl.cafile 或更新 CA 证书，对这类问题完全无效
• 升级 Composer 版本也大概率无解 —— 它只是忠实解析服务端返回的内容
• 真正要盯的是“谁在响应到达 Composer 前动了手脚”，而不是 Composer 本身

最容易被忽略的一点：有些安全软件（尤其国内某卫士类）会在后台静默注入 JS 脚本到所有 HTTP/HTTPS 响应中，哪怕你没开浏览器 —— 这种情况只能关掉对应软件或换网络环境验证。