curl error 28 根本原因是本地到镜像的网络链路异常，需同步调大 http.timeout（控制http请求全程）和 process-timeout（控制子进程），并检查 default_socket_timeout、dns、代理、tls证书及ipv4/6设置。
为什么改了镜像还报 cURL error 28
换阿里云或腾讯云镜像后仍卡在 Downloading 或报 cURL error 28: Operation timed out，说明问题不在源站速度，而在本地到镜像的网络链路——DNS 解析慢、TLS 握手卡顿、中间代理丢包都可能触发。此时只换源不够，http.timeout 必须同步调大，否则 cURL 底层的 CURLOPT_TIMEOUT 会在 5 秒（默认值）后直接中断。
必须同时设 http.timeout 和 process-timeout
这两个参数作用完全不同，缺一不可：
-
http.timeout控制每次 HTTP 请求（如 GET /packages.json）的总等待时间，单位秒，影响 DNS + TCP + TLS + 响应体下载全过程 -
process-timeout控制 Composer 子进程（如git clone、unzip、post-install-cmd脚本）执行上限，和网络下载无关 - 常见错误：看到
cURL error 28却去调process-timeout，完全无效
推荐全局设置：
composer config -g http.timeout 600<br>composer config -g process-timeout 1800
若只临时生效，加命令行参数：composer install --timeout=1800（注意：该参数仅覆盖 process-timeout，http.timeout 仍需单独设或靠环境变量）
容易被忽略的底层干扰项
即使你把 http.timeout 设到 600，仍可能超时，因为 PHP CLI 的 default_socket_timeout ini 值会劫持 cURL 行为。运行 php -i | grep default_socket_timeout 查看当前值，若低于 600，需在 php.ini 中显式设为更大值（如 default_socket_timeout = 600）。
另外，Resolving dependencies 卡住时，http.timeout 完全不生效——那是 DNS 层问题，得用 dig mirrors.aliyun.com 或改 /etc/hosts 绑定 IP。
代理、证书、IPv4 强制这些细节真会影响超时
公司内网走代理却没配 http-proxy？运行 composer config -g http.proxy 确认；
TLS 握手失败（错误含 error:14090086）？不是超时问题，是证书链缺失，优先设 cafile 路径而非关验证；
IPv6 路由异常导致连接卡顿？临时强制 IPv4：export COMPOSER_IPRESOLVE=4。
真正麻烦的从来不是 timeout 数值本身，而是网络路径中某一段（DNS、TLS、代理、镜像节点）出现非对称延迟——它只在特定包、特定时刻爆发，所以调参前，先 curl -v https://mirrors.aliyun.com/composer/packages.json 看卡在哪一环。
