只配http-proxy连不上Packagist，因所有仓库全走HTTPS，必须同时配置http-proxy和https-proxy，且https-proxy值必须为http://开头；漏配或格式错误会导致静默直连、超时或502。
只配 http-proxy 肯定连不上 Packagist，必须同时配 http-proxy 和 https-proxy，且后者值必须是 http:// 开头。
为什么 composer config -g http-proxy 配了还是卡在 “Loading composer repositories”
因为 Packagist、GitHub 等所有仓库地址全是 HTTPS，而 Composer 对代理是严格分协议路由的：
-
http-proxy只用于 HTTP 请求（极少用到） -
https-proxy才用于 HTTPS 的 CONNECT 隧道（这才是关键） - 漏掉任一字段，Composer 就静默 fallback 到直连，结果就是超时、502 或卡住无报错
验证是否生效，别信命令返回成功，直接运行：
composer config -g --list | grep -E "(http|https)-proxy"
必须看到两行，且格式都正确，例如：
立即学习“PHP免费学习笔记（深入）”；
http-proxy http://127.0.0.1:8080<br>https-proxy http://127.0.0.1:8080
https-proxy 值填错的典型现象和修复
填成 https://127.0.0.1:8080、127.0.0.1:8080 或带未编码特殊字符的密码，都会导致静默失败。
- 正确写法永远是
http://协议开头，哪怕代理本身监听 TLS 端口 - 含
@、/、:的密码必须 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 代理（如 Windows 域环境）怎么办
Composer 原生不支持 NTLM 认证，设了 http-proxy 也会直接返回 407 Proxy Authentication Required 或连接失败。
- 不能靠改 Composer 配置解决，必须引入中转代理工具，如
cntlm或px - 让它们监听
127.0.0.1:3128并处理 NTLM，再让 Composer 连这个本地地址 - 临时验证是否是 NTLM 问题：执行
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，如果curl也报 407，说明中转层没配好 - 别指望系统
HTTP_PROXY环境变量——Composer 明确忽略它，只认自己的字段
代理配好了还是慢或失败，怎么快速定位
现象一致（卡住、超时、无报错），但原因可能在任意一层：
- 本地代理进程根本没启动
- 防火墙拦截了出站 CONNECT 请求
- 代理服务监听的是
127.0.0.1，但 Composer 实际走的是 IPv6 回环（::1），需确认代理是否监听双栈 - 镜像源本身不可达（比如配置了阿里云镜像但网络策略屏蔽了该域名）
最直接的验证方式是绕过 Composer，用 curl 模拟相同请求路径，看哪一步断开。真正的难点往往不在 Composer 配置本身，而在代理链路的协议兼容性和网络可达性上。
