composer如何设置超时重试机制?(http-retry-count配置项)

2次阅读

composer网络超时需同时设置http-retry-count(如5)和http-timeout(如900),并切换国内镜像源;单独调高重试次数无效,curl Error 28等底层超时须换源或调整防火墙策略。

composer如何设置超时重试机制?(http-retry-count配置项)

composer install/update 时网络超时怎么办

默认情况下,Composer 不会自动重试失败的 HTTP 请求,遇到网络抖动或源响应慢就直接报错退出。关键不是“能不能重试”,而是 http-retry-count 这个配置项只控制「HTTP 请求层面」的重试次数,不覆盖所有网络异常(比如 DNS 解析失败、连接被拒绝等),且必须配合 http-timeout 才能生效。

  • http-retry-count 默认是 3,但仅对 5xx 响应码和部分临时性连接中断生效;4xx 错误(如 404)不会重试
  • 重试不是线性等待,Composer 内部用指数退避策略,第一次失败后约 1 秒再试,第二次约 2 秒,第三次约 4 秒
  • 如果用了私有源(如 Satis、Artifactory),需确认其返回的 HTTP 状态码是否符合重试条件,有些代理会把超时转成 502/504,这能触发重试;而直接断连则不能
  • 执行命令前可临时加大超时: COMPOSER_HTTP_TIMEOUT=600 composer install(单位秒),比改全局配置更安全

怎么设置 http-retry-count 和 http-timeout

这两个配置必须同时设才实际起作用。单独调高 http-retry-count 没意义——因为默认 http-timeout 只有 300 秒,单次请求若卡住超过这个时间,重试根本没机会触发。

  • 全局设置(影响所有项目):composer config -g http-retry-count 5composer config -g http-timeout 600
  • 项目级设置(推荐):composer config http-retry-count 5 + composer config http-timeout 600,写入当前项目的 composer.jsonconfig 字段
  • 注意:配置值必须是整数,"http-timeout": "600"字符串)会被忽略,必须写成 "http-timeout": 600
  • 验证是否生效:运行 composer config --list,检查输出中 http-retry-counthttp-timeout 的值是否为你设的数字

为什么设置了还是报 cURL error 28 或 Operation timed out

这类错误说明请求在 http-timeout 限定时间内没收到任何响应,已由 cURL 底层直接终止,Composer 的重试逻辑根本没机会介入。

  • cURL error 28 是典型的「等待响应超时」,常见于国内访问 packagist.org 官方源,本质是网络链路不稳定,不是服务器忙
  • 此时该换镜像源,而不是 retry 参数:composer config -g repo.packagist composer https://packagist.phpcomposer.com(注意:该镜像已停用,应改用 https://mirrors.aliyun.com/composer/
  • 某些企业防火墙会主动 kill 长连接,即使设了 600 秒 timeout,也可能在 60 秒左右被截断,这时要联系运维调整出口策略
  • composer install -v 查看详细日志,确认出错的是哪个 URL——如果是 packages.json 元数据请求失败,重试有用;如果是某个具体 .zip 下载中断,则重试只针对那个文件的 GET 请求,不影响其他包

自定义重试逻辑的替代方案

Composer 本身不支持 hook 重试行为,也没提供事件监听机制。真有强定制需求(比如按错误类型分策略、加日志、换源 fallback),只能绕过原生命令。

  • 用 shell 脚本包装:循环执行 composer update,捕获退出码,遇到 2(网络错误)就 sleep 后重试,最多 3 次
  • 改用 curl + jq 手动拉取 packages.json,解析后用 composer require 逐个装,但这只适合极简场景
  • 最务实的做法:把 http-retry-count 设到 5,http-timeout 设到 900,再配好国内镜像源,99% 的 CI 场景够用
  • 别忘了清理缓存:composer clear-cache,旧缓存里可能存着失败的元数据,导致后续安装反复失败

真正难处理的从来不是重试次数,而是那些不返回 HTTP 状态码的底层连接问题——它们既不进 Composer 的重试判断,也不在 http-timeout 的管辖范围里。

text=ZqhQzanResources