Composer网络代理并发连接限制分析-composer-PHP中文网

答案：只配http-proxy无效是因为HTTPS请求需https-proxy建立CONNECT隧道。必须同时设置http-proxy和https-proxy，且值须为http://开头；漏设、格式错或协议误会导致静默直连，卡在Loading repositories。

composer网络代理并发连接限制分析

为什么只配 http-proxy 还是卡在 Loading repositories

因为 Packagist 和所有主流镜像源都走 HTTPS，而 http-proxy 只影响 HTTP 请求；HTTPS 请求必须靠 https-proxy 建立 CONNECT 隧道，漏掉它就等于没配代理。现象是命令卡在 Loading composer repositories，日志里看不到错误，但 curl -x http://127.0.0.1:8080 -I https://mirrors.aliyun.com/composer/packages.json 会直接失败。

必须同时设置两个字段：

composer config -g http-proxy http://127.0.0.1:8080
composer config -g https-proxy http://127.0.0.1:8080（注意：值必须是 http:// 开头，哪怕代理本身监听 TLS）

填错格式（如写成 https:// 或漏协议）会导致静默 fallback 到直连，最终超时或 502。验证命令：composer config -g --list | grep -E "(http|https)-proxy"，两行都得有且 URL 格式合法。

并发连接被代理限流后出现 429 或 Connection refused 怎么办

企业级代理（如 Zscaler、SonicWall）常对单 IP 的并发连接数硬性限制，Composer 默认开 5–10 个并发下载，很容易触发 429 Too Many Requests 或 Connection refused。这不是 Composer 配置问题，而是代理层拦截后返回了非标准响应（比如 HTML 登录页），Composer 解析失败就退回到过期缓存或官方源。

验证是否被代理劫持：

curl -I -v https://mirrors.aliyun.com/composer/packages.json —— 必须返回 HTTP/2 200 和 Content-Type: application/json
curl --noproxy "*" -I https://mirrors.aliyun.com/composer/packages.json —— 如果这行能通，说明代理是根因

解决路径不是调高并发，而是降并发 + 清缓存 + 锁定单一镜像源：composer config -g repos.packagist.org.concurrent-downloads 2，composer clear-cache，composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（结尾 / 不能少）。

Composer 2.2+ 并发参数全失效？确认你用的是哪个配置项

Composer 2.2+ 彻底废弃了 parallel-downloads、--concurrency、COMPOSER_PARALLEL，设了也白设。唯一有效的并发控制是 http-max-concurrent-downloads，但它只控制 HTTP 下载阶段，且仅对 2.2.0 及以上版本生效。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

三步确认是否真生效：

运行 composer --version，输出必须是 Composer version 2.2.0 或更高；否则立刻 composer self-update
运行 composer install -vvv，观察日志里是否同时出现多行 Downloading https://；若只有一行在动，说明并发被静默降级（常见于 DNS 卡顿、镜像拦截或 PHP 未启用 cURL）
检查 php -m | grep curl，没启用 cURL 会强制串行且不报错

全局设置命令：composer config -g http-max-concurrent-downloads 6；拼写必须一字不差——少 http-、多一个连字符、漏 - 都无效。

CI/CD 中并发失控导致端口枯竭的组合修复

在 CI 流水线里高频执行 composer install --no-interaction，容易打满本地可用端口（Linux 默认 32768–65535），表现为 Cannot assign requested address 或大量 TIME_WAIT 连接。单改 Composer 配置没用，必须系统级协同优化。

缺一不可的三项操作：

启用内核复用：sudo sysctl -w net.ipv4.tcp_timestamps=1 和 sudo sysctl -w net.ipv4.tcp_tw_reuse=1（tcp_tw_recycle 已在 4.12+ 内核移除，任何文档提它都是过时的）
提升文件描述符上限：ulimit -n 若 ≤1024，需写入 /etc/security/limits.conf 并重启 session
统一使用单一镜像源（如阿里云），禁用混用多个镜像——不同目标 IP 导致四元组不匹配，tcp_tw_reuse 失效

CI 环境中还要加环境变量覆盖：COMPOSER_MAX_PARALLEL_HTTP_REQUESTS=4 composer install（注意不是 COMPOSER_PARALLEL，该变量自 2.2 起已失效）。这些改动作用于整个系统，但只对 Composer 所在 PHP 进程作为客户端时生效。