排查思路
怀疑被安全组拦截时按固定顺序核对：流量方向 → 实例关联的全部安全组 → 规则优先级与授权对象 → 对端出入方向 → 用流日志或抓包确认丢包位置。安全组是白名单模型，未匹配放行规则的流量被静默丢弃，因此现象通常是超时而不是拒绝，按顺序推进比在十几条规则里反复打转快得多。
基本信息
| 典型现象 | 连接超时、无响应；ICMP 不通；部分端口通、部分端口不通 |
|---|---|
| 易混淆点 | 超时≈被安全组或 ACL 丢弃；connection refused≈报文已到达，主机侧拒绝 |
| 核对范围 | 实例可能关联多张安全组，实际生效结果是各张规则的并集 |
| 对端方向 | 本端入方向与对端出方向都要放行；回包由有状态机制自动放行 |
| 定位工具 | VPC 流日志（可筛 action=REJECT）、tcpdump 抓包、连接测试工具 |
标准排查步骤
- 确认方向：入方向管进入、出方向管发出，回包由状态机制处理
- 列全实例关联的所有安全组，不要只看默认那一张
- 检查优先级与授权对象是否覆盖实际来源网段或来源安全组
- 对端也有安全组时，核对对端出方向与本端入方向是否同时放行
- 用 VPC 流日志（action=REJECT）或 tcpdump 确认在哪一跳被丢弃
典型验证命令
典型验证命令
# 在目标机抓包，确认 SYN 是否到达
sudo tcpdump -ni any 'tcp port 3306' -c 20
# 从来源机发起连接测试，观察是超时还是被拒绝
nc -zv -w 3 10.10.3.20 3306 || echo 'connect failed'
# 确认本机服务确实在监听（排除应用层原因）
ss -lntp | grep 3306
# 流日志中检索被拒绝的流量（日志服务查询片段）
# * | select srcaddr, dstport, action where action='REJECT' limit 20抓包结果对照
| 抓包现象 | 结论与下一步 |
|---|---|
| 完全看不到 SYN | 流量在到达主机前被丢弃，回到安全组与网络 ACL 检查 |
| 看到 SYN 无 SYN-ACK | 报文已到达，查主机侧服务监听与系统防火墙 |
| 有 SYN-ACK 但应用无响应 | 网络已通，属于应用层问题 |
| 只有单向流量 | 检查对端出方向或路由回程路径 |
同一时刻只改一处配置：同时调整安全组与路由后如果现象变化，无法判断是哪一项生效，事后追溯会浪费大量时间。
排查期间临时放行 0.0.0.0/0 是最容易留下隐患的操作，务必记录并在完成后立即收回。
变更与留档习惯
- 变更前导出或截图当前规则，出问题时能快速比对差异
- 一次只改一处：安全组与路由不要同时调整
- 临时放行标注原因与到期时间，事后统一回收
- 把安全组变更与发布时间记在同一时间线上，便于事后归因
- 影响面大的变更先在测试环境复现验证再上生产
两端同时抓包对比
两端同时抓包对比
# 目标机抓包：确认 SYN 是否到达本机
sudo tcpdump -ni any 'tcp port 3306 and tcp[tcpflags] & tcp-syn != 0' -c 10
# 来源机抓包：对比两端看到的内容差异
sudo tcpdump -ni any host 10.10.3.20 -c 10
# 结合流日志筛选被拒绝的连接，确认丢包发生在哪一跳两端同时抓包是最有效的对比手段：只有来源侧看到 SYN 说明报文丢在途中，回到安全组与 ACL；两端都看到则问题在主机侧或应用层。
快速定位矩阵
| 连接测试结果 | 目标机抓包 | 结论 |
|---|---|---|
| 连通正常 | —— | 链路无问题，问题不在访问控制层 |
| 超时 | 看不到 SYN | 报文被安全组或网络 ACL 丢弃 |
| 超时 | 能看到 SYN | 主机侧服务未监听或系统防火墙拦截 |
| 被拒绝 | 能看到 SYN | 报文已到达，检查监听地址与端口 |