服务器调整网络连接超时时间需分层处理：内核层（如tcp_fin_timeout、tcp_keepalive_time）、Web服务层（Nginx的client_header_timeout等）、数据库层（MySQL的wait_timeout、connect_timeout）及应用代码层（显式设置socket保活与HTTP客户端超时），各层参数独立生效，缺一不可。
服务器调整网络连接超时时间，不能只改一个参数就指望“全局生效”。不同环节的超时行为由不同层级控制：内核协议栈、应用服务（如 Nginx/Apache/Tomcat）、数据库（如 MySQL）、甚至客户端代码本身。必须按作用域分层处理，否则容易调了A却卡在B。
Linux 内核层：TCP 连接生命周期控制
这是最底层、影响所有 TCP 连接的设置，通过 sysctl 修改：
- tcp_fin_timeout = 30：TIME_WAIT 状态保持时间（秒），默认 60。短连接密集服务（如 API 网关）建议设为 25～30，加快端口回收
- tcp_tw_reuse = 1：允许将 TIME_WAIT 状态的 socket 用于新客户端连接（仅对出站连接有效），配合 fin_timeout 使用效果明显
- tcp_keepalive_time = 600：空闲连接多久发第一个保活探测包（秒），建议设为 600（10 分钟），必须小于你链路中 NAT/防火墙的空闲清理时限（通常 5–15 分钟）
- tcp_keepalive_intvl = 30 和 tcp_keepalive_probes = 3：探测间隔与失败次数，组合起来决定“多久判定断连”
修改后执行 sudo sysctl -p 生效；永久生效需写入 /etc/sysctl.conf。
Web 服务层：Nginx / Apache / Tomcat
这些是面向客户端请求的第一道网关，超时配置直接影响用户感知：
-
Nginx：在 http 或 server 块中设：
client_header_timeout 10s;
client_body_timeout 10s;
send_timeout 10s;
（分别控制请求头、请求体、响应发送的等待上限） -
Apache：在 /etc/apache2/apache2.conf 或虚拟主机配置中加：
Timeout 30（单位秒，指接收请求或发送响应的整体等待时间） -
Tomcat：编辑 conf/server.xml 中的 Connector：
connectionTimeout="30000"（毫秒，即 30 秒，建连后无数据交互的等待上限）
数据库层：MySQL 连接保活与中断控制
长连接空闲后被服务端主动断开，是常见报错“MySQL server has gone away”的主因：
- wait_timeout = 600 和 interactive_timeout = 600：服务端自动关闭非活跃连接的时间（秒），建议统一设为 600～1800，避免比应用层心跳还短
- connect_timeout = 10：握手阶段最大等待时间，不宜低于 5，也不宜高于 15
- net_read_timeout = 60、net_write_timeout = 60：大查询或慢网络下读写数据的容忍时间，可按业务场景上调
配置写入 /etc/mysql/my.cnf 的 [mysqld] 段，重启或用 SET GLOBAL 动态生效（注意权限与持久性）。
应用代码层：显式控制连接行为
内核和中间件再怎么调，若应用没启用保活或没设连接超时，照样会断：
- TCP socket 必须显式开启 SO_KEEPALIVE（如 Java 的 socket.setKeepAlive(true)），否则内核 keepalive 参数完全不触发
- HTTP 客户端（如 Go 的 http.Client、Python 的 requests）需设置 timeout：包含连接超时（connect）、读超时（read）、写超时（write）三部分，不能只设一个
- 使用连接池（如 HikariCP、Druid）时，务必配置 validationTimeout、keepaliveTime 等健康检查参数，避免拿到已失效连接
