firewalld规则是否命中需看firewall-cmd --list-all --verbose中packets计数变化，而非仅--list-all；若reject/drop规则计数上升，即为实际拦截点，且默认target等效drop，无显式accept即拦截。
firewalld规则是否命中并计数增长
只看firewall-cmd --list-all输出无法确认某条规则是否真在拦截流量。关键要看包计数是否变化：运行firewall-cmd --list-all --verbose，观察每条规则后的packets字段；若某条REJECT或DROP规则的计数持续上升，基本锁定就是它在丢包。
常见误判点：firewalld默认使用default target（等效DROP），即使没显式规则，只要没匹配到ACCEPT也会拦截。临时改target验证：firewall-cmd --set-target=ACCEPT，再测连接——恢复即说明是firewalld策略问题。
iptables/nftables规则链中DROP位置是否靠前
规则顺序决定命运。用iptables -L INPUT -n -v或nft list ruleset查看INPUT链，重点找DROP或REJECT行。如果它出现在你放行端口的ACCEPT规则之前，那后面所有规则都无效。
- 典型陷阱：有人加了
iptables -A INPUT -j DROP作为“兜底”，却忘了它会插在链尾——但若之前已有-j REJECT，实际生效的是更早的那条 - 临时测试：把可疑
DROP规则删掉（iptables -D INPUT 3删第3条），或用iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT强行插到最前 - nftables里规则带handle编号，删时必须用
nft delete rule ip filter INPUT handle 12，不能只靠序号
是否开启防火墙日志并捕获丢包详情
光看计数只能知道“被拦了”，不知道“为什么拦”。启用日志才能看到源IP、端口、协议等上下文：
iptables示例：iptables -I INPUT -p tcp --dport 80 -j LOG --log-prefix "FW-HTTP-DROP: "，然后查journalctl -k | grep "FW-HTTP-DROP"；nftables类似：nft add rule ip filter INPUT tcp dport 80 log prefix "nft-http-drop: "。
注意：日志不记录完整payload，但足够定位是哪个IP段、哪个端口、甚至哪个应用（如User-Agent头里的curl/Chrome）触发了拦截。日志量大时建议加--limit 5/minute防刷屏。
云平台安全组和主机防火墙是否双重拦截
本地iptables或firewalld全开，不代表流量真能进来。云服务器（阿里云/腾讯云/AWS）的“安全组”是第一道网关，它独立于系统防火墙运行。
排查步骤：
- 登录云控制台，找到对应ECS实例的安全组配置
- 检查入方向规则：协议是否为
TCP，端口范围是否包含目标端口（如80或443），源IP是否允许（0.0.0.0/0或你的办公IP） - 安全组规则不支持
-s 192.168.0.0/16这种内网写法，必须填真实公网IP或CIDR - 某些厂商（如华为云）还分“网络ACL”和“安全组”，后者作用于实例，前者作用于子网，得两层都查
真正容易被忽略的是：安全组修改后无需重启实例，但firewalld重载（firewall-cmd --reload）可能清空手动添加的iptables规则——混用时尤其危险。
