必须同时配置http-proxy和https-proxy，否则https请求将直连超时；https-proxy值必须以http://开头，且两者需通过composer config -g命令全局设置。
composer config -g http-proxy 和 https-proxy 必须同时存在
Composer 对 HTTP 和 HTTPS 请求使用完全独立的代理路由逻辑，http-proxy 只影响 http:// 协议请求（极少用），而所有 Packagist、GitHub 等源都走 https://，必须靠 https-proxy 建立 CONNECT 隧道。漏掉任意一个，HTTPS 请求就 fallback 到直连，现象是 Loading composer repositories 卡住、无报错、最终超时或 cURL error 35。
正确做法是两条命令一起执行：
composer config -g http-proxy http://127.0.0.1:8080composer config -g https-proxy http://127.0.0.1:8080
注意：https-proxy 的值**必须是 http:// 开头**，哪怕你的代理监听的是 TLS 端口（如 443）——Composer 不支持 https:// 代理地址，填错会静默失败。
https-proxy 值写错的典型表现和验证方式
填成 https://127.0.0.1:8080、127.0.0.1:8080 或漏认证信息中的 @ 符号（如密码含 @ 未 URL 编码），都会导致 Composer 无法建立隧道，但不会报错，只会卡在元数据拉取阶段。
验证是否真正生效，别信 composer diagnose，直接运行：
composer config -g --list | grep -E "(http|https)-proxy"
输出中必须同时出现两行，且 URL 格式合法（含协议、主机、端口）。Windows 用户改完要重启终端，否则读不到新配置。
项目级配置会彻底覆盖全局代理设置
只要项目根目录的 composer.json 中存在 repositories 字段（哪怕只是空数组 "repositories": []），Composer 就会忽略全局的 http-proxy 和 https-proxy，转而使用项目级配置逻辑。此时代理失效不是“没配好”，而是被硬编码优先级屏蔽了。
如果你需要保留私有仓库又想走代理，不能依赖 composer config repo.packagist 这类命令——它会把整个 repositories 替换为单个对象，清空原有私有源。必须手动编辑 composer.json，在 repositories 数组里显式加 "type": "composer" 源，并确保其 url 走 HTTPS，才能触发 https-proxy 生效。
NTLM 代理或公司内网环境下代理不工作怎么办
Composer 原生不支持 NTLM 认证。设了 http-proxy 后仍返回 407 Proxy Authentication Required，说明代理层要求域身份验证，而 Composer 直接透传失败。
解决方案不是调 Composer 配置，而是加一层中转代理：
- Windows 域环境：装
cntlm或px，让它监听127.0.0.1:3128并处理 NTLM，再让 Composer 连这个本地地址 - 临时验证：用
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json测试中转层是否通
别试图用 HTTP_PROXY 环境变量绕过——Composer 明确忽略它，只认自己的字段。
代理配置最易被忽略的点：它和镜像源互斥。一旦配了 repo.packagist 镜像，Composer 就不再发请求到 packagist.org，https-proxy 自然也不会被用到。真要调试代理链路，得先 composer config -g --unset repo.packagist，再清缓存、重试。
