必须同时配置http-proxy和https-proxy，且https-proxy值必须以http://开头；仅配http-proxy会导致HTTPS请求静默直连而超时或卡在Loading composer repositories。
代理配了还是超时，大概率是只设了 http-proxy 没设 https-proxy，或者 https-proxy 的值协议头写错了——Composer 对 HTTPS 请求完全不走 http-proxy 字段，漏掉它就等于让所有包下载静默直连。
为什么只配 http-proxy 一定失败
Composer 把 HTTP 和 HTTPS 请求分路由处理：http-proxy 只管纯 HTTP 请求（极少），所有仓库（Packagist、GitHub、GitLab）全走 HTTPS，必须由 https-proxy 字段接管。漏掉它，就会卡在 Loading composer repositories 或反复报 cURL error 28，但命令行不提示具体原因。
-
https-proxy的值协议头必须是http://，哪怕你的代理服务监听的是 HTTPS 端口——例如http://127.0.0.1:7890才合法，https://127.0.0.1:7890或127.0.0.1:7890都会静默失效 - 含特殊字符的密码（如
@、/）必须 URL 编码，比如pa@ss/word要写成pa%40ss%2Fword - 验证是否生效：运行
composer config -g --list | grep -E "(http|https)-proxy"，必须看到两行且格式合规
代理配对后仍超时，该调哪几个 timeout
代理只是链路一环，超时还可能卡在其他环节。关键要区分清楚：
-
http.timeout：控制每次 HTTP 请求（含 DNS、TLS 握手、首字节等待）总时长，默认仅 60 秒。弱网下极易触发，建议设为600：composer config -g http.timeout 600 -
process-timeout：控制整个命令生命周期（如git clone、unzip、post-install-cmd），默认 300 秒。代理正常但卡在Executing command时，它才起作用，建议设为1200 - PHP 自身的
default_socket_timeout若低于你设的http.timeout（常见值是 60），会提前掐断连接，查它：php -i | grep default_socket_timeout
换镜像源后还失败？检查这三处隐形干扰
执行了 composer config -g repo.packagist https://mirrors.aliyun.com/composer/ 不代表就生效了：
- 镜像 URL 末尾必须带
/，少一个会拼出//packages.json导致 404 - 项目级
composer.json里写了repositories字段，会直接覆盖全局配置，得手动清理或同步更新 - 系统级代理、杀软 HTTPS 扫描、WSL2 元数据挂载异常，会让 TLS 握手卡在
* TLSv1.3 (IN), TLS handshake那一步——curl测通了，Composer 却静默超时
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，说明中转没配好 - 临时绕过代理测试：
HTTP_PROXY= HTTPS_PROXY= composer install，若此时成功，基本锁定是代理配置问题
最常被忽略的是：CI 容器重启后 composer config -g 的配置会丢失，且 COMPOSER_PROCESS_TIMEOUT 环境变量比命令行参数更可靠——尤其当插件或自定义 installer 启动子进程时。
