net.ipv4.tcp_syn_retries 决定 connect() 最大超时上限，其值为4时约31秒、5时约75秒、6时约127秒；即使应用层设60秒超时，内核仍按该参数强制终止，故需协同调优。
查 tcp_syn_retries：connect() 的硬性超时上限
Linux 中 connect() 系统调用的超时不是你代码里设多少就多少，它受内核参数 tcp_syn_retries 严格限制。这个值决定了 SYN 包最多重发几次，直接决定最大连接耗时。
运行以下命令即可查看当前值：
sysctl net.ipv4.tcp_syn_retries
输出类似 net.ipv4.tcp_syn_retries = 4，对应实际超时约 31 秒（重试间隔呈指数增长：1s、3s、7s、15s 后失败）。常见取值与超时关系如下：
-
4→ ~31 秒 -
5→ ~75 秒 -
6→ ~127 秒
注意：即使你在应用层设置 connect() 超时为 60 秒，若系统值是 4，它仍会在 ~31 秒后强制失败，不会等满 60 秒。
查 tcp_keepalive_*：长连接空闲探测周期
这是另一个常被误认为“连接超时”的参数组，但它管的是已建立连接的保活探测，不是建连阶段的超时。默认值极保守（tcp_keepalive_time=7200），容易被 NAT/防火墙提前断开。
一次性查全三个关键参数：
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes
或分别看：
cat /proc/sys/net/ipv4/tcp_keepalive_time<br>cat /proc/sys/net/ipv4/tcp_keepalive_intvl<br>cat /proc/sys/net/ipv4/tcp_keepalive_probes
它们不控制 connect 超时，但决定一个 ESTABLISHED 连接空闲多久后开始发 keepalive 探测包、间隔多长、失败几次后关闭连接。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
查具体连接是否启用 keepalive 及状态
光改内核参数没用——每个 socket 默认不开启 keepalive。必须在应用层显式调用 setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on)) 才生效。
验证某个活跃连接是否真启用了 keepalive：
ss -ti 'sport = :8080'
观察输出中是否有 keepalive 字样；没有则说明应用没开，调了 tcp_keepalive_* 也白搭。
常见坑：
- 只改 sysctl，忘了在代码里调
setsockopt(... SO_KEEPALIVE ...) - 误把
tcp_keepalive_time当作 connect 超时去调，结果对建连完全无效 - 用
netstat查不到 keepalive 状态，ss -ti才是唯一可靠方式
别被 /proc/sys/net/ipv4/tcp_fin_timeout 迷惑
这个参数控制的是 TIME_WAIT 状态的持续时间，默认 60 秒，和“连接超时”无关。它影响的是连接关闭后本地端口释放速度，不是建连或读写超时。
如果你看到有人建议改它来“解决超时”，基本是混淆了概念。真正影响业务感知的连接中断，90% 出现在：
- connect 阶段：看
tcp_syn_retries - 长连接空闲断开：看
tcp_keepalive_*+ 应用层SO_KEEPALIVE
其他如 tcp_rmem/tcp_wmem 或 net.core.somaxconn 属于性能调优范畴，不直接决定“超时”行为。
