centos 7上composer卡在resolving dependencies并报curl error 28，根本原因是内核全连接队列溢出（net.core.somaxconn=128默认值过小），导致tcp第三次ack被丢弃、连接无法建立；需同步调大somaxconn至2048、清缓存、换阿里云镜像源并验证send-q生效。
为什么CentOS 7上Composer卡在Resolving dependencies还报curl error 28
这不是 Composer 慢，是 TCP 全连接队列（accept queue）溢出后，内核丢弃了客户端的第三次 ACK，导致连接永远建不起来——Resolving dependencies卡住几十秒、curl -v https://mirrors.aliyun.com/composer/packages.json卡在 Resolving host 或直接超时，本质都是这个底层问题。CentOS 7 默认 net.core.somaxconn=128，而 Composer v2.9.6+ 并发拉包时会密集建连，极易打满队列。
怎么确认是全连接队列溢出而非DNS或TLS问题
先排除干扰，再抓真因：
- 运行
curl -I https://mirrors.aliyun.com/composer/—— 若能快速返回200 OK，说明 DNS 和 TLS 握手正常，问题不在上层 - 执行
netstat -s | grep -i "listen.*overflow"或ss -lnt | grep :443，看Recv-Q是否持续接近或等于Send-Q（比如Recv-Q: 127 Send-Q: 128） - 检查溢出计数：
cat /proc/net/netstat | grep -i "ListenOverflows\|ListenDrops"，若数值随 Composer 执行明显上涨，就是它 -
sysctl net.core.somaxconn输出仍是128？那基本坐实——旧内核默认值太小，且 Composer 不会主动调大它
如何安全调大全连接队列并让Composer生效
必须同时改内核参数和应用行为，单边无效：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 临时生效（立刻见效）：
sudo sysctl -w net.core.somaxconn=2048；永久写入：echo "net.core.somaxconn = 2048" | sudo tee -a /etc/sysctl.conf && sudo sysctl -p - 重启 PHP-FPM 或 Apache 无用——Composer 是 CLI 进程，只依赖系统级
somaxconn，不走 Web 服务队列 - 别碰
tcp_max_syn_backlog：半连接队列在此场景极少溢出，强行调高反而可能引发 SYN flood 误判 - 验证是否生效：
ss -lnt | grep :443的Send-Q应变为2048；再跑composer clear-cache && composer install -vvv，看是否跳过长时间卡顿 - 如果仍卡在 TLS 握手（如报
error:14090086），那是证书链或时间不同步问题，跟队列无关，需单独查date和openssl s_client -connect mirrors.aliyun.com:443 -servername mirrors.aliyun.com
为什么调大somaxconn后还要清缓存和换镜像
队列只是通道，镜像才是源头。CentOS 7 常见组合陷阱：
-
composer config -g repos.packagist.org.url必须输出https://mirrors.aliyun.com/composer/，不是packagist.org或已停用的phpcomposer.com - 换源后不执行
composer clear-cache，Composer 仍会从本地缓存读取旧的 packagist.org 元数据，继续走海外链路，队列再大也白搭 - 老旧服务器常禁用 IPv6，但某些镜像 CDN 优先回 IPv6 地址，导致
dig mirrors.aliyun.com返回空或超慢——可加+short A强制查 A 记录，或直接绑/etc/hosts - PHP CLI 的
default_socket_timeout（ini 中值）若设为 60，即使你配了http.timeout=600，底层 socket 仍会在 60 秒强制断开，需同步检查php -i | grep default_socket_timeout
全连接队列溢出没有错误日志，不会报错，只会静默丢包。CentOS 7 上看到 Resolving dependencies 卡住又没其他线索，第一反应就该查 ListenOverflows——不是 Composer 配置问题，是内核网络栈在说“我接不住了”。
