核心思路是先用tcpdump确认数据包是否到达网卡，再结合iptables/nftables规则检查是否被主动丢弃：若tcpdump能抓到包但连接不通，重点排查INPUT链DROP规则及默认策略；若完全抓不到，则问题在前序网络或本机网卡硬件。
用 tcpdump 配合防火墙排查丢包，核心思路是：先确认数据包是否到达网卡（tcpdump 能抓到），再判断是否被 iptables/nftables 主动丢弃（或未匹配规则导致隐式丢弃）。两者结合，能快速区分是网络路径问题，还是本机策略拦截。
确认丢包是否发生在本机防火墙环节
如果客户端发包，服务端收不到，先在服务端执行：
- 运行 sudo tcpdump -i eth0 -nn -s0 'host 192.168.1.100'（替换为目标客户端 IP），观察是否能捕获到入向报文；
- 若能抓到，说明包已抵达网卡，问题可能出在上层（如端口未监听、应用崩溃）或防火墙；
- 若完全抓不到，说明丢包发生在前序网络设备（如路由器、交换机、中间防火墙），或本机网卡驱动/硬件异常，此时应先检查
ethtool -S eth0中的RX_DRP和RX_ERR。
检查 iptables 是否存在 DROP/REJECT 规则
抓到包但连接不通，重点查防火墙是否拦截：
- 查看当前规则及计数：sudo iptables -L -n -v（IPv4）或 sudo ip6tables -L -n -v（IPv6）；
- 重点关注 INPUT 链中是否有匹配目标端口（如
tcp dpt:8080）且动作是 DROP 的规则； - 特别注意默认策略（
Chain INPUT (policy DROP)），若 policy 是 DROP 且无显式 ACCEPT 规则，所有未匹配流量都会被丢弃； - 可临时清空规则验证：sudo iptables -P INPUT ACCEPT && sudo iptables -F（测试后务必恢复）。
用 tcpdump + 日志标记定位具体丢弃点
当 iptables 规则较复杂时，可添加 LOG 规则辅助追踪：
- 在可疑位置插入日志规则，例如：sudo iptables -I INPUT 1 -p tcp --dport 8080 -j LOG --log-prefix "FW-DROP-8080: "；
- 同时运行 sudo tail -f /var/log/kern.log | grep "FW-DROP"，观察是否触发日志；
- 若日志出现但 tcpdump 抓不到后续包，说明该包确被此规则丢弃；
- 若日志无输出而 tcpdump 也抓不到包，则问题不在 iptables，需转向 nftables 或内核模块（如 ebtables、tc）排查。
留意 nftables 取代 iptables 的情况
新版系统（如 Debian 12+/RHEL 9+）默认使用 nftables，iptables 命令可能只是兼容层：
- 检查真实规则：sudo nft list ruleset；
- 查看 INPUT 链中的 drop 规则，注意 hook 点（如
hook input priority 0）； - nftables 不支持直接 LOG 计数，可用
meta nftrace set 1配合sudo cat /sys/kernel/debug/nf_trace追踪（需开启 debugfs）； - 临时禁用：sudo systemctl stop nftables（仅测试用）。
