Composer网络代理负载均衡调度-composer-PHP中文网

composer镜像配置必须同时满足四要素：-g、repo.packagist（单数小写）、composer（type值）、https且末尾带/，缺一即静默失效；代理需同时设proxy和ssl-proxy；多镜像须配"canonical":false才并发；下载加速依赖parallel-downloads与http-max-concurrent-downloads全局配置。

composer网络代理负载均衡调度

直接配代理 + 多镜像并行下载，比在 Composer 前硬套 Nginx/HAProxy 更稳、更快、更少故障点。

composer config -g proxy 和 ssl-proxy 必须同时设

Composer 100% 走 HTTPS 请求，只配 repo.packagist.org.proxy 不生效——它会尝试用 HTTP 代理转发 HTTPS 流量，结果是静默超时或 502。必须补上 repo.packagist.org.ssl-proxy 才能真正走通 TLS 隧道。

正确写法（以 Clash HTTP 代理为例）：composer config -g repo.packagist.org.proxy http://127.0.0.1:7890 和 composer config -g repo.packagist.org.ssl-proxy http://127.0.0.1:7890
SOCKS5 代理需 Composer ≥ 2.2，且协议必须写全：socks5://127.0.0.1:7891，漏掉 socks5:// 会被当成普通 HTTP 地址解析失败
验证是否生效：运行 composer config -g 查看输出中是否有这两项；再执行 curl -x http://127.0.0.1:7890 https://packagist.org/packages.json 确认代理本身可用

多镜像源必须设 "canonical": false 才触发并发分发

只在 composer.json 的 repositories 里加几个镜像地址，不设 "canonical": false，Composer 默认只当 fallback 用——查第一个失败才试第二个，根本不会并发请求。

First Principles Decomposer

把任何问题拆解为根本真理，再从原子层面重建解决方案。

下载

正确配置示例（注意 canonical 是布尔值，不是字符串）：

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://mirrors.aliyun.com/composer/",
      "canonical": false
    },
    {
      "type": "composer",
      "url": "https://packagist.phpcomposer.com/",
      "canonical": false
    }
  ]
}

若其中一个是官方源（https://packagist.org），也必须显式设 "canonical": false，否则 Composer 会把它当作“唯一权威源”，其他镜像退化为只读 fallback
该字段控制的是“是否允许并行查询多个源的 metadata”，不是下载阶段的分流；dist 包下载靠的是 parallel-downloads 参数

parallel-downloads 和 http-max-concurrent-downloads 是 dist 下载提速关键

Composer 默认最多并发 6 个 dist 包下载（zip/tar），对 CI/CD 批量构建明显不够。这两个参数才是实际起效的并发阈值，且必须全局设（-g），项目级 config 不影响下载器行为。

推荐值（兼顾稳定性与吞吐）：composer config -g parallel-downloads 15 和 composer config -g http-max-concurrent-downloads 8
parallel-downloads 控制总并发任务数（含 metadata 查询 + dist 下载），http-max-concurrent-downloads 专管 dist 下载连接数，后者不能超过前者
设太高反而容易触发镜像站限流（如阿里云镜像对单 IP 每秒请求数有限制），15/8 是多数国内镜像实测较稳的上限
禁用无意义重试：composer config -g github-protocols ["https"]，避免 SSH 协议卡住整个流程

L4/L7 代理在 Composer 场景下极易成为瓶颈

Nginx 或 HAProxy 做 Composer 流量入口，不是“加了就稳”，而是引入新故障面：短连接洪峰压垮 proxy_buffer、健康检查无法感知 metadata 同步延迟、所有请求一视同仁无法区分 /packages.json 和 /dist/xxx.zip。

典型症状：Loading composer repositories 卡住几十秒，日志显示大量 Connection refused 或 503 Service Temporarily Unavailable，但后端镜像站本身完全正常
若真需统一出口（如审计要求），底线方案是 L4 + L7 协同：HAProxy（mode tcp）做连接卸载 + leastconn 负载，后端接 Nginx（mode http）仅做路由和健康检查，且健康检查 URI 必须是 /packages.json，间隔 ≤20s
绝大多数场景，删掉代理层，直接靠 Composer 原生多镜像 + 并发参数，延迟更低、成功率更高、排障路径更短

最常被忽略的一点：镜像源之间的同步延迟是客观存在的，"canonical": false 并发查多个源时，可能拿到不同时间点的 packages.json，导致依赖解析冲突；生产环境务必搭配 composer.lock 提交，而非依赖实时解析。