Composer 代理必须同时配置 http-proxy 和 https-proxy，且 https-proxy 值也须以 http:// 开头；仅配 http-proxy 会导致 HTTPS 请求静默直连而卡在 Loading repositories。
composer config -g http-proxy 和 https-proxy 必须同时配对
只设 http-proxy，所有 HTTPS 请求（包括访问 https://packagist.org/packages.json）会静默 fallback 到直连，结果就是卡在 Loading composer repositories，不报错也不继续。这不是网络慢，是代理根本没走通。
必须同时运行两条命令：
composer config -g http-proxy http://127.0.0.1:7890composer config -g https-proxy http://127.0.0.1:7890
注意：https-proxy 的值也必须以 http:// 开头，哪怕你的代理服务监听的是 HTTPS 端口；填 https:// 或漏协议头都会被 Composer 忽略。
验证代理是否真生效，别信 config -g 的输出
composer config -g --list | grep -E "(http|https)-proxy" 只能确认字段存在，不能说明请求真走了代理。真实路径得靠 -vvv 日志抓取：
- 运行
composer install -vvv 2>&1 | grep -E "Downloading|Connected to" - 如果看到
Connected to 127.0.0.1，说明代理已走通；如果还是Connected to repo.packagist.org，说明配置未生效
常见失效原因：用了 sudo composer config -g，结果写进了 /root/.composer/config.json，但普通用户运行时读的是 $HOME/.composer/config.json。
临时代理生效的最简指令
不用改全局配置，临时绕过所有持久化设置，直接用环境变量驱动：
- Linux/macOS：
HTTP_PROXY=http://127.0.0.1:7890 HTTPS_PROXY=http://127.0.0.1:7890 composer install - Windows CMD：
set HTTP_PROXY=http://127.0.0.1:7890 && set HTTPS_PROXY=http://127.0.0.1:7890 && composer install - PowerShell：
$env:HTTP_PROXY="http://127.0.0.1:7890"; $env:HTTPS_PROXY="http://127.0.0.1:7890"; composer install
这个方式跳过了 config.json 解析，也避开了权限、路径、缓存干扰，适合快速验证代理链是否通畅。若此时成功，基本可锁定是全局配置写错或未生效。
NTLM 代理或企业中间人证书场景要额外处理
如果你的代理要求 Windows 域认证（比如返回 407 Proxy Authentication Required），Composer 原生不支持 NTLM，硬配 http-proxy 没用。必须加一层中转：
- 装
cntlm或px，让它监听127.0.0.1:3128并处理 NTLM 认证 - 再把 Composer 的代理指向它：
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，说明中转没配好
另外，Clash/Surge 类工具常劫持 TLS 流量并签发自签名证书，PHP 的 OpenSSL 默认不信任——此时即使代理通了，也会卡在 SSL handshake failed。临时解法是 composer config -g cafile /path/to/your-proxy-root-ca.pem，但更稳妥的是让系统 CA store 包含该根证书。
