安全组工作在OSI模型的第3层（网络层）和第4层（传输层）之间，是云平台虚拟网络栈中紧贴物理网卡之上的有状态包过滤机制，能识别IP、协议类型、端口号并基于五元组状态智能放行。
安全组不是操作系统层面的防火墙，也不是靠 iptables 或 Windows 防火墙实现的。它的运行位置更底层——在云平台虚拟网络栈中，紧贴物理网卡之上、虚拟机网卡之下，属于 VPC 网络层的有状态包过滤机制。
安全组运行在网络协议栈的哪一层？
它工作在 OSI 模型的第 3 层（网络层）和第 4 层（传输层）之间，能识别源/目的 IP、协议类型（TCP/UDP/ICMP）、端口号，并基于连接状态做智能放行。流量进入云服务器前，先经过宿主机上的虚拟交换机（如 OVS、VPC Gateway），再由安全组模块完成匹配与决策，未被允许的包直接丢弃，根本不会到达实例内核协议栈。
这意味着：即使你关掉了系统防火墙、没设 root 密码、SSH 允许空口令，只要安全组没放 22 端口，外部就完全无法建立 TCP 连接——连 SYN 包都进不来。
安全组规则是怎么下发并生效的？
规则不写在服务器本地，而是由云平台控制面（如阿里云的 ACS、腾讯云的 TKE-Controller）统一管理。当你在控制台或 API 提交一条新规则，后台会：
- 校验语法、优先级冲突、CIDR 合法性等；
- 将规则编译为轻量级匹配指令（类似 eBPF 或 Netfilter xt_match 的精简版）；
- 通过元数据通道（如 etcd + agent 心跳同步）推送到该实例所在物理机的转发平面；
- 宿主机上的 vSwitch 或安全组代理模块热加载规则，毫秒级生效，无需重启实例或网卡。
这种“控制面-数据面分离”架构，保证了规则变更对业务零感知，也解释了为什么改完安全组，立刻就能 ping 通或断开——它不依赖任何实例内部服务。
为什么安全组是有状态的？底层怎么实现？
有状态不是靠维护完整连接表，而是基于五元组（源IP、目的IP、源端口、目的端口、协议）+ 方向哈希做快速查表。当一条入方向规则允许某 TCP 流量进来，系统自动在状态表中记录该连接的反向路径（目的变源、端口互换），后续响应包只要匹配该反向五元组，就直接放行，无需再走规则匹配流程。
出方向同理：实例主动发包触发状态创建，返回流量自动豁免入方向规则检查。这大幅降低性能损耗，也让管理员不用配“回程放行”这类冗余规则。
多个安全组绑定时，规则如何叠加？
一个实例可绑多个安全组，但规则不是简单合并，而是“全允许才放行”。即：某条入站流量必须同时满足所有已绑定安全组中至少一条允许规则，且不被其中任一拒绝规则命中，才会被接受。
实际匹配过程是：按安全组优先级从高到低依次遍历，每个安全组内部再按规则优先级（1–100，越小越高）逐条匹配。一旦某个安全组中某条规则明确拒绝该流量，立即拦截，不再检查其余安全组。
所以，拒绝类规则要慎用——它可能意外阻断本该放行的业务流量，尤其在多安全组混用场景下。
