Composer报错curl error 28超时_网络环境排查与优化【常见问题】-composer-PHP中文网

curl error 28超时本质是dns解析或tcp连接失败，非composer配置问题；应先用curl -v和nslookup验证网络通路与dns，再换镜像源或调git/ssh超时。

composer报错curl error 28超时_网络环境排查与优化【常见问题】

确认是不是真超时，还是 DNS 或镜像源卡住

看到 cURL error 28: Operation timed out after 300000 milliseconds 别急着调 timeout——这数字是毫秒，300 秒（5 分钟）已经很长了。大概率不是“等太久”，而是根本没发出去或卡在 DNS 解析、源站不可达、SSH 连接不上这些环节。

先快速验证：运行 curl -v https://packagist.org/packages.json，看是直接失败、卡在 * Trying 185.199.108.153:443...（TCP 连接阶段），还是卡在 * Connected to packagist.org (185.199.108.153) port 443 (#0) 之后（TLS 握手或 HTTP 响应阶段）。前者盯 DNS 和网络通路，后者才考虑 Composer 配置。

用 nslookup packagist.org 或 dig packagist.org +short 检查 DNS 是否返回 IP
如果用的是国内服务器，ping packagist.org 很可能不通（ICMP 被墙），但 curl -I https://mirrors.aliyun.com/composer/packages.json 应该秒回
换镜像源是最有效第一步：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/

HTTP 请求超时只影响 metadata 查询，不控制 git clone

Composer 的 http.timeout 和 http.connect_timeout 配置项（如 composer config -g http.timeout 600）只对它自己发起的 HTTP(S) 请求生效，也就是查包列表、下载 packages.json 这类动作。一旦进入下载代码阶段，行为就分叉了：

如果包定义里 "source": {"type": "git", "url": "git@github.com:..."}，Composer 会直接调 git clone，此时超时由 Git 自己管，和 Composer 配置无关
如果走 HTTPS zip 下载（"dist": {"type": "zip", "url": "...", "shasum": "..."}），那才走 Composer 的 HTTP 配置
查具体包用什么方式拉：composer show vendor/package --all | grep -A5 source

所以你调大 http.timeout 后还卡在 Cloning into 'xxx'...，说明问题在 Git 层，不是 Composer。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

Git 克隆超时得单独设，SSH 和 HTTPS 处理方式不同

Git 的超时不能通过 Composer 控制，必须从 Git 本身或系统层下手。常见场景有两类：

用 git@github.com SSH 地址时，超时由 SSH 客户端决定：git config --global core.sshCommand "ssh -o ConnectTimeout=30 -o ServerAliveInterval=30"
用 https://github.com 时，可强制让 Composer 放弃 git 协议：composer config -g github-protocols https，这样即使包声明了 git source，也会退到 zip 下载
全局禁用 git（慎用）：composer config -g use-github-api false，但私有仓库或需要 GitHub API 的功能会失效
如果走代理，确保 git config --global http.proxy 和 https.proxy 设置正确，且代理本身没限速或断连

别忽略 PHP 和 cURL 底层限制

Composer 是 PHP 程序，它底层依赖系统的 cURL 扩展和 PHP 的 socket 设置。有些环境（尤其是 Docker 或共享主机）会默认限制 socket 超时，导致 Composer 的配置无效：

检查 php.ini 中 default_socket_timeout = 300（单位秒），太小会截断 Composer 的长连接
确认 cURL 版本：php -r "echo curl_version()['version'] . "\n";"，低于 7.52.0 的旧版本在某些 TLS 握手下容易假死
临时绕过所有缓存和更新检查：composer install --no-scripts --no-plugins --prefer-dist，能快速判断是否卡在脚本执行或插件逻辑里

真正难搞的 case 往往是 DNS 解析慢 + Git over SSH + 本地防火墙拦截重试包，三者叠在一起时，单纯加 timeout 只会让等待时间更煎熬。先用 strace -e trace=connect,sendto,recvfrom composer install -vvv 看第一处阻塞点在哪，比盲目调参靠谱得多。