因为packagist等仓库全量走https，而composer对http-proxy和https-proxy协议分离路由：仅配http-proxy时，https请求因缺少https-proxy建立connect隧道而直连超时；必须同时配置两个字段，且值均须为http://开头。
为什么只配 http-proxy 还是连不上 Packagist？
因为 Packagist、GitHub 等所有主流仓库全量走 HTTPS，而 Composer 对代理是协议分离路由的：http-proxy 只处理 HTTP 请求，https-proxy 才负责建立 CONNECT 隧道转发 HTTPS 流量。漏掉任意一个，HTTPS 请求就会 fallback 到直连——结果就是卡在 Loading composer repositories，无报错、无提示、只有超时。
必须同时配置两个字段，且值都得是 http:// 开头（哪怕代理本身监听 TLS 端口），这是 Composer 的硬性约定。
-
https-proxy填成https://127.0.0.1:8080或漏协议头（如127.0.0.1:8080）→ 静默失败，所有 HTTPS 请求直连 - 密码含
@、/、:必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword，可用php -r "echo rawurlencode('pa@ss/word');"快速生成 - Windows 下若报
Could not write to file，检查%APPDATA%\Composer\config.json目录是否存在且可写
composer config -g 代理命令必须加 -g 才生效
不加 -g（或 --global）的话，composer config http-proxy http://127.0.0.1:8080 实际写入的是当前项目根目录下的 composer.json 的 config 节点——换个项目、换个目录就失效。全局代理必须显式加 -g，写入用户级配置文件。
验证是否真生效：运行 composer config -g --list | grep -E "(http|https)-proxy"，应看到两行输出，且 URL 格式正确（http:// 开头，端口正确，认证信息已编码）。
公司用 NTLM 代理（如 Windows 域环境）怎么办？
Composer 原生不支持 NTLM 认证。设了 http-proxy 也会直接返回 407 Proxy Authentication Required 或 Unable to connect to http://repo.packagist.org。
不能靠改 Composer 配置解决，必须引入本地中转代理工具，例如 cntlm 或 px，让它们监听 127.0.0.1:3128 并处理 NTLM 认证，再让 Composer 连这个本地地址：
- Composer 配置指向本地中转：
composer config -g http-proxy http://127.0.0.1:3128和composer config -g https-proxy http://127.0.0.1:3128 - 临时验证中转是否正常：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，如果也报407，说明中转层没配好 - 别指望
HTTP_PROXY环境变量能绕过——Composer 明确忽略它，只认自己的http-proxy字段
代理配好了还是卡住？快速定位在哪一层断的
现象一致（卡住、超时、无报错），但原因可能在任意一层：本地代理进程未启动、防火墙拦截、代理本身不支持 CONNECT、证书校验失败……
分层验证最有效：
-
curl -x http://127.0.0.1:8080 -I https://packagist.org/packages.json→ 若失败，问题在代理层或网络层；若成功，问题大概率在 Composer 配置或版本兼容性 - 出现
file_get_contents(): SSL operation failed→ 代理未正确透传 TLS 流量，或本地 CA 证书不被信任；换用纯http://代理（非 HTTPS）可绕过此问题 - 出现
Connection refused或No route to host→ 代理进程没开、端口填错、防火墙拦截 -
composer create-project仍慢 → 它内部同样访问https://repo.packagist.org/packages.json，检查是否漏配https-proxy
真正容易被忽略的是：代理配置和镜像源配置是正交的两件事。即使你用了阿里云镜像，只要镜像站地址是 HTTPS（它一定是），https-proxy 就仍然必须存在且可用。
