AWS EC2连接不稳定，如何逐层排查网络问题？

“服务器平时可以连接，但偶尔会突然断开。重试几次以后，又恢复正常了。”

相比完全无法连接，这类间歇性故障更难处理。

因为检查人员登录服务器时，服务可能已经恢复，监控曲线也没有明显异常。于是问题很容易被归结为“网络波动”，却没有找到真正原因。

排查AWS EC2连接不稳定，关键不是反复重启实例，而是先确定故障发生在哪一段链路。

一、先区分不同的连接现象

开始检查前，最好记录完整错误提示。

常见现象包括：

Connection timed out
Connection refused
Connection reset
SSH连接一段时间后断开
网站能够打开，但响应速度不稳定
部分用户正常，部分用户连接失败
通过私网正常，通过公网不稳定

这些现象代表的问题方向不同。

连接超时通常表示请求没有顺利到达目标服务，可能与安全组、网络ACL、路由或公网线路有关。

连接被拒绝，往往说明请求已经到达实例，但目标端口没有服务监听，或者操作系统防火墙拒绝了连接。

连接建立后又被重置，则要继续检查应用程序、连接超时设置、负载均衡和服务器资源。

错误提示不同，排查起点也应该不同。

二、记录问题发生的范围和时间

间歇性故障最重要的证据，是准确的发生时间。

建议至少记录：

故障开始和恢复时间
客户所在地区和网络运营商
访问的公网IP或域名
使用的端口和协议
是否经过负载均衡
哪些用户正常，哪些用户异常
同一时间实例监控是否出现变化

如果只有某个办公网络连接失败，问题可能出在客户出口、防火墙或互联网线路。

如果所有地区同时异常，应优先检查EC2实例、负载均衡、路由和AWS服务事件。

如果只有负载均衡后面的部分请求失败，则可能是某台后端实例或某个可用区出现异常。

三、先看EC2状态检查

进入EC2控制台，确认实例是否通过系统状态检查和实例状态检查。

系统状态检查主要反映底层宿主机、网络和电源等基础设施状况；实例状态检查则更接近操作系统内部的网络和启动状态。

如果状态检查曾经失败，应当查看对应时间段的事件记录，不要只看当前是否已经恢复。

同时查看CloudWatch中的以下指标：

CPU使用率
网络流入和流出
网络包数量
实例状态检查
磁盘读写情况
突发型实例的CPU积分

需要注意，CPU正常并不代表网络一定正常。连接数、每秒数据包数量和实例网络额度达到限制时，也可能出现延迟或丢包。

四、确认实例是否具备正确的连接路径

如果通过互联网连接EC2，需要确认实例是否具备公网访问条件。

重点检查：

实例是否关联公网IP或弹性IP。
实例所在子网是否使用正确的路由表。
路由表是否具有指向互联网网关的路由。
VPC是否已经关联互联网网关。
当前连接地址是否仍然是实例最新的公网地址。

普通公网IP可能在实例停止并重新启动后发生变化。如果DNS记录或运维文档仍然保存旧地址，就会出现部分人员能够连接、部分人员连接到错误地址的情况。

如果实例位于私有子网，则不能简单依靠互联网网关直接连接。通常需要使用堡垒机、VPN、Direct Connect、Session Manager或其他私网接入方式。

五、安全组要检查来源和端口

安全组是EC2实例的重要访问控制层。

检查时不要只看“端口是否开放”，还要确认：

规则是否绑定到正确的实例网卡。
入站规则中的协议是否正确。
目标端口是否与服务监听端口一致。
来源IP是否包含当前客户的公网出口地址。
实例是否关联了多个安全组。
出站规则是否限制应用访问外部服务。

例如，SSH通常使用22端口，Windows远程桌面通常使用3389端口。如果业务修改了默认端口，安全组也要同步调整。

办公网络的公网出口IP发生变化后，原来只允许固定地址的安全组规则也可能失效。

不建议为了排障长期向所有来源开放SSH或远程桌面端口。更合适的方式是确认当前出口IP，只允许必要来源访问。

六、网络ACL容易漏掉返回流量

安全组和网络ACL经常被混为一谈，但两者工作方式不同。

安全组具有状态跟踪能力。已经允许进入的连接，其返回流量通常不需要再单独配置对应的入站规则。

网络ACL则是无状态的，需要分别允许请求和返回流量。

因此，网络ACL不仅要允许SSH、HTTPS等业务端口，还要考虑客户端使用的临时端口范围。如果只允许请求进入，却拦截了返回流量，连接可能超时或者表现不稳定。

还要注意：

网络ACL按照规则编号匹配。
较小编号的规则会优先处理。
允许规则前面可能存在范围更大的拒绝规则。
入站和出站需要分别检查。

AWS官方的EC2连接排障说明也建议同时检查安全组、网络ACL和路由表，并确认网络ACL允许返回使用的临时端口。AWS EC2连接问题排查

七、检查操作系统内部状态

如果AWS网络配置没有明显问题，就要继续检查实例内部。

重点关注：

SSH或远程桌面服务是否正常运行。
Nginx、Apache或业务程序是否出现重启。
操作系统防火墙是否修改过规则。
CPU、内存和磁盘等待是否过高。
TCP连接数量是否异常增长。
文件句柄或连接队列是否达到上限。
系统日志中是否出现网卡、内核或内存错误。

有些实例在平时负载较低时表现正常，业务高峰到来后，连接队列或内存资源达到限制，就会开始拒绝新连接。

如果重启后短时间恢复，但运行一段时间又出现问题，更应该检查资源泄漏、连接未释放和应用进程状态，而不是把重启当成最终解决方案。

八、关注实例网络额度

不同EC2实例类型具有不同的网络性能和数据包处理能力。

如果流量持续增长，实例可能碰到带宽、每秒数据包数量或连接跟踪额度。此时，CloudWatch中看到的平均网络流量未必特别高，但用户仍可能遇到丢包、延迟或新连接建立失败。

AWS提供了ENA网络指标，可以辅助判断是否超过实例网络额度，例如：

入方向或出方向带宽额度被超过
每秒数据包额度被超过
连接跟踪额度不足
链路本地数据包处理额度被超过

部分较小实例的网络性能采用基线加突发模式。短时间测试可能正常，持续高流量后性能才开始下降。

AWS官方说明，实例超过网络额度时可能出现数据包排队、丢包、延迟升高和连接被迫关闭等现象。AWS EC2网络额度排障

九、使用负载均衡时检查所有后端

如果用户通过ALB或NLB访问EC2，不能只检查其中一台实例。

需要查看：

目标组中是否有实例健康检查失败。
不同可用区是否都有健康目标。
健康检查端口和业务端口是否一致。
应用是否能够正确响应健康检查路径。
安全组是否允许负载均衡访问后端。
连接空闲超时是否符合业务需要。
实例下线时是否完成连接排空。
某个可用区是否存在异常后端。

如果三台后端实例中有一台异常，用户的请求可能有时成功、有时失败。这种现象经常被误判为公网线路不稳定。

应该分别查看每台目标实例的健康状态和应用日志，而不是只看负载均衡的整体访问量。

十、比较不同网络的访问结果

如果AWS侧配置和实例资源都正常，可以从不同客户端进行对照测试。

例如：

办公宽带
家庭网络
手机热点
不同地区的测试节点
同一区域内的另一台EC2实例

如果内网访问一直正常，只有某个地区的公网用户不稳定，问题更可能出现在公网链路或客户本地网络。

检查网络路径时，不要只看到中间某一跳丢包就下结论。部分路由设备会限制探测请求的响应，如果后续节点和最终目标没有持续丢包，中间节点的单独丢包不一定影响真实业务。

AWS建议同时关注最终目标是否丢包，以及异常是否持续到后续节点。AWS网络性能排障说明

十一、使用VPC Flow Logs查看流量结果

VPC Flow Logs可以记录经过网络接口的流量信息。

排查时可以根据故障时间、源地址、目标地址和端口，查看流量是被接受还是被拒绝。

如果记录显示请求被拒绝，应继续检查安全组、网络ACL和网络路径。

如果请求已经被接受，但应用仍然没有响应，则应把重点转向操作系统防火墙、服务监听和应用处理能力。

需要注意，Flow Logs适合判断流量是否经过和是否被拒绝，但它不能完全说明应用为什么响应缓慢。

十二、用Reachability Analyzer检查配置路径

VPC Reachability Analyzer可以分析源和目标之间的配置路径，帮助定位安全组、网络ACL、路由表或网关配置中的阻断点。

它比较适合检查：

互联网网关到EC2的访问路径
两台EC2之间的私网连接
跨VPC连接
负载均衡到后端实例的路径
VPC端点访问路径

但它分析的是网络配置模型，不是实时发送数据包，也不能代替延迟、丢包和应用性能测试。AWS Reachability Analyzer说明

结语

AWS EC2连接不稳定，可能发生在客户端、公网线路、VPC网络、实例操作系统或者应用程序中的任何一层。

可以把连接链路理解为：

客户端 → 公网或专线 → VPC路由 → 网络ACL → 安全组 → EC2系统 → 应用服务

先判断问题影响范围，再按照这条链路逐层检查，比直接重启实例或开放全部端口更容易找到真正原因。