服务器TIME_WAIT堆积怎么查

业务明明没涨流量，机器却开始出现连不上、偶尔超时、新建连接失败，登上去一看连接状态里密密麻麻全是 TIME_WAIT。这个状态既不是错误也不是故障，它只是正常的连接关闭流程，但数量堆到一定程度，端口就真的不够用了。这篇从怎么判断是不是它的问题讲起，把内核参数怎么调、长短连接怎么选、端口不够时怎么绕开讲清楚，结尾附一份上线后该盯的指标清单。

TIME_WAIT 堆起来是什么感觉

最直观的表现是新建连接偶发失败，报错里能看到地址已被占用或者无法分配端口。刷新几次又好了，隔一阵又冒出来，用压测工具跑能复现，正常访问又看不出异常。这类偶发性故障最难复现，抓不到包就只能靠猜。

第二个表现是延迟抖动。连接建立阶段多了几百毫秒的等待，应用层的监控看不出来，抓包才能看到握手阶段的空档。这种抖动在接口调用链路里会被放大，一次请求串了几十个下游，累计起来就很明显，用户端的感受是整页加载变慢，很难归因到某一次请求。

第三个表现是监控图上的曲线形状。并发连接数没涨，但本地端口占用数一路向上，两者背离就是这个状态的典型特征。只看并发连接数的话，很容易得出一切正常的结论，把两个指标画在同一张图上才有意义。

有些业务会先出现日志里的连接超时告警，然后才轮到用户端感知。这类告警往往被当成下游服务的问题，排查了一圈才发现问题在自己的端口池上，白折腾一圈，把真正的问题拖得更久。

判断其实不难，一条命令把各状态的连接数统计出来，看 TIME_WAIT 占总连接的比例。超过一半就该处理，长期维持在七成以上基本可以确认是这里的问题，跑业务量大的机器尤其容易出现，用云途这类香港独服承载接口服务时更值得纳入日常巡检。

先分清是本地还是对端

统计的时候要分两个方向看：本机作为客户端主动关闭的，TIME_WAIT 落在本机；本机作为服务端被客户端关闭的，TIME_WAIT 落在对端。这一点决定了优化手段该往哪边使，搞反了调参数只会白忙，甚至越调越糟。判断方向这件事五分钟就能做完，却省掉几天的试错。方向定错的时候，参数调得越勤，问题暴露得越晚，等到用户开始投诉才知道，代价已经翻了几倍。方向判断本身很简单，难的是有人愿意先花五分钟去看一眼，而不是直接上手改参数。判断错了方向，后面每一步都是在给错误答案加细节。

抓一下连接四元组就能分辨。本地端口是随机高端口的，说明是主动发起方；本地端口是监听端口、远端端口随机的，说明是被动关闭方。两种情况的处理思路完全不同。前者要减连接次数，后者要检查对端为什么频繁断开，可能对方的超时设得太短，也可能中间设备主动掐了空闲连接。这条线索指向的往往是网络侧策略，跟应用代码无关，改代码是白费力气，要去找网络那边对一下策略，顺手把双方的空闲超时值对齐。

短连接密集的调用最容易堆这个状态。每一次请求都新建一条 TCP，请求完就断开，关闭动作由客户端发起，于是客户端的端口表被迅速填满。这种模式在内部服务互调里非常普遍。

内核参数怎么调才不越界

允许重用处于等待状态的连接，是最常被提到的一项。打开之后，新的连接可以复用还在等待的端口组合，端口压力会明显缓解，但前提是时间戳选项正常工作，否则有极小概率收到旧连接的数据。

缩短等待时长是另一条路。默认值偏保守，把它压到几十秒可以加快端口回收，代价是极端情况下旧连接的残余数据可能被误认。改动幅度要克制，别一步调到极限。

本地端口的可用范围值得扩一下。默认区间在高峰期确实不够用，扩到几万条能顶一阵，但扩完要确认防火墙和中间设备的规则没有跟着误伤。

连接队列的长度要和业务量匹配。队列太短，突发流量会直接被丢弃；队列太长，握手阶段的等待时间会悄悄上升，用户以为是服务慢，其实是排在了队列里。

有些参数不适合随手改。调整系统的文件句柄上限、调整内存相关的缓冲，这些要跟实际内存和业务模型对上，抄一份别人的配置往往适得其反。

改动之前先记录基线。每个参数调完观察一天，看端口占用曲线和错误率有没有改善，一次改五六项的话，出了问题根本判断不出是哪一项导致的。

灰度是必须的。选一台非核心机器先跑，确认业务没有异常再推到其余机器，用配置管理工具统一下发，避免挨台登录。

要留回退开关。参数写进配置文件、纳入版本管理，出事的时候一条命令切回旧值，比现场手改要快得多，这类配置比较规整的香港独服在批量下发参数时更省事。

长连接和短连接怎么选

内部服务之间的高频调用，长连接几乎是唯一正确的选择。建立一条连接反复使用，端口不会快速消耗，握手开销也省了。代价是要处理连接复用、超时重连、空闲回收这些细节，工程量不小，收益也最大。改造完成之后端口占用曲线会明显平缓下来。

对外提供 HTTP 接口的场景，保持连接是标配。客户端和服务端协商复用同一条连接，短时间内的多次请求共享端口，压力自然就下来了。协议层面的开关记得打开，别靠代码里手动管理。

数据库连接池的配置要跟服务端的上限对齐。客户端开了一百条连接，服务端只允许五十条，多出来的会排队甚至被拒，表现出来又是一堆超时。

长连接不是万能药。连接长期占用不释放，服务端的内存会被逐渐吃满，重启一次才恢复正常。空闲超时和最大生命周期这两项一定要设，别指望客户端自觉，一套代码几十个调用点，总有一处会漏掉关闭逻辑。

有些场景确实适合短连接，比如低频的定时任务、偶发的管理请求。这类业务量小，堆不出问题，为了它们去改造连接池反而增加复杂度。

判断标准说到底是频率。每秒几十次以上的调用走长连接，每分钟几次的走短连接，夹在中间的看实际测试结果。这条线不是拍脑袋定的，压测一遍就有答案，偏中低配的机型也能扛住改建连池之后的负载。

端口不够用的时候怎么办

短期缓解的办法是加机器。把客户端角色拆到多台机器上，每台的端口池独立，压力自然分散。这种方式见效快，成本也直观。适合短期救火，长期看还是要把连接次数降下来，不然加机器的成本会一直往上涨，账单上看不出，年底一算就很明显。能靠改代码省下的机器，比靠加机器扛住的方案划算得多。

把客户端和服务端放在不同机器上，也是一种思路。同一台机器上既当客户端又当服务端，端口池是共享的，拆开之后两边互不干扰。部署上多一层规划，好处是排查问题时边界清晰，坏处是多了一层网络规划，机器一多管理成本也上来了，多少台机器拆成两组，得提前定个界限，别拍脑袋临时分，分完之后两边的监控要各自独立，不然一端出问题会把另一端也拖进来，边界划清楚了反而好排查。

改用 Unix 域套接字可以彻底绕开端口限制。同机进程之间的通信走本地文件描述符，不占端口，延迟也更低，只是跨机器就没法用了。

长期方案还是从架构上减少连接数。把多个小请求合并成批量调用，把轮询改成推送，把同步调用改成异步，这些改动带来的收益比调参数更持久，也更不容易引起副作用。架构层面的减法，效果通常比参数层面的加法更持久，参数会随版本升级被覆盖，架构改动不会。这也意味着参数优化要写进部署检查项里。

上线后盯哪几项

盯各状态连接数的分布，重点看等待状态占比，超过一半就要预警，预警阈值建议设成基线的两倍，超过就当成一次小型告警来对待，别等它翻倍才反应。阈值定好之后要让值班的人知道超了该找谁。

盯本地端口占用率，接近上限之前就该扩容或者改架构，别等到连不上才开始动手，那时候已经在影响用户了，提前一天的扩容窗口要留出来，临时加机器来不及走流程。

盯新建连接的失败率，这一项最能反映用户侧真实感受，比内部指标更值得放在最显眼的位置，它直接对应着能不能正常访问。

盯连接建立的耗时，握手阶段的延迟上涨往往先于错误出现，属于早期信号，连续几小时缓慢上涨比一次尖峰更值得警惕，尖峰会回落，缓涨不会。

盯连接池的等待队列长度，队列长期非空说明配置偏紧，加大池子或者缩短占用时间都能缓解，前者治标后者治本。两条一起做，效果比单做任何一条都稳。

盯参数改动的生效范围，确认所有机器都下发了同一份配置，漏掉一台就可能在那台上复现同样的故障，配置核查要当成发布流程的一环，不核查就不算发完。

把这几个指标放进同一块看板，出问题的时候一眼就能定位到是端口、是配置还是业务量。指标不用多，能回答\"现在卡在哪\"就够。看板做出来之后记得定期复盘，别等出事才第一次打开。