云端 ACL 放行了端口，主机仍可能拒绝连接；主机防火墙允许访问，云端规则也可能在流量到达前将其拦截。做好云端网络ACL与主机防火墙规则协同，关键是按数据包经过的顺序逐层核对，而不是把两处规则简单复制一遍。以下五项可用于 Linux 或 Windows 云主机的变更检查。
1. 先画清流量经过哪些控制点
记录客户端、云网络边界、主机网卡和服务进程之间的路径，并标明每一层应用的规则。以一台提供 HTTPS 的 Linux 主机为例，请求可能先经过云端网络访问控制列表（ACL），再到主机的 nftables 或 firewalld，最后由 Web 服务监听端口。若环境还使用安全组、负载均衡器或网关，也应纳入路径图，不能把它们与 ACL 混为一谈。
注意产品语义并不完全相同：AWS VPC 网络 ACL 是无状态的，入站和出站需要分别配置；安全组则是有状态的。其他云平台的 ACL 也应以对应产品文档为准。先确认规则对象和处理顺序，才能判断阻断发生在哪一层。
2. 按方向逐条核对五元组
每条规则都写明源地址、目的地址、协议、端口和方向。主机开放 TCP 443，不代表云端只需写“允许 443”：还要确认规则匹配的是客户端到服务器的入站请求，还是服务器的出站响应。
例如，HTTPS 客户端访问 Linux 主机的 TCP 443 时，无状态 ACL 通常还要允许返回流量到客户端所用的临时端口范围；该范围会随操作系统和配置而异，应查实际系统设置，不能照搬一个固定区间。有状态的主机防火墙通常可借助连接跟踪处理已建立连接的回包。核对入站规则与出站规则时，分别验证新建连接和返回流量。
3. 查规则顺序、默认动作与重复放行
同一条流量可能同时符合多条规则。检查 ACL 是否按编号或优先级先匹配，以及末尾默认是允许还是拒绝；再查看主机规则中是否存在更早的拒绝规则。云端与主机的匹配逻辑不同，不能只比较规则条数。
建议维护一张最小权限表，记录“业务用途—来源—协议端口—云端动作—主机动作—负责人”。例如 SSH 管理端口只允许来自受控管理网段；不要为了排障而长期对所有来源开放。临时放宽时记录到期时间，并在问题定位后恢复原规则。
4. IPv4、IPv6 和主机接口都要覆盖
分别检查 IPv4 与 IPv6 规则。只限制 IPv4、却让服务通过 IPv6 地址监听，可能形成遗漏；反过来，主机只开放 IPv4 而云端配置 IPv6 放行，也不会自动让服务可达。还要确认规则绑定的网卡、子网和实际目的地址一致，避免把测试网卡上的结果误当成生产路径。
若主机使用 nftables、firewalld 或 Windows Defender 防火墙，应在相应工具中确认当前生效规则，而不只检查配置文件。不同工具的规则持久化方式不同，重启后也要验证规则仍然存在。
5. 分层测试、留痕并准备回滚
- 变更前导出或记录云端 ACL 与主机防火墙现状，标注规则编号、修改人和回滚方式。
- 先从获准的来源测试目标端口，再从不应获准的来源做反向验证；不要只以“能连上”作为通过标准。
- 同时查看云端流日志（若已启用）和主机日志，结合时间、源地址、目的端口判断丢弃位置。日志功能与字段因平台而异。
- 确认业务连接、管理通道及必要出站访问正常后，再保存变更；若管理连接可能被切断，先保留控制台或其他带外恢复途径。
把这五项纳入每次规则变更单，云端网络ACL与主机防火墙规则协同就能从“碰巧可用”变成可核验的访问控制。重点是规则方向和实际路径一致、必要回包可达、拒绝范围清楚，并且每项变更都能验证与回退。
常见问题
云端 ACL 和主机防火墙需要配置完全相同吗？
不需要。它们承担不同层次的控制职责，但允许的业务流量应一致；主机层可进一步按进程、接口或连接状态细化。
只允许入站端口，为什么连接仍然失败？
可能是出站回包被无状态 ACL 拦截，也可能是主机未监听该端口、主机规则拒绝流量，或目的地址与网卡不匹配。按路径逐层检查。
改规则后如何确认生效？
从允许和拒绝的来源分别发起测试，核对云端与主机日志，并确认规则已保存且重启后仍有效。测试范围应限于获准的主机和网络。
