composer怎么解决网络不稳定报错_设置composer下载重试【方案】

composer报“Connection refused”或“curl Error 28”是因默认超时过短导致，需调大process-timeout、换稳定镜像、清缓存、确保Openssl支持TLS 1.2并正确配置DNS。

composer install/update 时提示 “Connection refused” 或 “cURL error 28” 怎么办

这是网络超时导致的典型错误，curl 等底层工具在等待响应时主动中断了连接。Composer 默认超时时间太短（尤其在国内镜像不稳定或 DNS 波动时），不是网络真断了，而是等不及。

• composer config -g github-protocols https：强制 github 走 https，避免某些企业网络拦截 git:// 协议
• 加 --timeout 300 参数临时延长单次请求上限，比如 composer update --timeout 300
• 别依赖默认值——timeout 默认只有 300 秒，但实际单个包下载可能卡在 DNS 解析或首字节延迟上，真正起效的是 process-timeout

怎么让 composer 自动重试失败的下载请求

Composer 本身不提供“重试 N 次”的内置开关，但可以通过环境变量和配置组合实现稳定下载行为。

• 设置 COMPOSER_PROCESS_TIMEOUT=600（单位秒），它控制的是整个命令生命周期，不是单个 HTTP 请求；值太小会导致大包直接被 kill
• 用 COMPOSER_HOME 指向一个可写的目录，确保缓存能正常写入，否则重试时连本地 fallback 都没有
• 最关键的其实是镜像源稳定性：国内推荐用 https://packagist.phpcomposer.com（已停）或当前有效的 https://mirrors.aliyun.com/composer/，通过 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 设置

为什么换了镜像还报错 “file could not be downloaded”

这不是镜像地址问题，而是 Composer 在校验包完整性时发现下载内容和 dist.sha256 不匹配，常见于中间代理劫持、CDN 缓存污染或 DNS 劫持。

• 先运行 composer clear-cache，清除可能损坏的缓存文件
• 检查是否启用了非官方插件（如 hirak/prestissimo），它会并发下载但不校验顺序，容易触发校验失败；临时禁用：composer global remove hirak/prestissimo
• 如果用 docker，确认容器内 DNS 配置没走 host 的不可靠 DNS（比如 114.114.114.114 在某些地区返回错误 IP），改用 8.8.8.8 或阿里 DNS 223.5.5.5

PHP 版本和 OpenSSL 配置也会导致下载失败

哪怕网络通畅，低版本 PHP 或编译时未启用 TLS 1.2 支持，也会在连接现代镜像站时静默失败。

• 运行 php -r "print_r(stream_get_transports());"，确认输出包含 ssl 和 tls
• 检查 openssl.version：PHP 7.1.2+ 才默认支持 TLS 1.2；低于此版本即使设了超时也连不上新版 packagist 镜像
• 在 php.ini 中确认 extension=openssl 已启用，且没被 ;extension= 注释掉

重试机制本质是掩盖不稳定，但真正关键的是让每次请求都更大概率成功——镜像源、DNS、PHP 底层传输能力，这三块缺一不可。很多人调了 timeout 却忽略 openssl 是否就绪，结果重试十次还是卡在同一个地方。