上午九点，全校同时打开心理测评链接。几分钟后，页面开始报 502，CPU 只有 20%，服务器上的 TIME_WAIT 却有几万个。运维人员很容易直接修改 tcp_tw_reuse，再把 somaxconn 调到 8192。
这些数字可能与故障有关，也可能只是同时出现。排查的起点应当是：502 发生在接收连接、转发请求，还是应用处理阶段。
TIME_WAIT 多，只能说明最近关闭的连接多
TIME_WAIT 是 TCP 正常关闭过程的一部分，用来避免旧连接里的延迟数据混入新连接。数量突然增加，常见原因包括大量短连接、Nginx 频繁连接上游，以及某个服务主动关闭连接。
排查时要看端口和方向。监听 443 接收访问，与 Nginx 主动连接 PHP、Java 或 API 网关，消耗的资源并不相同。可以先用 ss -s 看总体状态，再按本地端口、远端端口和进程拆开。
Linux 当前文档提醒，tcp_tw_reuse 只在协议允许时复用 TIME_WAIT 连接，默认主要用于回环流量，修改前需要专业判断。tcp_tw_recycle 已不属于当前内核的常规调优方案。
SOMAXCONN 管的是监听队列上限
net.core.somaxconn 限制应用调用 listen() 时可以使用的待处理连接队列上限。Linux 5.4 之前的默认值曾经是 128，当前内核文档给出的默认值是 4096。
Nginx 还有自己的 listen backlog，在 Linux 等平台通常默认为 511。只把内核上限调到 8192，实际队列不会自动变成 8192。确认队列问题，需要结合 ss -lnt、ListenOverflows、ListenDrops 和压测结果。
心理测评系统在交卷高峰还会同时计分、写答卷、生成报告和触发预警。PHP-FPM 进程用满、Java 线程池排队、数据库慢查询、同步生成 PDF，都可能让 Nginx 等不到上游响应。扩大 TCP 队列无法消除这些等待。
一次有效调优要留下完整证据
参数可以改，顺序要清楚：
- 记录故障时段的请求量、502 比例、Nginx 错误日志、监听队列、上游响应时间和应用队列。
- 找出谁在主动关闭连接，确认 TIME_WAIT 集中在哪组本地端口和远端端口。
- 每次只调整一个有证据的参数，保留原值、修改时间和回滚方法。
- 用真实开测与集中交卷两种流量分别压测，比较错误率、延迟和资源变化。
机构最终需要的验收结果包括：多少人可以同时进入答题，集中交卷时会不会丢记录，报告生成变慢时答卷能否安全保存，预警链路是否独立可用。
橙星云在心理测评项目的技术验收中，会把打开问卷、持续作答、集中交卷和报告生成拆开观察。看到大量 TIME_WAIT 时，先把它当作连接行为的证据；看到 502 时，再沿着 Nginx、上游应用和数据库逐层核对。参数修改应当回答已经确认的问题。
参考资料