安全组限制导致应用间通信超时，本质是syn包被拦截，表现为nc测试“connection timed out”；需检查入站规则是否精确配置源安全组id、协议端口，并确认服务监听0.0.0.0而非127.0.0.1。
安全组限制导致的应用间通信超时，本质是流量在到达目标端口前就被拦截了。这不是网络不通，而是“门没开好”——端口开着、服务跑着、ping也通，但TCP三次握手卡在SYN阶段，连接根本建不起来。
确认是不是安全组的问题
先快速排除其他环节，聚焦安全组：
- 用 nc -zv 测试：如果显示 Connection timed out（不是 Connection refused），大概率是安全组或防火墙拦住了SYN包；
- 检查源实例能否 ping 通目标实例：能通说明ICMP放行了，但不代表TCP端口开放；
- 登录目标服务器，执行 netstat -tuln | grep ，确认服务确实在监听 0.0.0.0:（而非仅127.0.0.1）；
- 临时关闭系统防火墙（如 systemctl stop firewalld 或 ufw disable），再测一次——若此时通了，说明安全组和OS防火墙至少有一个没配对。
安全组规则必须满足的两个条件
云平台的安全组是有状态的，但只对“已允许的流”自动放行响应包。所以关键在入站规则是否精准匹配：
- 入站规则必须显式允许源流量：不能依赖“同组互通”，即使两台EC2都在同一个安全组A里，组A的入站规则若没写“来源是安全组A”，它们之间依然不通；
- 源要写对，别写IP地址：推荐用安全组ID作为源（例如 sg-0a1b2c3d4e5f67890），而不是私有IP段（如10.0.0.0/16）。这样既避免IP变更失效，又符合最小权限原则；
- 协议和端口要精确：SQL Server用TCP 1433，Redis用TCP 6379，别错填成UDP或全端口；
- 出站规则通常不用动：有状态机制会自动放回包，除非你主动限制了出站。
典型配置示例（以AWS EC2为例）
假设Web服务器（S1）要连数据库服务器（S2）的1433端口：
- S2的安全组（DB-SG）入站规则加一条：
Type: MS SQL
Protocol: TCP
Port Range: 1433
Source: sg-xxxxxxxx（即S1所在的安全组ID） - 不要写成 Source: 0.0.0.0/0（太宽泛）、也不要写成 Source: 10.0.1.5（S1的私有IP，易变且难维护）；
- 确保S1的安全组（WEB-SG）本身没有出站限制（默认全放行）；
- 如果跨可用区或跨VPC，还要检查路由表和对等连接是否就绪，但安全组仍是第一关。
华为云/阿里云/腾讯云的注意事项
各家控制台界面不同，但逻辑一致：
- 华为云安全组中，“源地址类型”选“安全组”，再选对应的安全组ID；
- 阿里云叫“安全组授权”，填写“授权对象”时粘贴另一台ECS的安全组ID；
- 腾讯云在“入站规则”里，“来源”类型选“安全组”，然后选择目标安全组；
- 所有平台都支持按安全组授权，这是比IP更稳定、更安全的做法。
