直接验证防火墙是否拦截关键流量：先查firewalld、iptables、nftables服务状态及规则，再重点检查INPUT链默认策略与端口放行规则，结合包计数和日志定位拦截点，最后通过临时绕过确认因果。
直接看防火墙规则是否拦住了关键流量——不是先猜，而是按顺序验证 INPUT、OUTPUT、FORWARD 三条链有没有误 DROP 或漏放行。
确认防火墙服务是否运行
很多问题其实源于防火墙根本没生效，或者刚重启后规则丢失：
- 查 firewalld 状态：sudo systemctl status firewalld
- 查 iptables 是否加载：sudo iptables -L -v -n | head -10（若输出为空或只有 chain names，说明规则可能未加载）
- 查 nftables 规则：sudo nft list ruleset | grep -E "(hook|drop|accept)"
- 若服务停着但本该启用，立即启动：sudo systemctl start firewalld 或 sudo systemctl start nftables
检查默认策略和关键链的允许规则
最常见错误是 INPUT 默认 DROP，却忘了加 SSH、HTTP 等基础放行规则：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 重点看 INPUT 链：是否有 ACCEPT 规则匹配你的服务端口（如 22、80、443）和来源网段
- 检查 OUTPUT 是否被锁死：如果连 ping 8.8.8.8 都失败，可能是 OUTPUT 默认 DROP 或缺少 ESTABLISHED/RELATED 放行
- 内网访问外网异常？看 FORWARD 链 + net.ipv4.ip_forward=1 是否开启（sysctl net.ipv4.ip_forward）
- 用 sudo iptables -L INPUT -v -n 查计数器——若某条 ACCEPT 规则包计数为 0，说明流量根本没走到那儿，得往前排查
临时绕过防火墙验证是否真由它导致
别靠“感觉”，用最小干预快速证伪：
- firewalld 用户：sudo firewall-cmd --panic-on（紧急模式全阻断），再 --panic-off 恢复；或临时清空：sudo firewall-cmd --remove-all-services --remove-port=22/tcp --reload
- iptables 用户：sudo iptables -P INPUT ACCEPT && sudo iptables -P OUTPUT ACCEPT && sudo iptables -F（慎用，仅测试）
- 测试后立刻恢复：sudo systemctl restart firewalld 或重载规则，避免裸奔
- 如果禁用后网络立刻恢复，基本锁定是防火墙策略问题
查日志定位被拦截的具体连接
光看规则不够，得知道谁被拦、为什么拦：
- 启用拒绝日志（firewalld）：sudo firewall-cmd --set-log-denied=all && sudo firewall-cmd --reload，然后查 journalctl -u firewalld | grep 'DROP'
- iptables 日志需提前配置 LOG target，但更简单的是用 sudo tcpdump -i any port 22 and icmp 结合 ping/ssh 失败时抓包，看是否发出去就被本机丢弃
- 注意：云服务器还要同步检查安全组（如阿里云/腾讯云控制台），它在防火墙外层，常被忽略
