composer config -g http-proxy不生效的典型原因：未加-g参数导致仅写入项目级配置（实际被忽略），https-proxy值未用http://开头而静默失效，NTLM代理需中转工具而非直接配置。
composer config -g http-proxy 命令不生效的典型原因
直接运行 composer config http-proxy http://127.0.0.1:7890（漏掉 -g）只会写入当前目录下的 composer.json，换项目或 cd 到别处就失效。这不是“输错了”，而是没加全局标记。
必须加 -g（等价于 --global），否则配置不落地到 %APPDATA%\Composer\config.json（Windows）或 ~/.composer/config.json（macOS/Linux）。
-
composer config -g http-proxy http://127.0.0.1:7890✅ 全局生效 -
composer config http-proxy http://127.0.0.1:7890❌ 仅当前项目 composer.json 生效，且该字段在项目级配置中实际被忽略 - 若已误配，用
composer config -g --unset http-proxy清除再重设
https-proxy 必须用 http:// 开头，填 https:// 就静默失败
这是 Composer 的硬性路由规则：它对 HTTPS 请求只认 https-proxy 字段，但该字段值协议头必须是 http:// ——哪怕你的代理服务监听的是 TLS 端口（如 Clash 的 HTTPS 模式），也得写成 http://127.0.0.1:7890。
填成 https://127.0.0.1:7890 或漏协议头（如 127.0.0.1:7890）会导致所有 HTTPS 请求 fallback 直连，现象是卡在 Loading composer repositories 或报 cURL error 28，却无明确错误提示。
- 正确写法：
composer config -g https-proxy http://127.0.0.1:7890 - 带认证时密码含
@、/、:必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword - 验证是否写入成功：
composer config -g --list | grep -E "(http|https)-proxy"，应同时看到两行
NTLM 代理（如公司域环境）不能靠 config 解决
Composer 原生不支持 NTLM 认证。即使你把 http-proxy 和 https-proxy 都设成 http://domain\user:pass@proxy.corp:8080，也会直接返回 407 Proxy Authentication Required 或 Unable to connect to http://repo.packagist.org。
根本解法是引入中转代理工具，让它们处理 NTLM 并暴露一个本地 HTTP 端口供 Composer 连接：
- Windows 推荐
cntlm或px，监听127.0.0.1:3128 - 然后统一设：
composer config -g http-proxy http://127.0.0.1:3128和composer config -g https-proxy http://127.0.0.1:3128 - 验证中转层是否通：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，若也报 407，说明 cntlm/px 没配好认证凭据
临时绕过代理测试是否真由 proxy 导致失败
有时候你以为是代理问题，其实是 DNS、PHP 超时或镜像源失效。最简单的验证方式是临时禁用代理执行命令：
HTTP_PROXY= HTTPS_PROXY= composer install
如果此时成功，基本锁定是代理配置或链路问题；如果仍失败，就得查别的环节——比如是否用了 HTTP 镜像源（v2 默认拒绝）、php.ini 中 default_socket_timeout 是否太小、或 repo.packagist 是否还指向 http:// 地址。
别指望系统级 HTTP_PROXY 环境变量能覆盖 Composer 行为，它明确忽略这些变量，只读自己的 http-proxy 和 https-proxy 配置项。
