Composer代理配置必须同时设置http-proxy和https-proxy，且https-proxy值必须以http://开头；仅配http-proxy会导致HTTPS请求静默直连，卡在Loading composer repositories或报cURL error 28。
composer config -g https-proxy 必须填 http:// 开头
只配 http-proxy 一定失败，https-proxy 字段必须存在且值以 http:// 开头——哪怕你的代理服务监听的是 HTTPS 端口。Composer 对 HTTPS 请求强制走 CONNECT 隧道，而隧道发起协议由 https-proxy 的协议头决定，填 https://127.0.0.1:7890 或漏掉协议头（如 127.0.0.1:7890）都会静默失效。
常见写法：
-
http://127.0.0.1:7890（Clash/Proxyman 默认 HTTP 端口） -
http://user:pa%40ss%2Fword@127.0.0.1:8080（密码含@或/必须 URL 编码）
验证命令：composer config -g --list | grep -E "(http|https)-proxy"，输出必须包含两行，且格式合规。
必须同时设置 http-proxy 和 https-proxy
Composer 将 HTTP 和 HTTPS 请求完全分路由：http-proxy 只处理纯 HTTP 流量（极少），所有仓库（Packagist、GitHub、GitLab）全量走 HTTPS，因此 https-proxy 是实际生效的关键字段。漏掉它，等同于让全部元数据请求 fallback 到直连，现象是卡在 Loading composer repositories 或报 cURL error 28，无明确错误提示。
配置命令必须带 -g（全局）：
composer config -g http-proxy http://127.0.0.1:7890composer config -g https-proxy http://127.0.0.1:7890
不加 -g 会写入当前项目 composer.json，换目录即失效。
镜像和代理不能共存
国内用户最容易踩的坑：一边配了阿里云镜像，一边又设 http-proxy 和 https-proxy。二者作用机制冲突——镜像改的是请求地址（如把 repo.packagist.org 换成 mirrors.aliyun.com/composer），代理改的是流量路径。Composer 优先应用镜像配置，此时 http-proxy 和 https-proxy 字段被完全忽略。
排查方法：
- 先清空镜像：
composer config -g --unset repo.packagist - 再确认代理生效：
composer install -n -vvv日志里应出现Proxy CONNECT字样 - 若日志无此字样，说明代理根本没启动，不是慢，是没走
NTLM 代理或公司域环境怎么办
Composer 原生不支持 NTLM 认证，直接填 http-proxy 会返回 407 Proxy Authentication Required。这不是配置错，是协议不兼容。
必须引入中转代理工具：
- Windows 推荐
cntlm或px，监听127.0.0.1:3128并处理 NTLM - 然后统一指向它：
composer config -g http-proxy http://127.0.0.1:3128和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 明确忽略它，只认自己的字段。
