关键是要捕获内核 netfilter 的丢包痕迹，而非仅看 firewalld 服务日志；需用 journalctl -k 结合 drop/reject/log 等关键词实时过滤内核日志，并验证 firewalld 是否启用 log-denied 或 direct log 规则。
排查防火墙丢包问题，关键不是只看 firewalld 服务日志，而是要捕获内核层面实际执行丢包动作的痕迹——这通常出现在 netfilter 日志或内核日志中，而 journalctl 是最直接的入口。
确认 firewalld 是否启用了日志记录
firewalld 默认不记录每条丢包，必须显式开启日志规则。否则 journalctl 里几乎看不到丢包细节。 - 检查当前是否配置了带 log 前缀的 rich rule 或 direct rule： sudo firewall-cmd --list-all（看输出中是否有log 或 LOG）
- 查看 firewalld 配置文件是否启用 debug 级别日志：
grep "log-level" /etc/firewalld/firewalld.conf
若为 log-level=info 或更低，建议临时改为 debug，再 sudo systemctl restart firewalld用 journalctl 抓取内核 netfilter 丢包日志
真正触发丢包的是内核 netfilter 模块（如 iptables/nftables），其日志由内核发出，通过 journald 收集，优先级通常是notice 或 info，但带关键词如 IN=、OUT=、DROP、REJECT、LOG。
- 查看最近含 DROP/LOG 的内核消息：
journalctl -k -g "DROP\|LOG\|REJECT" -n 100
- 结合时间范围和接口过滤（例如排查 eth0 上的丢包）：
journalctl -k --since "10 minutes ago" | grep -i "eth0.*drop\|in=eth0.*out="
- 若使用 nftables 后端，还可加关键词：journalctl -k -g "nft\|nf_tables"交叉验证：检查 rsyslog 是否转发了内核日志
有些系统会把内核日志重定向到 /var/log/messages 或 /var/log/kern.log，而 journalctl 可能未实时同步。需确认日志流向是否一致。 - 运行：journalctl -k -n 20 和 tail -20 /var/log/kern.log 对比内容是否接近 - 若后者有更多 DROP 记录，说明 journald 配置可能限制了内核日志采集（检查/etc/systemd/journald.conf 中 ForwardToSyslog=yes 和 MaxLevelKMsg=notice 设置）
补充技巧：让丢包“自己说话”
如果当前没日志，可主动注入一条可识别的测试规则，触发并定位日志格式： - 添加一条带唯一标识的日志规则（临时）： sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 9999 -j LOG --log-prefix "TEST-DROP-9999: " - 再触发一次连接（如nc -zv localhost 9999），然后立刻查：
journalctl -k --since "30 seconds ago" | grep "TEST-DROP"
- 成功后记得清理：sudo firewall-cmd --direct --remove-rule ipv4 filter INPUT 0 -p tcp --dport 9999 -j LOG真正丢包往往发生在内核路径，而非 firewalld 进程本身。所以重点盯 journalctl -k + 关键词 + 时间窗口，而不是只刷 journalctl -u firewalld。
