linux tcp连接超时需分场景处理：connect()阻塞超时应使用非阻塞socket+select/poll控制，而非修改tcp_syn_retries；空闲断连须调优tcp_keepalive_time/intvl/probes并显式启用so_keepalive；time_wait堆积应启用tcp_tw_reuse（依赖tcp_timestamps）；fin_wait2长期存在主因是应用层未close()，tcp_fin_timeout仅作兜底。
Linux TCP连接超时不是单一参数能控制的，得按场景拆开看：是建立连接慢（connect()卡住）、空闲断连、还是关闭后僵在TIME_WAIT或FIN_WAIT2？不同阶段对应不同内核参数和应用层动作，光改一个tcp_fin_timeout解决不了大部分问题。
connect()阻塞超时怎么调：别碰sysctl，用非阻塞+select/poll
默认connect()会等127秒才失败（7次SYN重试，指数退避累加），这不是sysctl能改的——它由net.ipv4.tcp_syn_retries控制，但硬调它会影响所有连接，风险高。实际应该在代码里处理：
- 把socket设为非阻塞：
fcntl(sockfd, F_SETFL, O_NONBLOCK) - 调用
connect()，立即检查返回值；若返回-1且errno == EINPROGRESS，说明正在连接 - 用
select()或poll()等待socket可写，超时时间自己定（比如5秒） - 可写后调
getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &err, &len)确认是否成功
硬改net.ipv4.tcp_syn_retries到3（即最多等15秒）虽可行，但会全局影响，比如对高延迟链路可能误判，不推荐作为首选。
空闲连接被NAT/防火墙断开：必须调keepalive三参数+应用层启用
长连接空闲几分钟后断开，99%是中间设备（家用路由器、云LB）清掉了连接表，而Linux默认2小时才发第一个keepalive探测包（tcp_keepalive_time=7200），根本来不及。
- 临时调参：
sudo sysctl -w net.ipv4.tcp_keepalive_time=300（5分钟）、net.ipv4.tcp_keepalive_intvl=30、net.ipv4.tcp_keepalive_probes=3 - 永久生效：写入
/etc/sysctl.d/99-keepalive.conf，再跑sudo sysctl --system - 关键一步：应用层必须对每个socket显式开启，否则内核根本不发探测包——
setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on)) - 验证是否生效：
ss -ti看连接输出里有没有keepalive字样
只调内核参数却不调用SO_KEEPALIVE，等于没做。
TIME_WAIT堆积太多：tcp_fin_timeout只是“新连接”的超时，老连接不会立刻消失
net.ipv4.tcp_fin_timeout设成30秒，不会让你当前屏幕上看到的几万个TIME_WAIT马上清掉——它只决定「新关闭的连接」进入TIME_WAIT后等多久释放端口。老连接仍按原来的定时器走完剩余时间。
- 真正能复用
TIME_WAIT端口的是net.ipv4.tcp_tw_reuse = 1，但它必须配合net.ipv4.tcp_timestamps = 1才有效 - 检查
tcp_timestamps是否开启：sysctl net.ipv4.tcp_timestamps输出必须是1；不是就加一行net.ipv4.tcp_timestamps = 1到sysctl配置 -
tcp_tw_reuse只对本机主动发起的连接（如curl调API、Nginx反向代理）有用，对监听端口的服务端无效 - 别碰
tcp_tw_recycle——4.12+内核已删除，旧系统上开了在NAT环境必出问题
如果服务端大量TIME_WAIT，优先检查是不是客户端不主动关连接，或者Nginx/upstream配置里没设keepalive复用。
FIN_WAIT2长期不消失：应用层没close()才是根因，调内核参数只是补救
FIN_WAIT2状态卡住，说明你已经发了FIN、收到ACK，但对方一直没回FIN。常见于服务端recv完数据后忘了close()，或客户端异常退出没发FIN。
- 内核用
tcp_fin_timeout控制这个状态的超时（默认60秒），可设小一点，比如30：echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout - 但这只是兜底——根本解法是应用层确保：收到对端EOF（
read()返回0）后立刻close()；用epoll监听到EPOLLIN且read()为0时必须释放fd - 检查泄漏：
ss -antp | grep FIN_WAIT2看对应PID，结合进程日志确认是否逻辑漏了close
内核参数能加快清理，但填不完应用层的坑；大量FIN_WAIT2基本等于代码里有socket没关。
