Composer网络代理状态码异常捕获-composer-PHP中文网

composer不捕获407、502等http状态码，因其将网络失败统一处理为不可恢复错误并终止进程，导致try/catch无法介入；需绕过composer用curl手动验证代理链路及状态码。

composer网络代理状态码异常捕获

Composer 本身不提供 HTTP 状态码级别的异常捕获接口——你无法在 PHP 脚本里拿到 407 Proxy Authentication Required 或 502 Bad Gateway 这类响应码，因为 Composer 在底层用 cURL 发起请求时，只要连接失败或超时，就直接退出并返回非零状态码，不抛出可 catch 的 PHP 异常。

为什么 `try/catch` 捕不到 `407`、`502` 等代理相关错误

Composer 的网络层封装了 cURL，但做了高度抽象：它把所有网络失败（DNS 解析失败、连接被拒绝、TLS 握手失败、HTTP 状态码 ≥ 400）统一处理为“不可恢复错误”，然后终止进程。这意味着：

post-install-cmd 或自定义脚本里的 try/catch 完全不会执行，命令根本没走到那一步
composer install -vvv 日志里可能只显示 Failed to download ...，但看不到原始 HTTP 状态码
即使你用 proc_open() 调用 Composer，也拿不到 cURL 层的 CURLOPT_HEADERFUNCTION 回调，更无法拦截响应头

如何实际看到代理返回的 `407` 或 `502`

必须绕过 Composer，直接用 curl 模拟其请求路径，验证代理链路是否真正通达目标 URL：

先确认 Composer 当前使用的源：composer config -g repo.packagist，输出类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
手动发起等效请求：curl -I -x http://127.0.0.1:8080 https://mirrors.aliyun.com/composer/packages.json（-x 指定代理，协议必须是 http://）
观察响应第一行，比如 HTTP/1.1 407 Proxy Authentication Required 或 HTTP/1.1 502 Bad Gateway
若返回 curl: (7) Failed to connect，说明代理地址不可达；若返回 curl: (56) Received HTTP code 407，才是代理认证问题

`https-proxy` 配错导致状态码“消失”的典型表现

Composer 对 https-proxy 的值有硬性校验逻辑：如果填错，它会静默 fallback 到直连，此时你看到的错误其实是目标服务器的拒绝（如 Connection refused），而非代理的真实状态码。常见错误包括：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

https-proxy 值写成 https://127.0.0.1:8080（协议必须是 http://，哪怕代理监听 HTTPS 端口）
漏写协议头，如 127.0.0.1:8080 → Composer 忽略该配置，走直连
密码含 @ 或 / 未 URL 编码，导致解析 URL 失败，整个 proxy 配置失效
Windows 下 NTLM 代理未用 cntlm 中转，直接填域账号，结果始终卡在 Loading composer repositories，无任何状态码提示

在 CI/CD 中稳定捕获代理层错误的最小可行方案

不要依赖 Composer 自身日志。应在执行 composer install 前，插入一个 shell 校验步骤：

#!/bin/sh
PROXY_URL="http://127.0.0.1:8080"
MIRROR_URL="https://mirrors.aliyun.com/composer/packages.json"

if ! curl -s -o /dev/null -w "%{http_code}" -x "$PROXY_URL" "$MIRROR_URL" | grep -q "^200$"; then
  echo "Proxy check failed: $(curl -s -I -x "$PROXY_URL" "$MIRROR_URL" | head -1)"
  exit 1
fi

这个检查能提前暴露 407、502、000（连接失败）等真实状态码，并让 CI 流水线明确失败原因，而不是等 Composer 跑几分钟后报一个模糊的 Could not resolve host。

真正难调试的，永远不是状态码本身，而是 Composer 在代理失效时自动 fallback 的行为——它既不提示、也不记录，只默默换源重试，直到所有路径都失败才报错。所以验证代理，必须在 Composer 启动前做，且必须用和它完全一致的 URL 和代理配置。