必须同时配置http-proxy和https-proxy且后者协议头为http://，否则HTTPS请求静默直连导致“Loading composer repositories”卡住；NTLM环境需用cntlm等中转代理，且所有配置须加-g全局生效。
只配 http-proxy 一定失败，必须同时设置 http-proxy 和 https-proxy，且后者值必须以 http:// 开头——这是 Composer 的硬性路由规则，不是可选项。
为什么 composer install 卡在 “Loading composer repositories”
因为 Packagist、GitHub 等所有仓库全量走 HTTPS，而 Composer 对 HTTP 和 HTTPS 请求走完全不同的代理路径：http-proxy 只处理纯 HTTP 请求，https-proxy 才触发 CONNECT 隧道。漏掉后者，HTTPS 请求会静默 fallback 到直连，结果就是卡住、超时、无明确错误。
常见现象包括：
-
Loading composer repositories长时间无响应，最终报cURL error 28 -
composer config -g --list只显示http-proxy，没看到https-proxy - 填了
https://127.0.0.1:8080或127.0.0.1:8080—— 这两种写法都非法，会静默失效
https-proxy 的正确写法和验证方式
无论你的代理服务监听的是 HTTP 还是 HTTPS 端口，https-proxy 的协议头必须是 http://。例如：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 本地 Clash/Proxyman：
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"，确认两行都存在且格式合规 - 临时绕过代理测试：
HTTP_PROXY= HTTPS_PROXY= composer install，若此时成功，基本锁定是代理配置问题
NTLM 代理（如公司 Windows 域环境）怎么办
Composer 原生不支持 NTLM 认证，设了 http-proxy 也会直接返回 407 Proxy Authentication Required。不能靠改 Composer 配置解决，必须引入中转代理工具：
- Windows 推荐
cntlm或px，让它们监听127.0.0.1:3128并处理 NTLM，再把 Composer 的http-proxy和https-proxy都指向http://127.0.0.1:3128 - 验证中转层是否生效：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，如果也报407，说明中转没配好
代理配好了还是超时或报 502？别只盯着 proxy 字段
代理只是链路一环，超时还可能卡在其他环节：
-
http.timeout默认仅 300 秒（5 分钟），弱网下极易触发；需同步运行composer config -g http.timeout 600 - PHP 的
default_socket_timeout若低于你设的http.timeout（常见值是 60），会提前掐断连接；查它：php -i | grep default_socket_timeout - 镜像和代理不能共存：混配会导致
http-proxy和https-proxy被完全忽略；先清空镜像：composer config -g --unset repo.packagist
最易被忽略的一点：所有配置必须加 -g（全局），否则只写入当前项目 composer.json，换目录就失效；另外，Composer 明确忽略系统 HTTP_PROXY 环境变量，只认自己的字段。
