composer连不上packagist主因是仅配http-proxy而缺https-proxy，导致https请求静默直连卡死；必须同时配置格式合规的http://开头https-proxy，ntlm代理需用cntlm等中转，且每跳代理必须支持connect隧道。
Composer为什么连不上Packagist，明明配了http-proxy
因为Packagist全量走HTTPS，而http-proxy只管HTTP请求；HTTPS请求必须走https-proxy字段建立CONNECT隧道，缺一不可。漏掉https-proxy，Composer会静默fallback到直连——卡在Loading composer repositories，无报错、无超时提示，只干等。
https-proxy值必须是http://开头，哪怕代理本身是HTTPS端口
这是Composer硬性约定，不是协议逻辑问题。填https://127.0.0.1:8080或漏协议头（如127.0.0.1:8080）都会导致HTTPS请求完全失效，现象仍是“没反应”。正确写法永远是：
http://127.0.0.1:8080- 带认证时：
http://user:pass@127.0.0.1:8080（注意密码含@、/、:需URL编码，例如pa@ss/word→pa%40ss%2Fword）
验证命令：composer config -g --list | grep -E "(http|https)-proxy"，必须看到两行且格式合规。
公司用NTLM代理（比如Windows域环境）怎么办
Composer原生不支持NTLM，设了http-proxy也会直接返回407 Proxy Authentication Required或Unable to connect to http://repo.packagist.org。这不是配置问题，是协议不兼容。
- 必须引入中转代理工具：如
cntlm或px，让它们监听127.0.0.1:3128并处理NTLM认证 - 再把Composer的
http-proxy和https-proxy都指向http://127.0.0.1:3128 - 临时验证是否是NTLM问题：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，如果curl也报407，说明中转层没配通
别指望HTTP_PROXY环境变量能绕过——Composer明确忽略它，只认自己的http-proxy字段。
代理配好了还是慢或失败，怎么快速定位
现象一致（卡住、超时、无报错），但原因可能在任意一层：
- 本地代理进程根本没启动（比如
cntlm服务未运行） - 防火墙拦截了出向连接（尤其Windows Defender或企业EDR）
- 代理监听地址不是
127.0.0.1而是localhost，某些系统DNS解析localhost异常 -
composer install并发下载默认12路，若代理吞吐不足，会大量重试或排队，可临时降为composer config -g process-timeout 600+composer config -g use-include-path false减少干扰
最易被忽略的是：自定义网络代理链路里，每跳都必须支持CONNECT方法，且中间任何一环（比如二级代理）拒绝CONNECT，就会导致HTTPS隧道建立失败——此时curl -v -x能看到CONNECT packagist.org:443 HTTP/1.1后卡住或返回502，而非Composer自身报错。
