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或阿里 DNS223.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=注释掉
