备案站点的 TCP 连接排障与内核参数调优

应用日志什么都没有，因为请求没走到应用

高峰期偶发「连接被重置」、建连时间出现 1 秒、3 秒的阶梯、客户端超时但服务端访问日志里连记录都没有——这类问题在应用层永远查不出原因，因为请求在内核的连接队列里就被丢掉了，根本没到应用。这是高并发站点最典型的一类隐形丢连接。

关键要点

• 内核里是两个队列：半连接队列和全连接队列，溢出表现完全不同，处理方式也不同。
• 全连接队列上限取「应用 listen 时传的 backlog」与「系统参数」的较小值，只改系统参数常常无效。
• TIME_WAIT 堆积在服务端通常无害，真正致命的是主动发起方的本地端口耗尽。
• 网上抄来的内核参数可能造成大面积随机失败，改参数前先看计数器增量。

两个队列，两种故障表现

队列	什么时候进入	溢出后的表现	受什么限制
半连接队列	收到 SYN、握手未完成	SYN 被丢弃，客户端按秒级退避重试，表现为建连很慢	内核的 SYN backlog 参数
全连接队列	握手已完成、等待应用 accept	按配置静默丢弃或直接回 RST，表现为偶发连接重置或超时	应用 listen backlog 与系统 somaxconn 的较小值

排查动作是看监听套接字上的队列排队数与内核的溢出计数器（「listen queue overflow」「SYN 被丢弃」这两类统计）。关键是看增量而不是绝对值：累计值从开机起就在涨，只有单位时间内的增长才说明现在正在丢连接。

全连接队列溢出的根因通常不是队列小，而是应用 accept 不过来——线程池被慢请求占满、GC 停顿、或下游拖慢了处理。这时候只调大队列相当于把排队人数变多，延迟反而更差，真正要查的是应用为什么慢，思路见 性能优化与压测；若伴随进程内存异常，见 内存泄漏与 OOM 排查。

TIME_WAIT：被误解最多的状态

主动关闭连接的一方会进入 TIME_WAIT 并保持约两倍报文最大生存时间（常见为 60 秒），目的是让迟到的报文自然消亡、并确保对端能收到最后的确认。

• 服务端有几万个 TIME_WAIT，通常无害：它只占少量内存与连接表项，不影响接受新连接。
• 真正的问题出在主动发起大量短连接的一侧：反向代理到后端、应用到数据库或第三方接口。本地可用端口是有限范围，短连接建得太快就会耗尽，表现为「无法分配请求的地址」这类错误。

对策按优先级排：

1. 改用长连接与连接池（治本）：反代到后端开启 keepalive，见 Nginx 反向代理配置；数据库侧见 数据库连接池与连接数治理。
2. 扩大本地端口范围。
3. 允许处于 TIME_WAIT 的端口被发起方复用。
4. 绝不要照抄「快速回收」类参数：它在 NAT 环境下会因为时间戳不单调而丢弃正常连接，造成同一出口下部分用户随机失败，这类参数在较新的内核里已被移除。

连接被中间设备静默断开

云负载均衡、NAT 网关、防火墙通常对空闲连接有超时（几分钟到几十分钟），超时后单方面丢弃，而且不一定通知两端。连接池里的空闲连接就此变成「已死但看起来还活着」，直到下一次使用才报出莫名的连接重置。

两条对策必须同时做：应用侧连接的最大空闲时间要短于中间设备的空闲超时；同时开启 TCP keepalive 并把默认的两小时探测间隔改成分钟级。连接最大存活时间与上层超时的配合见 超时设置与重试策略。

重传率：判断「是不是网络问题」的第一指标

现象	观察到的指标	结论
P99 抖动且出现阶梯式延迟	重传率上升	链路丢包，重传超时按指数退避
P99 抖动但重传平稳	应用耗时上升	问题在应用或下游
单连接上多个请求一起变慢	重传集中在少数连接	队头阻塞，复用同一连接的请求被拖住

重传带来的延迟是百毫秒级的阶梯而不是平滑增长，这是识别丢包最直观的特征。这些指标要长期采集而不是故障时才去看，见 可观测性建设 与 备案网站监控告警体系。

跨地域链路：窗口比带宽更常成为瓶颈

跨地域备份或数据同步跑不满带宽，多数时候不是带宽不够，而是单连接吞吐受限于窗口与往返时延的比值：往返时延越大，同样窗口下的吞吐越低。处理方向是让内核的缓冲区自动调节生效（别手工写死一个小值），或者用多连接并行传输。备份链路的规划见 数据备份与容灾。

改内核参数的纪律

• 先测量再改：没有溢出计数在涨，就不要动队列参数。
• 一次只改一个，并记录改动前的基线指标。
• 改动要持久化到配置管理，只在运行时生效的修改会在重启后悄悄丢失，见 配置与环境变量管理。
• 容器里的网络参数受命名空间与宿主机限制，容器内修改未必生效，见 容器化部署要点。
• 参数变更要有回滚方案，重要调整应先在演练中验证，见 故障演练与预案验证。

常见坑

• 只调系统参数不改应用 backlog：全连接队列上限没变，问题照旧。
• 照抄快速回收类参数：NAT 后的用户随机连不上，极难定位。
• 把 TIME_WAIT 数量当故障指标：盯错了对象，真正的端口耗尽却没监控。
• 应用空闲超时长于中间设备超时：周期性出现连接重置。
• 只看累计计数不看增量：误以为正在丢连接，或误以为一切正常。

常见问题

建连偶发很慢、耗时像阶梯一样跳，是什么原因？

典型特征是 SYN 被丢弃后按秒级退避重试。先看半连接队列与溢出计数是否在增长，同时检查链路重传率。应用日志通常完全正常，因为连接还没建立。

服务器上有几万个 TIME_WAIT，需要处理吗？

服务端的 TIME_WAIT 一般不用特别处理。需要关注的是主动发起连接的一侧是否出现本地端口不足，这才会真正导致建连失败。治本手段是改用长连接和连接池。

连接池频繁报连接被重置，怎么查？

优先怀疑中间设备的空闲超时与应用侧空闲时间不匹配。把连接的最大空闲与最大存活时间设得短于中间设备超时，并开启 keepalive，通常就能消除这类偶发错误。

内核参数需要提前做一轮优化吗？

不建议。绝大多数默认值对中小站点是合适的，盲目调整反而引入难以排查的故障。正确顺序是先采集队列溢出、重传、端口占用等指标，出现瓶颈信号再针对性调整。

资料来源

Linux 内核网络相关公开文档（监听队列、TIME_WAIT 与端口复用、TCP keepalive）、主流反向代理关于上游长连接的官方说明，以及通用的 TCP 性能排查实践资料。本文为通用运维说明，仅供参考，具体参数以实际内核版本与网络环境为准。