Composer拉取Packagist失败主因是代理配置缺项或错误：必须同时配置http-proxy和https-proxy，且https-proxy值必须以http://开头（如http://127.0.0.1:8080），否则HTTPS请求静默直连导致卡在“Loading composer repositories”、超时或502。
Composer拉取Packagist失败，90%不是网络卡，而是代理配置缺项、协议写错或镜像未生效——先查https-proxy有没有配，再确认它是不是http://开头。
为什么只配http-proxy一定失败
Packagist 全量走 HTTPS，而 Composer 把 HTTP 和 HTTPS 的代理路由完全分开：http-proxy只管 HTTP 请求，https-proxy才负责建立 CONNECT 隧道。漏掉后者，Composer 就会把 HTTPS 请求直连出去，结果是卡住、超时，或被中间网关拦截后返回 502。
-
https-proxy的值必须是http://127.0.0.1:8080这类格式，哪怕你的代理监听的是 TLS 端口，也绝不能写成https:// - 命令必须加
-g（全局），否则只写进当前项目composer.json，换目录就失效 - 验证是否生效：运行
composer config -g --list | grep -E "(http|https)-proxy"，两行都得有且 URL 格式正确
https-proxy填错的典型现象和修复
填成https://127.0.0.1:8080或漏协议头（如127.0.0.1:8080），会导致静默 fallback 到直连——没报错，但所有 HTTPS 请求都失败。
- 正确写法永远是
http://127.0.0.1:8080，带认证则为http://user:pass@127.0.0.1:8080 - 密码含
@、/、:必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword，可用php -r "echo rawurlencode('pa@ss/word');"快速生成 - Windows 下若报
Could not write to file，检查%APPDATA%\Composer\config.json是否存在且可写
公司 NTLM 代理怎么办
Composer 原生不支持 NTLM 认证，设了http-proxy也会直接返回407 Proxy Authentication Required或Unable to connect。
- 必须引入中转代理工具，如
cntlm或px，让它们监听127.0.0.1:3128并处理 NTLM - 再让 Composer 连这个本地地址：
composer config -g http-proxy http://127.0.0.1:3128和composer config -g 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，说明中转层没配好
代理配对后仍失败？立刻验证链路
现象一致（卡住、502、无报错），但原因可能在任意一层：本地代理进程未启动、防火墙拦截、或代理自身异常。
- 用
curl -x复现请求：curl -x http://127.0.0.1:8080 -v https://packagist.org/packages.json，看是否真能通 - 如果 curl 返回 502，说明代理服务本身出问题；如果卡住，可能是 TLS 握手失败或认证未通过
- 别指望系统
HTTP_PROXY环境变量——Composer 明确忽略它，只认自己的http-proxy字段
真正容易被忽略的是：即使代理配置全对，如果镜像源没同步、repositories字段在项目级覆盖了全局设置、或缓存里存着损坏的元数据，依然会失败。排查时得一层层切，而不是只盯着代理。
