composer安全连接超时（如curl error 28）本质是默认http.timeout过短+tls握手卡顿所致，非证书错误；应优先调高http.timeout至600秒并强制ipv4（composer_ipresolve=4），而非更换镜像或修改证书配置。
Composer 安全连接超时（如 cURL error 28、TLS handshake timed out）不是证书错误，而是默认超时太短 + TLS 握手卡顿导致的假性“连不上”。优先调高 http.timeout 并强制 IPv4，比换源或重装证书更直接有效。
为什么 cURL error 28 不是证书问题
报错里带 Operation timed out after XXX milliseconds 就是典型 cURL error 28，本质是 TLS 握手或首字节响应太慢，被 Composer 默认的 http.timeout（约 60 秒）或 PHP 的 default_socket_timeout（常为 60 秒）截断。它和证书过期、curl: (60) SSL certificate problem 完全无关——后者会明确提示 SSL 或 certificate 关键词。
常见诱因包括：
- 国内 DNS 解析慢，导致
mirrors.aliyun.com域名查得久 - 系统启用 IPv6 但本地网络不支持，卡在 IPv6 连接尝试阶段
- 杀毒软件或防火墙做 HTTPS 中间人扫描，拖长 TLS 握手时间
- 镜像站 TLS 配置较新（如只支持 TLS 1.3），而旧版 cURL 或 OpenSSL 版本握手慢
http.timeout 和 process-timeout 必须分开设
很多人只改 process-timeout，结果依然卡在 Downloading https://... —— 因为下载包走的是 HTTP 请求，受 http.timeout 控制，不是外部进程。
永久生效（推荐）：
composer config -g http.timeout 600<br>composer config -g process-timeout 1200
注意：http.timeout 单位是秒，控制每次 HTTP 连接+读取总时长；process-timeout 控制 git clone、unzip 等外部命令生命周期。两者缺一不可。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
临时调试可合并使用环境变量：
COMPOSER_HTTP_TIMEOUT=600 COMPOSER_PROCESS_TIMEOUT=1200 composer install
强制 IPv4 避免 TLS 握手卡死
很多超时实际卡在 DNS 返回 IPv6 地址后，本地网络无法完成 IPv6 TCP 连接，cURL 会等满 http.timeout 才降级试 IPv4。直接跳过这一步最省事：
- 全局强制 IPv4：
export COMPOSER_IPRESOLVE=4 - Windows 用户在 CMD 中运行：
set COMPOSER_IPRESOLVE=4 - 该设置对所有后续
composer命令生效，无需重启终端
验证是否生效：运行 composer install -vvv，看日志里是否出现 Connected to mirrors.aliyun.com (118.31.175.211) port 443 (#0)（IPv4 地址），而非 [2408:400a:800:1::] 类 IPv6 地址。
别碰 cafile，除非你真有自签名证书
网上大量教程让你改 php.ini 的 curl.cainfo 或 Composer 的 cafile 配置，这反而容易引入新问题。Composer 2.2+ 自带证书包，且阿里云/腾讯云镜像均使用标准可信 CA 签发的证书，根本不需要手动指定。
真正要检查的是：
- 你的系统时间是否准确（TLS 严重依赖时间，误差 > 5 分钟就会握手失败）
- 是否开了代理但没配给 Composer（用
composer config -g --unset http.proxy清理残留） - 杀软是否启用 HTTPS 扫描（临时关闭测试）
复杂点在于：TLS 握手慢是隐性瓶颈，-vvv 日志里不会直接说“TLS 卡住了”，只会停在 Connecting to 后长时间无输出。这时候，COMPOSER_IPRESOLVE=4 + http.timeout 600 是最稳的第一响应动作。
