firewall-cmd --state是最直接可靠的centos/rhel防火墙状态判断方式，输出running表示真正就绪，not running表示未运行；它直连firewalld daemon查询真实状态，比systemctl status更准确。
先看防火墙是否启用，再确认它拦了什么
很多人一上来就改安全组，结果发现根本没开 firewalld 或 ufw，白忙活。先执行 firewall-cmd --state（CentOS/RHEL）或 ufw status verbose（Ubuntu/Debian）确认状态。如果输出 not running 或 Inactive，那系统防火墙压根没在工作，问题一定出在安全组或服务监听地址上。
如果已启用，用 firewall-cmd --list-all 或 ufw status numbered 查当前规则。重点看两点：一是是否有明确的 allow 规则匹配目标端口和协议（比如 80/tcp），二是默认策略是不是 DROP 或 deny。常见坑是只加了 firewall-cmd --add-port=3306/tcp，但没加 --permanent，重启后规则消失；或者用了 ufw allow 3306 却没指定 proto tcp，导致 UDP 流量被误放行而 TCP 仍被拒。
安全组开了端口，但连接超时？查规则是否真生效
阿里云、腾讯云等平台的安全组规则不是“添加即生效”——有些控制台会显示“已添加”，但实际可能因权限不足、跨区域绑定错误或安全组未真正关联到实例而失效。登录控制台，进实例详情页 → 安全组，确认当前实例绑定的安全组列表里确实包含你刚配的那个。
再检查入方向规则本身：
- 协议类型必须与服务一致（HTTP/HTTPS 用
TCP，不要选ALL或UDP） - 端口范围要精确（
80不等于80-80，某些平台对格式敏感） - 授权对象不能写错，
0.0.0.0/0是全放开，203.123.45.67要带/32才算单 IP - 优先级冲突：多个规则匹配时，高优先级（数值小）的会覆盖低优先级的，比如一条
deny规则优先级为 100，而你的allow是 99，那就白配了
两边都配了白名单，还是连不上？检查逻辑是否自相矛盾
最典型的冲突场景：安全组允许 203.123.45.67 访问 80 端口，但 firewalld 里只写了 firewall-cmd --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" port port="80" protocol="tcp" accept' ——看着是放行了，实则把所有来源都接进来，违背了最小权限原则；更糟的是，若 firewalld 默认 zone 是 drop，又没加源地址限制，这条规则反而会触发内核丢包。
正确做法是让两边规则严格对齐：
- 安全组放行哪些 IP，firewalld 就只对这些 IP 加 rich rule 或 ufw 的
from限定 - 避免在 firewalld 中留“宽泛放行”规则（如
allow 80/tcp），除非你确定这是临时调试且有监控兜底 - 用
ss -tlnp确认服务监听的是0.0.0.0:80而非127.0.0.1:80，否则即便规则全对，流量也进不到 socket 层
排查时别跳步骤：从本地到公网逐层验证
很多人直接从自己电脑 telnet 公网 IP，失败就断定是安全组问题，结果折腾半天发现服务根本没监听外网地址。必须按顺序验证：
- 在服务器本地跑
curl -v http://127.0.0.1:80→ 确认服务活着 - 用另一台同 VPC 内的 ECS
telnet 内网IP 80→ 排除安全组，聚焦系统防火墙 - 从公网机器
telnet 公网IP 80→ 若超时，说明被安全组或中间网络设备拦截；若被拒绝（Connection refused），才是监听地址或服务没启 - 最后用
tcpdump -i eth0 port 80抓包，看请求是否到达网卡：有包进来但无响应 → 防火墙或服务层问题；完全没包 → 安全组或路由问题
复杂点在于，安全组和系统防火墙是两套独立机制，内核收包路径上它们先后作用，但错误配置不会报错，只会静默丢包。最容易被忽略的是：修改 firewalld 后忘了 firewall-cmd --reload，或者改了安全组却没检查实例是否绑定了新规则组——这两处不生效，前面所有操作都归零。
