AWS网络负载均衡器：客户端重置计数是什么？为何数值偏高？

核心指标定义 #

先明确这三个指标的核心都是统计RST数据包的数量——而RST包的作用就是主动中断TCP连接：

• TCP_Client_Reset_Count：统计从客户端发送到ELB的RST包数量
• TCP_Target_Reset_Count：统计从后端目标服务器发送到ELB的RST包数量
• TCP_ELB_Reset_Count：统计ELB主动发起的RST包数量

针对你的场景拆解 #

你提到负载均衡器有一个长期稳定的客户端连接，但每小时出现约100次客户端重置、10次ELB重置，目标端重置为0，这里可以从几个方向拆解可能的原因：

1. 客户端侧的“隐性”中断触发 #

虽然你觉得连接看起来正常，但每小时100次客户端发起的RST，大概率是客户端在某些场景下主动发送了RST包：

• 客户端TCP栈配置了较短的空闲超时，在连接间歇性空闲时主动发送RST中断
• 客户端进程内部的逻辑触发，比如重试机制、资源回收流程中误发了RST
• 客户端网络层面的波动，比如NAT设备的会话超时，导致客户端侧判定连接失效而发送RST

2. ELB发起重置的可能原因 #

ELB每小时发10次RST，结合目标端重置为0，说明ELB不是因为后端返回RST才转发，而是自身主动触发：

• ELB的空闲连接超时配置：如果ELB设置的空闲超时比客户端或后端短，当连接空闲达到ELB阈值时，ELB会主动发送RST中断连接
• 客户端RST引发的ELB后续动作：比如客户端发送RST后，ELB可能会向客户端/后端发送RST来彻底终止连接会话
• ELB的连接表维护逻辑：比如ELB在清理“疑似失效”连接时触发了RST（但你的是单一长期连接，这个可能性较低）

3. 目标端重置为0的含义 #

这说明后端服务器从来没有主动发送过RST包，意味着后端一直认为连接状态正常，没有触发自身的TCP中断逻辑，问题完全集中在客户端与ELB的交互环节。

排查建议 #

• 抓包分析：在客户端与ELB之间抓包，确认RST包的触发时机（比如是否在特定请求后、空闲一段时间后出现）
• 核对超时配置：对比客户端、ELB的空闲连接超时设置，排查是否存在配置不匹配的情况
• 检查客户端日志：查看客户端进程的内部日志，寻找连接中断、资源回收相关的记录

内容的提问来源于stack exchange，提问作者Aleksandr Dubinsky