问题背景
线上服务告警，报请求外部服务 EOF 错误。告警持续约10几分钟恢复正常。 我们业务依赖很多第三方服务，看到该告警，第一时间拉起了第三方服务的研发排查，但因为使用的是第三方服务提供的 sdk，请求成功前默认不会记录有请求 id 来帮助定位，对方一时也无从下手，同时也没有其他客户反馈该问题，建议我们先复现。
问题排查过程
阶段一
查资料得知 EOF出现的直接原因就是读一个已经关闭的 TCP 连接。
网上有相似的问题，在高并发场景下，长连接复用时，可能会遇到对方服务主动关闭链接时，客户端还在读该链接则报 EOF。
另外，据有相关经验的同事提到，他有其他服务遇到过相似问题，改用短链接就好了。
服务本身虽然会有一定的并发，但应该不至于高到这个程度，但服务本身对短链接这点性能消耗是可以接受的，先改成短链接跑一段时间。
阶段二
服务安然跑了两周，就在以为问题解决的时候，又冒出了告警，持续了一小会。
迅速打开容器和主机的网络监控面板，没有发现异常情况，NAT 网关虽然流量有升高，但是购买的性能应该是远能满足。这就非常让人摸不着头脑了。
手上信息不足，无头绪。但看监控可以排除容器和主机的网络问题。问题可能出在我方网关或者对方网关上。于是，向第三方服务方求证是否对客户端 ip 进行了限制，得到了否定的答复。那就只好先行抓包，等下一次现场出现。同时，在另外的不共用 NAT 网关的环境跑一些拨测脚本，设置该对照组进一步缩小问题范围。
阶段三
没过两天，终于等来了现场。
观察抓包数据，发现好些个发往第三方的请求一直没有收到回包导致一直重传，最后收到第三方服务的 fin 包。这个就是 EOF 的直接原因了。但不是高并发引起，而是在包重传了一分钟后被断开。
紧接着在有问题的容器中 curl 第三方服务，出现等待很久的现象，再尝试 curl 其他外网服务，有时成功，有时也会等待。此时其他对照组本身没有遇到该问题。那是不是出在 NAT 网关上？
NAT 网关的情况和上次差不多，出入流量和连接数在上升，但在性能允许范围内。奇怪了。
会引起出入带宽明显上升的情况应该挺特殊，了解确认后得知是一个上传下载的功能引起。立马通过日志确认 EOF 时间点是否使用了该功能。发现确实有相关性，每次 EOF 时都有东西在上传下载。网关的监控数据表明出现明显波动。
当前的重点是恢复核心业务，立马和产品沟通，暂时下架该功能。然后问题恢复，告警群回归正常。
阶段四
虽然解决了EOF问题，但是网关的问题得深究，明明性能配置都远没达到 NAT 网关的瓶颈，为何会出现丢包的情况。而且观察监控数据，流量一直跑在低点，即使在上传下载文件，也没有突增到很高。和 NAT 网关的同学的沟通后得知，有新特性做了灰度，对于某类用户，NAT 网关关联的EIP 默认带宽为 1M, 以前是没有这个限制的，后续已将默认值调大至 5G。后续我们也作了调整，将占带宽功能的出入口与业务的网关分隔开，以免业务受影响。
结论
NAT 网关 EIP 带宽过低，在超过 EIP 的带宽后会出现丢包。第三方服务在我方发出请求后一分钟没有收到后续请求，主动断开了连接，导致我方报 EOF。查以往 EOF 的日志也确认了这一点，都是在发请求后一分钟开始报错。