Composer配代理报502不是自身问题,而是代理未正确转发HTTPS CONNECT请求或返回非法响应;https-proxy必须用http://开头,且须与http-proxy成对配置,并用curl -x复现验证各环节。

Composer配代理后报错,90% 不是 Composer 本身的问题,而是代理链某处没接住 HTTPS CONNECT 请求,或返回了非法响应——直接看报错里带 502 Bad Gateway、cURL error 7 或 Connection refused 的那一行,别急着改 composer.json。
为什么配了 https-proxy 还是 502?
因为 Composer 对 https-proxy 的协议头有硬性要求:它必须是 http:// 开头,哪怕你用的是 HTTPS 代理服务。Composer 只负责发起 CONNECT 隧道,不参与 TLS 握手。
- 错误写法:
composer config -g repo.packagist.org.ssl-proxy https://127.0.0.1:7890→ 必然触发 502 或静默失效 - 正确写法:
composer config -g repo.packagist.org.ssl-proxy http://127.0.0.1:7890 - 必须同时设置
http-proxy(即使只走 HTTPS):composer config -g http-proxy http://127.0.0.1:7890 - 验证代理是否真通:用
curl -x http://127.0.0.1:7890 -I https://packagist.org复现;如果也返回 502,说明代理自身异常,不是 Composer 的锅
代理连上了但卡住或 fallback 到直连?
常见于企业中间人代理(如 Zscaler、SonicWall)证书不受信任,cURL 拒绝继续握手,Composer 会静默 fallback 到直连——结果就是“没报错但一直卡在 Downloading”,或突然切回超时。
工作流任务拆解与模型编排技能。使用场景:(1) 收到复杂工作任务需要拆解为可执行步骤,(2) 需要为不同步骤选择最合适的模型,(3) 需要跟踪工作流进度和模型使用情况,(4) 长时间任务卡住需要问题诊断和解决方案。
- 临时调试可关掉证书校验:
composer config -g secure-http false和composer config -g cafile /dev/null(仅限本地验证,勿提交) - 更可靠的方式是导出代理的根证书,再让 Composer 显式信任:
composer config -g cafile /path/to/cert.pem - 注意:某些代理(如 Clash)默认不监听 HTTPS 端口,填了
https://地址却只开了 HTTP 监听,也会导致 CONNECT 失败
怎么确认 Composer 真的在走代理?
composer config -g repo.packagist.org.ssl-proxy 输出看起来正常,不代表生效——项目级 composer.json 中的 repositories 字段会完全屏蔽全局代理配置。
- 真实请求路径只能靠
composer install -vvv 2>&1 | grep Downloading看日志里实际发起的 URL - 如果看到
Downloading https://packagist.org/packages.json而不是镜像地址,说明代理没生效,优先检查是否项目里写了"type": "composer", "url": "https://packagist.org"这类硬编码 - 全局代理和镜像源不能混用:设了
repo.packagist.org.ssl-proxy就别再设repo.packagist,否则行为不可预测
公司网络下代理始终失败,还有没有备选方案?
有些内网策略会拦截 CONNECT 请求本身,或对 User-Agent 做识别过滤,此时换代理参数意义不大。
- 最稳的绕过方式是改 hosts:
137.74.169.73 packagist.org(IP 以实时查询为准),配合阿里云镜像源使用 - 或者彻底弃用 HTTPS 流量走代理:把所有包换成 zip 分发模式,对 GitHub 有效:
composer config -g github-protocols https - CI/CD 中务必固化环境变量:
COMPOSER_HTTP_PROXY=http://127.0.0.1:7890,比config -g更可靠,避免容器重启后丢失
代理问题最难缠的地方不是配置不对,而是错误被层层吞掉——502 看似服务端问题,实际可能卡在本地代理进程没启动;-vvv 日志里看不到 CONNECT 请求,往往意味着 https-proxy 协议头写错了,而不是代理地址本身有问题。

















