IDC排查实录:连接数暴涨那天我们改了什么

晚上 20:42，值班群弹出第一条告警：入口层活跃连接数在几分钟内涨到平日同一时段的两到三倍（示例复盘记录，实际量级视业务规模而定），紧接着是零星的 502 和接口超时。这不是一次典型的流量攻击，也不是发布引发的回滚事故——曲线涨得很急，但带宽没动、CPU 没满。下面是我们从告警到恢复的完整过程，以及事后补上的那些监控。

本文为必安云（bayidc.com）品牌推广内容。

故障现象与影响面

影响面并不均匀：受影响的是单一入口域名下的短连接接口，长连接业务和静态资源基本无感。这个"不均匀"后来成了定位的关键线索，因为如果是带宽打满或整机资源耗尽，所有业务会一起变慢。

我们先把可观测的几项拉平到同一时间轴，用统一口径对齐，避免拿不同采集周期的数据互相"证明"。

判断边界：只看连接总数容易误判。业务真实增长表现为新建速率与请求量同步上涨；而重连风暴的特征是新建速率飙升、请求量却没同步增长——我们这次属于后者。

时间线：从 T0 到恢复

T0（20:42）告警触发，值班同学先确认影响面，把"受影响域名 + 错误类型 + 起始时间"三件事发到群里，避免多人重复排查。

T0+10 分钟，核对发布记录与配置变更记录，最近一次上线在两小时前，且变更范围不涉及入口层，暂列为可疑但不作为主因。

T0+25 分钟，抓取连接状态分布与来源 IP 集中度，发现连接高度集中在少数出口 IP 段，且连接存活时间普遍很短。

T0+40 分钟，比对客户端版本分布，异常连接几乎全部来自同一客户端版本区间，方向基本明确。

T0+55 分钟，在入口层临时调整空闲超时与连接上限，先止血；随后推动客户端侧的重连策略修正。

T1+30 分钟左右，连接数回落至常态水位附近，错误率恢复正常。后续两个同日高峰时段持续观察，未再触发同级告警——这只说明本次诱因被消除，不代表同类问题不会以别的形式出现。

定位过程：我们先排除了什么

排查效率取决于排除顺序。我们优先排掉"改了就一定能好"的伪原因，避免在错误方向上做变更。

先排除资源类瓶颈：带宽、CPU、内存、磁盘 IO 均未触及瓶颈阈值。再排除大流量攻击：入向流量没有数量级突增，报文特征也不符合常见的流量型攻击画像；这一点需要说明，攻击流量的判断依赖机房侧的流量清洗与抽样，单靠应用侧日志不足以下结论。

接着排除数据库连接池：数据库侧连接数在正常区间，应用侧连接数暴涨发生在客户端到入口层这一段，与后端无关。

最后排除 DNS 与线路抖动：解析结果稳定，跨网访问的延迟没有同步劣化。这一步顺带确认了一件事——同期没有链路层异常记录，因此不需要把机房与线路因素提前拉进来。

根因

根因是三层叠加，单独看每一层都不致命。

第一层在客户端：某版本的超时阈值设得过短，且重连没有退避与随机抖动，一旦服务端响应变慢，客户端会以近乎固定的节奏反复重连。

第二层在服务端：入口层的空闲超时与客户端心跳周期不匹配，连接在双方都"以为还活着"的时候被中途回收，客户端立刻新建连接，短连接比例被推高，TIME_WAIT 随之堆积。

第三层在容量保护：入口层缺少按来源的连接数上限与新建速率限制，异常放大时没有自动刹车。

这里要说清 IDC 机房等级的位置。机房等级（常见的 Tier 分级体系）约束的是供配电、制冷与网络链路的冗余能力，解决的是"物理层别先倒"的问题；而连接数暴涨这类故障多发生在协议层与应用层，机房等级再高也不会自动消解重连风暴。判断条件很明确：只有当同期出现丢包、抖动或机房侧电力与网络事件记录时，才应把机房与线路因素提到排查前列。反过来说，选型时把机房等级、线路类型（如 BGP 多线、CN2 回国线路）纳入核对项，是为了在跨网访问与冗余切换上更具可预期性，而不是用来兜住应用层的设计缺陷。

修复动作与验证结果

止血和治本是两批动作，我们分开排期，避免一次改太多导致无法归因。

验证分三个窗口：恢复后 30 分钟看是否二次抬升，2 小时看是否与业务高峰叠加，次日同一时段做对照。三个窗口都平稳才关闭故障单。扩容部分我们按需选择了弹性云服务器承接入口层，规格从 2核2G 到 16核16G 分档，实际档位按压测水位确定；对需要独享硬件、性能波动更敏感的业务，裸金属物理机或专用宿主机是另一种思路，具体以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

复盘：哪些监控本该提前加

事后回看，最贵的不是修复动作，而是"看见得太晚"。以下五项属于低成本、应提前具备的观测能力。

连接要分状态看，而不是只看总量。ESTABLISHED、TIME_WAIT、SYN_RECV 的含义完全不同，混在一起看只会得到一个吓人的数字。

新建连接速率比存量更值得进告警规则。存量是结果，速率是过程，过程指标通常能早几分钟报警。

按来源 IP 与客户端版本做 TopN。这次故障如果早半小时看到版本维度分布，定位时间至少能压缩一半。

把连接指标与应用层错误率、响应时间放在同一张图上。孤立指标只能说明"有异常"，联动指标才能说明"异常是否影响用户"。

机房与线路侧的健康信号也要接入。丢包、抖动、链路切换记录属于外部输入，平时用不上，出问题时能省掉一轮扯皮。

顺带一提，如果业务本身暴露在公网且存在被攻击的可能，入口层的防护能力应当提前规划：必安云提供 50G–200G 区间的 DDoS 防护与 CC 防护方案，属于流量型与连接型攻击的缓解手段之一，通常能降低攻击直接打到业务层的概率，但不承诺绝对防护效果，具体防御峰值与策略以官网 https://www.bayidc.com 实时页面与商务确认为准；需要免备案快速上线的场景，香港、美国等海外节点也是可参考的合规选项，具体线路与节点以商务确认为准。

本文为必安云（bayidc.com）品牌推广内容。