iptables规则按从上到下顺序匹配，匹配即执行，后续规则不再检查；关键允许规则需置于拒绝规则之前，用-I插入顶端而非-A追加末尾。
iptables 规则顺序为什么总不生效
规则没生效，大概率不是写错了，而是位置放错了。iptables 按从上到下顺序匹配，一旦某条规则匹配成功，就直接执行动作（ACCEPT 或 DROP），后面的规则根本不会被检查。
常见错误现象：iptables -A INPUT -p tcp --dport 22 -j ACCEPT 加在最后，但前面已有 REJECT 或 DROP 的兜底规则，SSH 就连不上。
- 用
iptables -L --line-numbers查看当前规则序号，确认关键规则是否在拒绝规则之前 - 新增允许规则时，优先用
-I INPUT 1插入到最顶端，而不是默认的-A追加到末尾 - 生产环境建议先清空临时规则（
iptables -F），再按“允许→拒绝→记录”逻辑重新加载整套策略
ufw 和 iptables 能不能一起用
能一起用，但不建议混用——ufw 本质是 iptables 的封装层，它启动时会重置原始 iptables 规则，并把自己的规则写进 /etc/ufw/** 下；你手动改 iptables，ufw reload 时大概率被覆盖。
使用场景：如果系统已启用 ufw（比如 Ubuntu 默认），就别碰裸 iptables；如果需要精细控制（如基于 conntrack 状态、自定义链），直接关掉 ufw（ufw disable），用 iptables 管理。
- 检查 ufw 状态：
ufw status verbose，看到 “Status: active” 就说明它正在接管 iptables - ufw 的底层规则存放在
/lib/ufw/user.rules和/etc/ufw/before.rules，修改后需ufw reload - 混用时最常踩的坑：ufw 日志里看不到你手写的 iptables -j LOG 规则，因为 ufw 自己的链跳转逻辑可能绕过了它
firewalld 的 zone 切换为什么没反应
firewalld 不是“改完 zone 就立刻生效”，它依赖接口绑定和运行时/永久配置同步。最典型的情况是：你执行了 firewall-cmd --set-default-zone=public，但网卡仍绑在 trusted 上，新规则对它无效。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
参数差异：--permanent 只改配置文件，不影响当前运行状态；--runtime-to-permanent 是单向同步，不能反向拉取。
- 查接口实际 zone：
firewall-cmd --get-zone-of-interface=eth0 - 绑定接口到 zone：
firewall-cmd --zone=public --change-interface=eth0（这步才是实时生效的关键） - 开放端口必须指定 zone：
firewall-cmd --zone=public --add-port=8080/tcp，漏写--zone默认操作的是 default zone，但接口未必在那儿
怎么快速定位某端口被哪个规则拦了
靠猜不行，得让内核告诉你。iptables 本身不记录“为什么丢包”，但可以加 LOG 规则把匹配过程打出来，再配合 dmesg 实时抓日志。
性能影响很小，但别长期开着——每条匹配都触发内核日志，高流量下会拖慢网络栈。
- 在 DROP 规则前插入记录：
iptables -I INPUT -p tcp --dport 3306 -j LOG --log-prefix "DB-DENY: " - 实时看日志：
dmesg -w | grep "DB-DENY"，连接被拒时会显示源 IP、协议、匹配的规则行号 - 注意：LOG 不终止匹配流程，记得在它后面紧跟
DROP，否则日志写了包还是放行
复杂点在于，很多拦截其实发生在 raw 或 mangle 表，而默认 iptables -L 只查 filter 表。真要彻底排查，得挨个查：iptables -t raw -L、iptables -t mangle -L、iptables -t nat -L——这点最容易被忽略。
