新手配置服务器网络超时参数的核心是平衡连接稳定性与资源效率，需厘清connectTimeout、readTimeout、wait_timeout职责，主动探测死链，科学设定连接池大小，并协同调优Linux内核参数。
新手配置服务器网络超时参数，核心目标不是“调得越严越好”，而是让连接既不僵死、也不过早中断，同时为死链清理和连接池健康留出合理窗口。重点不在堆参数，而在理清逻辑关系和常见误操作。
一、先搞懂三个关键超时时间分别管什么
很多新手把 connectTimeout、readTimeout、wait_timeout 混为一谈，结果调了也没用：
- connectTimeout（连接建立超时）：只控制客户端发起 TCP 握手到完成的耗时。设太短（如 500ms）会误杀正常慢网环境；设太长（如 30s）会让故障节点长期拖住线程。生产建议值：2–3 秒。
- socketTimeout / readTimeout（读取超时）：控制从服务端开始发数据后，客户端等待响应体的最大时间。它不包含连接建立，只管“等数据”。业务简单可设 10–30 秒；含复杂计算或外部依赖的接口，建议按 P95 响应时间上浮 20% 设置。
- wait_timeout（MySQL 空闲连接超时）：这是数据库侧参数，决定空闲连接在服务端保留多久后被自动断开。必须和应用层连接池的 idleTimeout 配合设置——通常 wait_timeout 应 > 连接池最大空闲时间，否则连接会被 MySQL 主动 kill，导致下次获取时抛异常。
二、死链清理不能靠“等超时”，要主动探测
超时只是兜底，真正的死链（比如中间网络断开但 TCP 连接未 FIN）靠被动等待 timeout 往往要几十秒，严重影响连接复用。正确做法是启用连接有效性验证：
- 在连接池（如 HikariCP、Druid）中开启 validationQuery（例如
SELECT 1）并设置 testOnBorrow 或更推荐的 testWhileIdle； - 配合 timeBetweenEvictionRunsMillis（如 30000，即每 30 秒扫描一次空闲连接）；
- 避免用 ping 或复杂 SQL 做检测，轻量、无副作用、数据库原生支持的语句最稳妥。
三、连接池大小不是拍脑袋定的，要匹配真实负载
新手最容易犯的错：看到报错 “Cannot get JDBC connection” 就猛加 maxPoolSize，结果压垮数据库。其实应分两步看：
- 看应用并发压力：估算 QPS × 平均连接占用时长（单位：秒）。例如 200 QPS × 0.2 秒 = 40，那理论最小连接池大小约 40～60（留缓冲）；
-
看数据库承载能力：MySQL 默认 max_connections=151，实际可用连接数 ≈ max_connections − 后台线程 − 管理连接。若应用池设 200，但 DB 只允许 100 并发，必然排队或拒绝。务必同步检查并调整 DB 的
max_connections和wait_timeout； - 连接池初始大小（minimumIdle）建议设为最大值的 30%～50%，避免冷启动时频繁创建连接。
四、Linux 系统层也要配合调，不然应用层调了也白搭
当大量短连接反复建立/关闭，系统内核的 TIME_WAIT 连接堆积会吃掉端口资源，间接导致 new connection timeout。需确认并调整：
-
net.ipv4.tcp_fin_timeout：默认 60 秒，可降至 30； -
net.ipv4.ip_local_port_range：确保范围足够宽（如1024 65535），避免端口耗尽； -
net.ipv4.tcp_tw_reuse：设为 1，允许 TIME_WAIT 套接字重用于新 outgoing 连接（客户端场景有效）； - 注意：
tcp_tw_recycle已废弃且在 NAT 环境下危险，切勿开启。
