Composer不支持代理热更新，改配置后需重启命令；常见失效原因是https-proxy缺失或格式错误（必须http://开头）、未加-g参数、Windows权限问题或NTLM代理需中转。
Composer 本身不支持网络代理的“热更新”——改完 http-proxy 或 https-proxy 配置后，已运行的 composer install 进程不会自动切到新代理；它只在每次命令启动时读取一次配置，没有运行时重载机制。
为什么改了 proxy 配置却没生效？
常见现象是：执行 composer config -g http-proxy http://127.0.0.1:8080 后，composer update 仍走直连、卡在 “Loading composer repositories”、无报错但超时。原因很直接：
-
https-proxy缺失或格式错误（必须是http://开头，哪怕代理监听 HTTPS 端口） - 只配了
http-proxy，但 Packagist 全量走 HTTPS，https-proxy才真正管用 - 没加
-g参数，配置写进了当前项目composer.json，换目录就失效 - Windows 下
%APPDATA%\Composer\config.json权限不足，写入失败但无提示
验证代理配置是否完整且正确
别靠猜，用命令确认两字段都存在且协议/端口无误：
composer config -g --list | grep -E "(http|https)-proxy"
输出应类似：
http-proxy http://user:pass%40word@127.0.0.1:8080 https-proxy http://user:pass%40word@127.0.0.1:8080
注意：
- 密码含
@、/、:必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword -
https-proxy值绝不能是https://或无协议头，否则静默 fallback 直连 - 公司 NTLM 代理（如 Windows 域环境）无法被 Composer 原生支持，必须用
cntlm或px中转并监听127.0.0.1:3128，再让 Composer 连这个本地地址
代理生效但依然慢或失败？快速定位在哪一层断的
Composer 的网络请求链路是：CLI → Composer HTTP 层 → 本地代理进程 → 外网。任一环出问题都会表现为“卡住”。分步验证：
- 先确认本地代理进程是否在运行：
curl -x http://127.0.0.1:8080 -I https://packagist.org/packages.json—— 若也超时或 502，说明代理服务本身没起来或被防火墙拦了 - 若
curl成功但composer update -vvv失败，在日志里搜Downloading和GET，看实际发出的请求 URL 和响应头（尤其Content-SHA256是否存在） - 遇到
Invalid package information错误，大概率是镜像源不支持 Composer 2.5+ 要求的哈希透传，和代理无关，得换镜像（如阿里云已默认支持）
真要“热切换”代理，只能绕开 Composer 自身机制
如果你在 CI/CD 流水线中需动态选代理（比如测试不同出口 IP），不要依赖 composer config -g 写死配置。可行做法是：
- 用
COMPOSER_HOME环境变量临时指定独立配置目录：COMPOSER_HOME=/tmp/composer-test composer config -g https-proxy ...，再运行命令 - 在脚本中用
--no-plugins+--no-cache组合避免插件干扰和缓存污染 - 更彻底的方式：把代理逻辑下沉到系统层，例如 Linux 下用
export HTTPS_PROXY=http://...并确保 PHP cURL 模块能继承该变量（注意：Composer 默认忽略系统环境变量，但某些自定义 downloader 可能读取）
真正的难点不在配置写入，而在你永远无法让一个正在执行 composer update 的进程中途切换代理——它从启动那一刻起，代理设置就固化在内存里了。
