Composer不读取系统http_proxy环境变量，必须用composer config -g同时配置http-proxy和https-proxy（均以http://开头），否则HTTPS请求直连超时。
Composer 不读系统环境变量 http_proxy 或 https_proxy，直接设环境变量对它完全无效。必须用 composer config -g 显式配置代理地址，否则所有请求仍走直连。
为什么设了 http_proxy 环境变量却没用
Composer 从不检查系统级代理变量，这是它和 curl、wget 的关键区别。即使你在 shell 里执行了 export http_proxy=http://127.0.0.1:7890，composer install 依然会尝试直连 packagist.org，结果就是卡在 “Loading composer repositories”。
- 不是 Composer 忘了读，是它压根不支持——源码里没实现这个逻辑
-
HTTPS请求默认不走http_proxy，而 Composer 100% 走 HTTPS，所以https_proxy也无效 - Windows 下用
set http_proxy=...或 PowerShell 的$env:http_proxy同样白搭
composer config -g 配代理的正确写法
必须同时配 proxy 和 ssl-proxy，且协议、地址、端口一个都不能少。漏掉 http:// 或写成 https:// 会导致 Invalid URI 错误。
- HTTP 代理（推荐）：
composer config -g repo.packagist.org.proxy http://127.0.0.1:7890 - HTTPS 代理（必须同步设）：
composer config -g repo.packagist.org.ssl-proxy http://127.0.0.1:7890 - SOCKS5 代理（仅 Composer ≥ 2.2）：
composer config -g repo.packagist.org.proxy socks5://127.0.0.1:7891 - 取消代理：
composer config -g --unset repo.packagist.org.proxy和composer config -g --unset repo.packagist.org.ssl-proxy
代理配错的典型报错和验证方法
配了但没生效，日志不会明说“代理连不上”，而是表现为超时或 TLS 失败。最稳的验证方式是手动 curl 测试代理连通性。
-
file_get_contents(): SSL operation failed→ 代理未透传 TLS 流量，换用http://代理可绕过 -
Connection refused或No route to host→ 代理进程未启动、端口填错、或防火墙拦截 - 验证代理是否可用：
curl -x http://127.0.0.1:7890 https://packagist.org/packages.json -I，返回200 OK才算通 - 确认 Composer 是否真在用代理：
composer install -vvv，看日志里实际请求的 URL 和 IP 是否来自代理出口
代理和镜像源不能共存——要么全走代理，要么全走镜像。混用会导致部分请求被重定向到海外节点，反而更慢。另外，CI 或宝塔等环境里，composer config -g 写的是当前用户配置，但执行命令的可能是 www 或 jenkins 用户，这点最容易被忽略。
