必须显式配置 http-proxy 和 https-proxy，否则 Composer 无法连接 packagist.org；它忽略系统环境变量，只认配置文件中的带连字符字段，且 https-proxy 值必须以 http:// 开头。
必须显式配置和，否则 Composer 会直连并卡在 “Loadingcomposerrepositories” —— 这不是慢，是根本连不上。
为什么
环境变量不生效
Composer 默认完全忽略系统级的
、
或任何环境变量。它只认自己配置文件里的
字段（注意带连字符，不是下划线）。很多用户反复 export 却没效果，根源就在这儿。
验证方式：运行
，检查输出中是否有
和
项
旧版写法
（无 s）已被弃用，优先以带
的字段为准
CI/CD 环境里设环境变量更方便，但本地开发请坚持用
必须填
协议
这是 Composer 的硬性限制：即使你用的是 HTTPS 代理服务，
的值也得写成
，不能写
或
（除非 Composer ≥ 2.2 且代理明确支持）。
错误示例：
→ 触发
或静默失败
正确写法：
（用户名/密码含
、
等需 URL 编码）
NTLM 代理不被原生支持，必须前置
或
做中转，再让 Composer 连
代理配对失败时的典型报错和快速验证法
配了代理还卡住？别猜，用最简命令直接验证链路是否通：
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
先确认代理进程在运行，端口没被防火墙拦截：
→ 代理未透传 TLS 或本地 CA 不被信任；换用
代理可绕过
或
→ 代理没开、端口错、或地址漏了
仍慢 → 检查是否漏配
，它内部也会访问
企业内网该用镜像还是代理
如果公司已部署阿里云、腾讯云或私有
镜像，**别配代理**——直接切源更稳：
全局切阿里镜像：
私有镜像地址示例：
镜像方案不依赖代理进程存活，无 TLS 证书问题，也避免认证类型不匹配（如 NTLM）
代理仅适合临时开发、小团队无镜像能力、或需要访问非 Packagist 的 GitHub/GitLab 包
真正容易被忽略的是：镜像源和代理不可共存。一旦配置了
，Composer 就不再走代理逻辑，所有流量定向到镜像地址。所以选一个，别混着来。
http-proxyhttps-proxypackagist.orghttp_proxyhttp_proxyHTTPS_PROXYhttp-proxycomposer config -g --listhttp-proxyhttps-proxyproxy-composer config -ghttps-proxyhttp://https-proxyhttp://127.0.0.1:7890https://socks5://https://127.0.0.1:7890Invalid URIhttp://user%40domain:pass%40word@127.0.0.1:7890@/cntlmpx127.0.0.1:3128curl -x http://127.0.0.1:7890 https://packagist.org/packages.jsonfile_get_contents(): SSL operation failedhttp://Connection refusedNo route to hosthttp://composer create-projecthttps-proxyhttps://repo.packagist.org/packages.jsonArtifactorycomposer config -g repo.packagist composer https://mirrors.aliyun.com/composer/composer config -g repo.packagist composer http://internal-mirror.yourcompany.com/composerrepo.packagist