net.ipv4.tcp_syn_retries 会直接影响 Linux 中 connect() 调用的最大超时时间上限。具体来看，当该参数设置为 4 时，连接超时大约为 31 秒；设置为 5 时，会延长到约 75 秒；如果提高到 6，则可能达到约 127 秒。这里有一个非常重要的细节：即使应用层已经配置了 60 秒的超时限制，内核仍然会按照这个参数提前终止连接。因此，应用超时设置与内核 TCP 参数必须配合调整，才能让连接超时机制真正符合预期。
查看 tcp_syn_retries：决定 connect() 超时的硬性上限
在 Linux 系统中，connect() 系统调用的超时时间并不完全由程序代码决定，而是会受到内核参数 tcp_syn_retries 的严格约束。这个参数表示 SYN 数据包最多允许重发的次数，因此会直接影响 TCP 建立连接时的最长等待时间。
执行以下命令即可查看当前配置值：
sysctl net.ipv4.tcp_syn_retries
输出通常类似 net.ipv4.tcp_syn_retries = 4，这意味着实际连接超时大约为 31 秒（重试间隔通常按指数方式递增，例如 1s、3s、7s、15s 后最终失败）。常见参数值与 TCP 连接超时关系如下：
4→ 约 31 秒5→ 约 75 秒6→ 约 127 秒
需要注意的是：即便你在应用层把 connect() 超时设置为 60 秒，如果系统中的该值是 4，连接仍然会在约 31 秒时被内核强制判定失败，不会等待完整的 60 秒。
查看 tcp_keepalive_*：长连接空闲时的保活探测周期
这是一组经常被误解为“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
cat /proc/sys/net/ipv4/tcp_keepalive_intvl
cat /proc/sys/net/ipv4/tcp_keepalive_probes
这些参数不会决定 connect() 的超时时间，但会影响一个处于 ESTABLISHED 状态的 TCP 长连接在空闲多久之后开始发送 keepalive 探测包、探测间隔是多少，以及连续失败多少次后关闭连接。
查看具体连接是否启用 keepalive 以及当前状态
仅仅修改内核参数并不足以让 keepalive 生效——因为大多数 socket 默认并不会开启 keepalive。要让 TCP 保活机制真正工作，必须在应用程序中显式调用 setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on)) 进行启用。
要验证某个活跃 TCP 连接是否真的开启了 keepalive，可执行：
ss -ti 'sport = :8080'
检查输出结果中是否包含 keepalive 相关信息；如果没有，说明应用层并未开启该选项，此时即使调整了 tcp_keepalive_* 参数，也不会产生实际效果。
常见误区包括：
- 只修改 sysctl 参数，却忘记在程序中调用
setsockopt(... SO_KEEPALIVE ...) - 把
tcp_keepalive_time误当成connect()超时参数来调，结果对 TCP 建连超时没有任何作用 - 使用
netstat无法准确查看 keepalive 状态，通常以ss -ti作为更可靠的排查方式
不要被 /proc/sys/net/ipv4/tcp_fin_timeout 误导
这个参数控制的是 TIME_WAIT 状态的持续时间，默认值通常为 60 秒，它和常说的“TCP 连接超时”并不是一回事。它影响的是连接关闭之后本地端口释放的速度，而不是 TCP 建连超时，也不是应用读写超时。
如果你看到有人建议通过修改它来“解决连接超时问题”，基本可以判断是概念混淆。真正会影响业务侧感知到的连接中断，绝大多数集中在以下两类场景：
connect建连阶段：重点查看tcp_syn_retries- 长连接空闲后被断开：重点查看
tcp_keepalive_*与应用层SO_KEEPALIVE是否正确配置
至于其他参数，例如 tcp_rmem/tcp_wmem 或 net.core.somaxconn，更多属于 Linux TCP 性能优化范围，并不会直接决定“连接超时”的行为表现。
