Composer临时代理无效是因全局配置优先于环境变量，需用composer config -g --unset清除http-proxy和https-proxy，并检查镜像源是否干扰。
临时设置代理后命令仍不走代理？先确认是否被全局配置覆盖
Composer 不会读取 HTTP_PROXY 或 HTTPS_PROXY 环境变量，所以用 HTTP_PROXY=http://127.0.0.1:7890 composer install 这种写法一定无效。它只认自己配置里的 http-proxy 和 https-proxy 字段。
更常见的情况是：你刚用 composer config -g http-proxy ... 配过全局代理，现在想临时绕过，但忘了清掉——结果环境变量没用，全局配置又还在，命令就继续走老代理。
- 检查当前生效的代理配置：
composer config -g --list | grep -E "(http|https)-proxy" - 若输出非空，说明全局代理仍在起作用，临时环境变量不会覆盖它
- 要真正“临时禁用”，得在命令前同时清空两个字段：
HTTP_PROXY= HTTPS_PROXY= composer install
为什么 composer config --unset http-proxy 没清掉？注意作用域
不加 -g 参数的 composer config --unset http-proxy 只删当前项目 composer.json 里的 config.http-proxy，对全局配置毫无影响。而绝大多数人配代理都是用 -g 配的，所以删错地方了。
- 清全局代理必须带
-g：composer config -g --unset http-proxy和composer config -g --unset https-proxy要各执行一次 - 删完立刻验证：
composer config -g --list | grep -E "(http|https)-proxy"应该无输出 - 如果仍看到输出，可能是权限问题（如 Windows 下 %APPDATA%\Composer\config.json 只读），需手动编辑该文件
代理清掉了，但还是卡在 Loading composer repositories？检查镜像是否干扰
国内用户最容易忽略的一点：镜像源和代理不能共存。一旦设置了 repo.packagist，Composer 会直接改写请求地址为镜像域名，http-proxy 和 https-proxy 字段会被完全忽略。
- 运行
composer config -g repo.packagist查看是否还残留镜像配置 - 若有，用
composer config -g --unset repo.packagist彻底清除（Composer 2.2+ 后此键名已废弃，但旧值仍可能残留） - 再验证：
composer diagnose中 “Repo packagist.org” 行应显示https://packagist.org，而非镜像地址
临时代理生效了，但请求仍失败？重点查 CONNECT 隧道是否建立
即使 http-proxy 和 https-proxy 都配对了，HTTPS 请求仍需通过 CONNECT 隧道转发。如果代理服务本身没启动、端口被防火墙拦截、或认证失败，Composer 日志里往往只显示 “Loading composer repositories”，不报具体错误。
- 手动测试隧道是否通：
curl -x http://127.0.0.1:7890 -I https://packagist.org/packages.json - 若返回
407 Proxy Authentication Required，说明代理需要认证但没传；若超时或连接拒绝，说明本地代理进程未运行或端口不对 - 加
-vvv看详细日志：composer install -vvv 2>&1 | grep -i "proxy\|connect"，确认是否出现Proxy CONNECT字样
代理配置最易被忽略的复杂点在于：它不是“设了就走”，而是依赖 http-proxy + https-proxy 两字段同时存在、格式合规、且未被镜像或项目级配置静默屏蔽。任何一个环节断开，表现都一样——卡住，无提示，让人反复怀疑网络。
