composer必须显式配置http-proxy和https-proxy，因其不读取http_proxy/https_proxy环境变量；两者缺一会导致https请求直连失败，卡在“loading composer repositories”且无报错。
Composer为什么必须显式配 http-proxy 和 https-proxy
Composer 不读 HTTP_PROXY 或 HTTPS_PROXY 环境变量，这是硬性设计——它只认自己配置项里的 http-proxy 和 https-proxy。漏掉任意一个，就会出现“卡在 Loading composer repositories”却无报错的现象。
根本原因是：Composer 对协议严格分流。访问 http:// 地址（比如某些旧仓库）走 http-proxy；而 Packagist、GitHub 等全部使用 https://，必须靠 https-proxy 建立 CONNECT 隧道。两者缺一，HTTPS 请求就 fallback 到直连，被企业防火墙或网络策略静默拦截。
-
https-proxy的值必须是http://开头，哪怕代理服务本身监听 TLS 端口（如http://127.0.0.1:8080），填https://或漏协议头都会失效 - 用户名/密码含
@、/、:时，必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword - 执行
composer config -g --list | grep -E "(http|https)-proxy"可快速验证是否两个字段都存在且格式正确
镜像源和代理不能共存
设了 repo.packagist 镜像（如阿里云源），http-proxy 和 https-proxy 就完全不生效——Composer 会直接访问镜像站地址，绕过所有代理逻辑。混配会导致 TLS 握手失败、静默超时或 “cURL error 35”。
真要用代理，第一步必须清空镜像：
- 运行
composer config -g --unset repo.packagist（注意不是repos.packagist或packagist.org） - 确认没有残留的
repo.packagist.org.proxy类配置（那是旧版 Composer 的写法，新版已弃用） - 再执行两条配对命令：
composer config -g http-proxy http://127.0.0.1:7890和composer config -g https-proxy http://127.0.0.1:7890
NTLM 代理或企业根证书场景怎么处理
Composer 原生不支持 NTLM 认证。如果公司用 Windows 域代理，直接设 http-proxy 会返回 407 Proxy Authentication Required 或连接拒绝。
必须引入中转层：
- 用
cntlm或px在本地启动一个 HTTP 代理（如127.0.0.1:3128），让它负责与 NTLM 代理通信 - 再让 Composer 连这个本地地址：
composer config -g http-proxy http://127.0.0.1:3128和https-proxy同理 - 证书问题常见于企业内网：运行
composer config -g cafile /path/to/company-root.pem指向内部 CA 证书，别用系统默认的ca-bundle.crt
如何确认代理真正在工作
加 -n -vvv 参数运行命令，比如 composer install -n -vvv，日志里出现 Proxy CONNECT 才算真正走通。没这行，说明代理没触发，大概率是镜像未清空或字段缺失。
临时验证代理连通性，别依赖 Composer：
- 用
curl -x http://127.0.0.1:7890 -I https://packagist.org/packages.json测试 CONNECT 是否成功 - 检查代理进程是否运行、端口是否监听、防火墙是否放行（特别是腾讯云 VPC 内默认无代理需求）
- Windows + WSL2 用户注意时间不同步也会导致 TLS 握手失败，可运行
sudo hwclock -s
最易被忽略的点：代理配置是“全有或全无”，少一个字段、错一个协议头、混一个镜像，都会让整个代理链路静默失效——它不会报错，只会卡住或 fallback 直连。
