我们的设置如下：VPC（约30-50 ec2实例） - > EC2 Nat实例 - > Internet。
自12月13日以来，我们一直在看到连接随机开始拒绝的问题。之前没有看到这样的问题。只有改变是通过API处理网址已经增加（换句话说，更多的TCP连接正在启动和处理）。从VPC内的EC2实例通过NAT实例向Internet请求API请求（POST / GET / PUT无关紧要）随机失败。
我尝试记录Flow日志，但是在这些流日志中，我看到了TCP日志传输显示ACCEPT OK的条目（附图片 - https://ibb.co/dwe3X6）。但是，tcpdump（vpc中的一个特定ec2实例）上的相同捕获显示TCP重传失败（流量通过NAT实例）（图片附加 - https://ibb.co/npqozm）。它们是同一时间和相同的ec2实例。
基本上，SYN数据包被启动，但实际的握手不会通过。请注意，这不会一直发生。
tcp重传失败是随机的。有时它会起作用，有时则不起作用。所以这让我相信NAT实例中有某种队列或缓冲区达到了极限，我不知道如何找到它的根。
这表明互联网或远端存在问题。
ACCEPT表示安全组和网络ACL允许连接（流的实例），不会告诉您握手是否成功。流日志中的OK表示日志条目本身是完整的。
没有理由相信NAT实例限制了这一点，因为SYN数据包确实显示在wireshark中，离开实例前往Internet，流日志表明它确实成功地从NAT实例中走出来。
您使用了“拒绝”一词，但wireshark条目与Connection timed out错误一致，而不是Connection refused，由于缺乏监听服务，这是由远端（或者不太常见的是中间防火墙）的主动拒绝在目标端口上，这将导致目标使用TCP RST进行响应。
如果您可以使用NAT Gateway复制问题，那么您可以确信它与NAT实例本身没有任何关系，NAT实例本身只是一个使用iptables ... -j MASQUERADE的Linux实例。
由于垃圾邮件，网络基础设施限制的唯一内容是到目标端口25的出站连接。其他所有内容仅受实例本身的功能限制。使用t2.micro，您应该有（iirc）超过125 Mbits / sec的以太网带宽可用，并且NAT功能不是特别处理器密集型，因此除非您耗尽以太网带宽或实例的CPU余额，NAT实例似乎不太可能是原因。