应采用多镜像源加并行下载而非L7代理，因Composer高频短连接与强缓存语义使Nginx/HAProxy易成瓶颈；正确做法是配置composer.json多镜像并设"canonical":false，启用parallel-downloads和http-max-concurrent-downloads参数，并禁用无意义重试。
单 Composer 镜像源扛不住 CI/CD 批量构建的并发冲击，直接改用多镜像 + 并行下载比加 L7 代理更有效、更轻量。
为什么不该在 Composer 镜像前硬套 Nginx 或 HAProxy
Composer 的 install 流程本质是大量短连接、高频率的 HTTP GET 请求（查 composer.json、packages.json、dist 包 URL、下载 zip），且每个请求都带强缓存语义（If-None-Match、Cache-Control）。L7 代理如 Nginx 若未精细调优，反而会成为瓶颈：
- 默认
proxy_buffering on对 KB 级响应（如packages.json）造成额外拷贝和延迟 - 健康检查若只做 TCP 端口探测，无法识别镜像站已同步卡顿或 token 服务不可用
- 不支持基于
User-Agent或Accept头的差异化路由，所有请求一视同仁，无法分流 dist 下载和 metadata 查询 - L4 代理（如 HAProxy）虽快，但完全无法感知 Composer 协议语义，故障节点仍会持续收包，引发批量
429或503
正确做法：用 Composer 原生 mirrors + 并行参数替代代理层
Composer 本身已内置负载分发能力，无需外挂负载均衡器。关键在于配置启用和参数对齐：
- 必须在项目
composer.json的repositories中声明多个镜像，并显式设置"canonical": false，否则只是 fallback 不是并发分发 - 全局启用并行下载：
composer config -g repos.packagist composer https://packagist.org→ 改为镜像地址后，再执行composer config -g fxp-asset.installer-paths {"npm-asset-library": "vendor/npm","bower-asset-library": "vendor/bower"}（非必需，但避免 asset 插件干扰） - 强制提升并发阈值：
composer config -g parallel-downloads 15和composer config -g http-max-concurrent-downloads 8，这两项直接影响 dist 包拉取的线程数 - 禁用无意义重试：
composer config -g github-protocols ["https"]避免 SSH 超时拖慢整体进度
当真需要代理层时，L4 + L7 协同才是底线配置
若因合规或审计要求必须统一出口（如所有 Composer 流量需经企业网关），则必须采用分层代理架构，而非单点 Nginx：
- 前端用 HAProxy（
mode tcp）做连接洪峰卸载，配置balance leastconn和timeout client 30s，避免连接堆积 - 后端接 Nginx（
mode http），仅代理到真实镜像站，并严格配置健康检查：health_check uri="/packages.json" interval=3 fails=2 passes=2 match=status 200 - 所有镜像后端必须开启
http.host绑定（如https://mirrors.tuna.tsinghua.edu.cn），禁止用0.0.0.0:80导致健康检查失败 - Nginx 中关闭
proxy_redirect，启用proxy_buffering off，并设置proxy_http_version 1.1+proxy_set_header Connection ''以复用连接
真正卡住 Composer 并发的，从来不是网络吞吐，而是单镜像源的限流策略与客户端重试逻辑的负反馈循环。把精力放在调参和镜像组合上，远比搭一套没人维护的 L7 代理更可靠。
