只配http-proxy一定失败，必须同时设https-proxy；Composer对HTTP和HTTPS请求走独立代理路由，所有仓库全量HTTPS，漏设https-proxy会导致元数据请求静默直连，表现为卡在Loading composer repositories或cURL error 28。
只配http-proxy一定失败，必须同时设https-proxy
Composer 对 HTTP 和 HTTPS 请求走两套完全独立的代理路由：前者用 http-proxy，后者必须靠 https-proxy 字段发起 CONNECT 隧道。而 Packagist、GitHub、GitLab 所有仓库全量走 HTTPS，漏掉 https-proxy 就等于让全部元数据请求静默直连——结果就是卡在 Loading composer repositories，或最终报 cURL error 28，却无明确错误提示。
常见错误写法包括：
-
https-proxy值填成https://127.0.0.1:7890或127.0.0.1:7890（漏协议头）→ 静默失效 - 只运行
composer config -g http-proxy http://127.0.0.1:7890，没设https-proxy→ 代理对 HTTPS 完全不生效
https-proxy 的值必须是 http:// 开头
无论你的本地代理（Clash、Proxyman、Fiddler）监听的是 HTTP 还是 HTTPS 端口，https-proxy 字段的协议头只能是 http://。这是 Composer 的硬性约定，不是可选项。
正确写法示例：
- 无认证：
http://127.0.0.1:7890 - 带认证：
http://user:pa%40ss%2Fword@127.0.0.1:8080（密码含@或/必须 URL 编码） - 验证是否生效：
composer config -g --list | grep -E "(http|https)-proxy"，应看到两行且格式合规
NTLM 代理（如公司 Windows 域环境）必须加中转层
Composer 原生不支持 NTLM 认证。直接配置 http-proxy 或 https-proxy 会返回 407 Proxy Authentication Required 或 Unable to connect to http://repo.packagist.org。
解决路径唯一：引入中转代理工具处理 NTLM，再让 Composer 连这个中转地址：
- Windows 推荐
cntlm或px，配置它们监听127.0.0.1:3128 - 然后统一设：
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，说明中转未配好
镜像和代理不能共存，优先清空镜像
镜像（repo.packagist）和代理作用层面不同，且互斥。同时配置会导致 Composer 完全忽略 http-proxy 和 https-proxy 字段——因为镜像配置优先级更高。
国内用户卡在 Loading composer repositories，90% 是混配了二者。排查步骤：
- 先清空镜像：
composer config -g --unset repo.packagist - 再确认代理已全局配置：
composer config -g --list | grep -E "(http|https)-proxy" - 最后加
-n -vvv跑一次：composer install -n -vvv，日志里出现Proxy CONNECT才算真正生效
代理字段必须加 -g（global），否则只写入当前项目 composer.json，换目录就失效；另外，http.timeout 和 PHP 的 default_socket_timeout 也要同步调大，否则代理通了也会因底层超时被掐断。
