Composer的https-proxy必须以http://开头，即使代理监听HTTPS端口；填https://或漏协议头会静默失效，导致HTTPS请求直连而卡在Loading composer repositories或报cURL error 28。
Composer的https-proxy必须写成http://开头
你本地代理服务哪怕监听的是443或8443这类HTTPS端口，https-proxy配置值也必须以http://开头。填https://127.0.0.1:7890或漏掉协议头，Composer会静默忽略该字段，导致所有HTTPS请求（包括访问https://packagist.org/packages.json） fallback 到直连——结果就是卡在Loading composer repositories，或报cURL error 28。
正确写法示例：
-
http://127.0.0.1:7890（Clash、Proxyman 等常见代理） -
http://user:pa%40ss%2Fword@127.0.0.1:8080（密码含@或/必须URL编码）
验证是否生效：运行composer config -g --list | grep -E "(http|https)-proxy"，输出里必须同时存在两行，且格式合规。
为什么只配http-proxy仍然卡住
因为Packagist、GitHub、GitLab等所有官方及主流仓库全量走HTTPS，而Composer对HTTP和HTTPS请求走完全分离的代理路径：
-
http-proxy只用于纯HTTP请求（极少） -
https-proxy才用于发起CONNECT隧道，承载全部HTTPS流量
漏掉https-proxy，等于让99%的元数据请求绕过代理直连——在企业防火墙、出口NAT或WAF拦截下，必然失败，且无明确错误提示。这不是“慢”，是根本没走通。
502 Bad Gateway说明代理链本身异常
如果composer install报502，基本可判定不是Composer问题，而是代理服务在建立CONNECT隧道后，向上游转发失败或返回了非法响应：
- 代理监听HTTP端口，但配置误用了
https://前缀 - 代理启用了TLS终止，但证书不受信任，cURL拒绝继续（此时可能降级直连，反而不报502）
- 企业网关（如WAF）拦截了代理发出的请求，并伪造了502页面
快速验证方式：curl -x http://127.0.0.1:7890 -I https://packagist.org/packages.json。如果同样返回502，问题就在代理层；如果成功，再查Composer配置是否被项目级repositories覆盖或缓存未清。
NTLM代理环境下必须加中转层
Windows域环境常见的NTLM认证，Composer原生完全不支持。即使填了http-proxy，也会直接返回407 Proxy Authentication Required。
必须引入中转代理工具：
- Windows推荐
cntlm或px，让它们监听127.0.0.1:3128并处理NTLM - 再把Composer的
http-proxy和https-proxy都设为http://127.0.0.1:3128
验证中转是否起效：curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json。若仍报407，说明中转工具本身未正确配置域凭据。
最容易被忽略的是：镜像源和代理不能共存。一旦设置了repo.packagist，http-proxy和https-proxy会被完全忽略。想用代理，务必先执行composer config -g --unset repo.packagist并composer clear-cache。
