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 协议头写错了，而不是代理地址本身有问题。
