故障背景与现象还原
在某中型企业的ERP系统日常巡检中，IT运维团队接到大量终端用户的反馈：在使用浏览器访问内部OA审批模块时，经常遇到页面加载缓慢，甚至在提交表单时出现“连接重置”或“502 Bad Gateway”错误。值得注意的是，这种故障并非持续发生，而是呈现明显的间歇性特征——通常在上午10点至11点，以及下午2点至3点等业务高峰期高发，而在夜间或非工作时间则完全正常。
初步排查显示，应用服务器CPU和内存负载均在正常范围内，数据库响应时间也未见明显异常。由于错误表现为HTTP层的连接中断，且仅部分用户受影响，运维团队首先怀疑是负载均衡器（LB）或反向代理层的配置问题，但检查其日志并未发现明显的上游服务器宕机记录。这促使我们将排查重点转向网络链路层，特别是TCP连接的稳定性。
第一步：现场复现与基础连通性测试
为了确认故障范围，我们选取了两台表现截然不同的客户端进行对比测试。一台处于故障频发时段且报错的用户PC，另一台在同一网络环境下但偶尔能正常访问的备用PC。
使用 ping 命令测试应用服务器网关，两台机器均显示延迟正常，无丢包。随后使用 telnet <server_ip> <port> 测试TCP端口连通性，结果均能成功建立连接。这表明基础的IP路由和端口监听是正常的，问题可能出在应用交互过程中的状态保持上。
第二步：深度流量分析——锁定TCP异常
鉴于HTTP超时的复杂性，我们决定在故障高发时段，在核心交换机镜像端口部署Wireshark进行抓包分析。通过过滤HTTP请求，我们捕捉到了关键的异常数据包序列：
- FIN/RST风暴：在看似空闲的连接中，客户端频繁收到来自中间设备的RST（重置）包，而非预期的FIN（结束）包。这意味着连接是被强制切断的，而非优雅关闭。
- Keepalive缺失：观察TCP首部选项，发现客户端发出的HTTP请求中虽然设置了
Keep-Alive头部，但在长时间无数据传输后，并没有看到客户端发送的TCP Keepalive探测报文，或者这些探测报文被中间设备丢弃。 - 时间窗口差异：故障发生的连接，其存活时间大多在300秒至600秒之间，这与某款主流防火墙的默认TCP会话超时时间高度吻合。
技术分析：许多企业级防火墙或硬件负载均衡器会维护一张NAT会话表或连接跟踪表。如果一条TCP连接在一段时间内没有数据传输，防火墙可能会认为该连接已失效并回收相关资源。然而，应用层（如Java后端或前端JS）可能仍认为连接有效，继续复用该TCP连接发送数据。当数据到达防火墙时，由于会话表项已不存在，防火墙直接丢弃数据包并返回RST，导致客户端看到“连接重置”错误。
第三步：根因确认——防火墙策略与TCP Keepalive的冲突
经与网络工程师协作，查阅核心防火墙上配置，发现以下两个关键因素共同导致了此次故障：
- TCP会话超时时间过短：防火墙对静态TCP连接的超时时间设置为300秒。对于高频短事务（如Web点击）尚可接受，但对于ERP系统中复杂的批量数据处理，用户在前端填写表单的时间往往超过300秒，导致连接在后台静默断开。
- 应用层未正确实现心跳检测：后端Java应用在配置Tomcat连接器时，未开启TCP Keepalive，且业务代码中缺乏有效的空闲连接检测机制。当浏览器尝试复用已经由防火墙断开的TCP连接时，必然失败。
第四步：解决方案与实施步骤
针对上述根因，我们制定了“网络侧调整+应用侧优化”的双管齐下修复方案。
1. 网络侧优化：延长TCP会话超时与启用Keepalive
登录防火墙管理界面，执行以下操作：
- 调整超时策略：将针对内部Web服务器网段的TCP连接超时时间从默认的300秒调整为1800秒（30分钟）。此操作需评估NAT表容量，确保不会耗尽会话资源。
- 启用探测报文：在防火墙策略中开启TCP Keepalive探测功能。配置为每60秒发送一次探测报文，若连续3次无响应则判定连接断开。这样可以确保防火墙知道哪些连接是真正活跃的，从而避免过早回收空闲但未断开的连接。
2. 应用侧优化：增强连接健壮性
协同开发团队对ERP系统进行以下代码级修改：
- 配置Tomcat Keepalive：在
server.xml的Connector节点中，显式设置keepAliveTimeout="15000"和maxKeepAliveRequests="100"。这将告诉底层OS和防火墙，该连接需要维持活跃状态，并定期发送TCP层的心跳包。 - 前端重试机制：在前端JavaScript中引入指数退避重试算法。当捕获到HTTP 502或连接重置错误时，不直接弹窗报错，而是静默重试1-2次。这对于处理短暂的中间设备抖动非常有效。
第五步：验证与监控
方案实施后，我们进行了为期一周的压力测试和日常监控：
- 回归测试：模拟用户在ERP系统中停留5分钟以上再进行提交操作，Wireshark抓包显示TCP连接始终保持ESTABLISHED状态，未出现RST包，页面加载成功率达到100%。
- 实时监控：在Prometheus+Grafana监控面板中，添加了“TCP重传率”和“连接超时数”指标。数据显示，实施后这两项指标下降了95%以上。
总结与建议
本案例表明，内网应用出现的“间歇性超时”往往不是单一维度的故障，而是网络架构、安全策略与应用逻辑相互作用的结果。在处理此类问题时，切忌仅盯着应用日志看。通过引入数据包级别的深度分析（如Wireshark），结合对中间网络设备（防火墙、负载均衡）行为模式的理解，才能精准定位根因。
对于中小企业IT人员，建议在日常运维中遵循以下原则：
- 建立基线：了解正常情况下的TCP连接行为，才能敏锐识别异常。
- 关注中间件配置：不要忽略操作系统内核参数（如
net.ipv4.tcp_keepalive_time）和安全设备策略对长连接的影响。 - 端到端排查：从用户浏览器到后端数据库，逐层排除，利用工具将黑盒变为透明。