Composer 在 Linux 上报 curl error 28 是因 HTTP 请求超时，默认仅约 60 秒，调高 http.timeout（如设为 600）最直接有效，同时需确保镜像源配置正确、系统时间准确及必要 PHP 扩展已启用。
Composer 在 Linux 上报 curl error 28，基本就是网络请求卡在响应阶段超时了，不是证书错、不是代理挂、也不是 DNS 彻底失败——调高 http.timeout 是最直接有效的解法。
为什么 composer install 总卡住或报 curl error 28
这个错误本质是 Composer 等待远程服务器返回包元数据（比如 Loading composer repositories with package information 阶段）时，耗时超过了内置阈值。默认值仅约 60 秒，远低于 PHP 的 default_socket_timeout（300 秒）或 cURL 自身的 CURLOPT_TIMEOUT。
常见诱因包括：
- DNS 解析慢（尤其首次访问 packagist.org 或 GitHub）
- TLS 握手延迟（国内到海外源常卡在这一环）
- 中间网络抖动导致 TCP 包重传
- 镜像源本身响应不稳定（比如未配置 HTTPS 或末尾缺
/）
注意：composer diagnose 不会暴露这个问题，它只测基础连通性，不模拟真实仓库拉取流程。
临时加参数：单次命令快速绕过
适合调试、CI 脚本或不想改配置的场景。记住两个关键点：
-
--http-timeout=600才真正控制 HTTP 请求超时（--timeout主要影响脚本执行阶段，对网络无效） - 单位是秒，600 表示 10 分钟，一般够用；若仍失败，可试 900
- 如需顺带缓解 DNS 慢，加上
--dns-cache-ttl=3600减少重复查询
示例：composer update --http-timeout=600 --dns-cache-ttl=3600
永久生效：改全局配置而非手动敲
执行以下命令写入用户级配置（别用 sudo，否则会写进 /root/.composer/config.json，Web 进程或普通用户根本读不到）：
composer config -g http.timeout 600
验证是否成功：composer config -g http.timeout 应输出 600；或直接看 ~/.composer/config.json 中是否有 "http": {"timeout": 600}。
补充建议：
- 顺手配个 GitHub Token 避免限速：
composer config -g github-oauth.github.com "your_token" - 该配置不影响
composer self-update，它走独立逻辑 - 若团队共用，建议统一执行，避免 CI 因用户上下文不同而行为漂移
比超时更关键的底层优化
光拉长超时只是兜底，真正减少 curl error 28 频次，得从链路入手：
- 必须换国内镜像源，且命令要写全：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意：键名是repo.packagist，type 是composer，URL 末尾必须有/，缺一都会静默失败） - 确认系统时间准：运行
date -u和curl -I https://packagist.org 2>/dev/null | grep Date对比，偏差超 60 秒就需修（sudo timedatectl set-ntp true） - PHP 扩展不能缺：
zip、openssl、mbstring、curl必须启用，否则可能卡在更底层，连超时都报不出来
超时值设再大，也救不了 DNS 解析失败、TLS 握手卡死、或者系统时间差七八分钟的情况——这些点容易被当成“网络问题”跳过，但恰恰是高频根因。
