X-Accel-Buffering 对 Composer 完全无效，因其是 Nginx 专用响应头，Composer 的 cURL 客户端不解析任何响应头，仅依赖本地 cache-files-ttl、http-max-concurrent-downloads 和缓存目录 I/O 性能。
Composer 不读 X-Accel-Buffering，配了也没用。 这个头是给 Nginx 看的，用来控制它是否缓冲后端 PHP 响应；而 Composer 的 HTTP 客户端（基于 cURL）压根不解析任何响应头，更不会据此调整行为。
为什么 X-Accel-Buffering 对 Composer 完全无效
Composer 拉取元数据（如 packages.json）时，只做两件事：检查本地缓存文件的时间戳、按 cache-files-ttl 判断是否过期。它不发条件请求（If-None-Match）、不看 ETag、不认 Cache-Control，当然也不管 X-Accel-Buffering —— 这个头连进不到 Composer 进程里。
这个头实际生效的位置在 Web 服务器层（比如你用 Nginx 反向代理一个自建 Composer 镜像服务），作用对象是浏览器或 curl 等客户端，不是 Composer 本身。
- 你在镜像源服务器上加
X-Accel-Buffering: no，影响的是访问该镜像的终端用户（比如前端页面请求 JSON） - 你在本地 PHP 里输出这个头，对
composer install调用毫无意义——Composer 不接收、不解析、不转发 - 即使镜像站返回了
X-Accel-Buffering: no，Composer 也当它不存在，照样走自己的 TTL 逻辑
真正影响 Composer 二次拉取速度的三个本地配置项
别折腾响应头，直接调 Composer 自己的缓存开关：
-
cache-files-ttl：元数据缓存秒数，默认900（15 分钟）。建议设为15552000（6 个月），避免频繁重拉：composer config --global cache-files-ttl 15552000 -
http-max-concurrent-downloads：并发下载数，默认5。内网高速镜像可提到15：composer config --global http-max-concurrent-downloads 15 - 缓存目录位置与磁盘 I/O：确保
~/.composer/cache/repo/在 SSD 上，且不被杀毒软件实时扫描
误配镜像 URL 尾部斜杠导致的 HTTP/1.1 fallback
这不是响应头问题，但常被当成“流式卡顿”的原因：如果镜像 URL 缺少结尾 /，Composer 拼路径会出错，触发 404 → 自动降级直连 packagist.org → 全部退化为 HTTP/1.1，连接复用失效，表现就是 Loading composer repositories 卡住几秒到几十秒。
- 错误写法：
https://mirrors.aliyun.com/composer（没斜杠） - 正确写法：
https://mirrors.aliyun.com/composer/（必须带斜杠） - 验证方式：
composer config --global repo.packagist.org.url，确认输出含末尾/
真正要优化 Composer 拉取性能，盯住本地 TTL 和并发数就行；HTTP 响应头那套机制，在 Composer 世界里只是旁观者。
