确认防火墙是否拦截连接需先排除服务未监听和网络丢包：若ss -tuln无目标端口监听、tcpdump收不到SYN包，则非防火墙问题；真正拦截表现为客户端超时且ss -tn state syn-recv为空，须通过iptables或firewalld日志（需手动开启）及conntrack状态交叉验证。
怎么确认防火墙是否在拦截连接（而不是丢包或服务未监听）
先排除其他可能性：如果 netstat -tuln 或 ss -tuln 显示目标端口没在监听，那根本不是防火墙问题；如果 tcpdump -i any port 80 在服务端收不到 SYN 包，才值得查防火墙拦截。真正被防火墙 drop 的连接，通常表现为客户端超时、无响应，且服务端 ss -tn state syn-recv 为空。
iptables 日志必须手动开启，否则默认不记录任何 drop 行为
iptables 默认不会记日志——哪怕规则里写了 -j DROP，也不会输出一行。必须显式插入一条 LOG 规则，并放在对应 DROP 规则之前：
sudo iptables -I INPUT -p tcp --dport 22 -m state --state NEW -j LOG --log-prefix "iptables-drop-ssh: "sudo iptables -I INPUT -p tcp --dport 22 -m state --state NEW -j DROP
注意顺序：LOG 必须在 DROP 前，否则日志永远不触发；--log-prefix 是关键，它让日志可过滤；-m state --state NEW 避免对已建立连接重复打日志。
firewalld 的日志开关藏得深，且默认关闭
firewalld 不像 iptables 那样允许自由插日志规则，它的日志控制集中在 --set-log-denied 这个全局开关上：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
sudo firewall-cmd --set-log-denied=all—— 开启所有被拒绝流量的日志（包括 icmp、tcp、udp） -
sudo firewall-cmd --get-log-denied—— 确认是否生效（返回all才算开） - 日志输出到
/var/log/messages或journalctl -u firewalld，搜索关键词如firewalld: deny或你设置的--log-prefix
别漏掉这一步：即使配置了 rich rule，若 --set-log-denied 是 off 或 unicast，大部分拒绝行为仍不会落日志。
统计拦截次数不能靠 grep 日志行数，得结合 conntrack 状态看实效
单纯用 grep "iptables-drop" /var/log/messages | wc -l 容易误判：一条连接重试多次会生成多条日志，而真正的“连接失败”只发生一次。更可靠的方式是交叉验证：
- 查当前未完成的连接堆积：
sudo cat /proc/net/nf_conntrack | grep -c "\[UNREPLIED\]"—— 大量[UNREPLIED]往往对应被防火墙静默丢弃的 SYN - 对比
netstat -s | grep -A5 "TCP:"中的failed connection attempts和connection resets，若前者远高于后者，说明很多连接连三次握手都没走完，大概率卡在防火墙层 - 临时放宽规则（如
iptables -I INPUT -p tcp --dport 80 -j ACCEPT），再观察[UNREPLIED]是否锐减，能快速反证
日志只是线索，conntrack 状态和协议统计才是判断拦截是否真实发生、是否持续发生的依据。
