AWS Network ACL导致SSH连接中断问题排查求助

这种情况我踩过好几次坑，核心原因基本都绕不开Network ACL（NACL）的无状态特性——和安全组“自动放行响应流量”的逻辑不同，NACL要求你明确配置入站和出站双向规则，漏了任何一边都会直接断连。结合你的描述，我帮你拆解下可能的问题点和排查步骤：

最可能的元凶：缺失SSH响应的出站规则 #

当你从本地VPC、对等VPC发起SSH连接时，数据包是源端口（临时端口1024-65535）→ 目标端口22入站到实例；而实例的响应数据包是**源端口22 → 目标端口（发起方的临时端口）**出站。如果你的自定义NACL只配了入站允许SSH，没配对应的出站规则，响应流量会被直接拦截，自然就断连了。

默认NACL是全放行所有进出流量的，换成自定义后，这个“隐式放行”就消失了，这是最容易忽略的细节。

逐条验证你的入站SSH规则 #

即使你配了三条入站规则，也得确认细节是否准确：

• 本地VPC实例发起连接：源地址是不是你本地VPC的完整CIDR？比如10.0.0.0/16，而不是某个单个IP？规则的协议是不是TCP，目标端口是不是22？
• 对等VPC发起连接：源地址是不是对等VPC的CIDR？另外要确认VPC peering连接已经成功建立且路由表配置正确——如果peering本身没通，NACL规则配得再对也没用。
• 公司办公网络：这条没配置的话，从办公网连肯定失败，但你说所有SSH都断，说明前两条的配置也存在问题。

规则优先级和默认拒绝的坑 #

NACL的规则是按序号从小到大匹配，匹配到就停止执行后续规则。如果你的自定义NACL最后一条是默认的“拒绝所有”（这是自定义NACL的默认配置），那你必须把三条允许SSH的规则放在“拒绝所有”规则的前面。要是不小心把允许规则放在了拒绝规则后面，那这些允许规则根本不会生效。

快速排查步骤 #

1. 临时测试出站规则：先给自定义NACL加一条“允许所有TCP流量（0.0.0.0/0，端口0-65535）”的出站规则，然后重新尝试SSH连接。如果能连上，就坐实了是出站规则缺失的问题，接下来再把出站规则细化成只允许对应源CIDR的临时端口范围（1024-65535）即可。
2. 核对入站规则的源和端口：逐个检查三条入站规则的源CIDR、协议、目标端口是否准确，有没有笔误（比如把CIDR写成10.0.0.1/32而不是整个VPC的范围）。
3. 确认NACL关联的子网：检查是不是把自定义NACL关联到了错误的子网，或者有没有其他子网的NACL影响了你的SSH路径。

总之，自定义NACL的核心就是“双向放行”，别只盯着入站规则，出站的响应流量同样重要。

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