新项目应优先使用nftables，明确业务需求后按表→链→规则结构编写，注意策略顺序、连接状态、回环接口放开及持久化保存，并通过nft list和tcpdump验证。
Linux防火墙规则编写不难，关键在理清逻辑顺序、理解匹配机制、避免常见冲突。用 iptables 或 nftables 都可以，但当前主流发行版（如 Ubuntu 22.04+、CentOS 8+、Debian 11+）默认启用 nftables，底层兼容 iptables 命令（通过 iptables-nft），建议新项目直接用 nftables 编写，更清晰、更高效。
明确防火墙目标：先想清楚“要放行什么、禁止什么”
别一上来就敲命令。先列业务需求：
- 只允许 SSH（22端口）和 HTTPS（443）入站，其他全部拒绝
- 本机需要访问外部 DNS（53/udp）、HTTP/HTTPS（80/443）
- 禁止来自某网段（如 192.168.5.0/24）的所有连接
- 记录可疑的 SYN Flood 尝试（可选审计）
目标清晰了，规则才有意义。防火墙不是堆砌指令，而是按优先级执行的“匹配-动作”链。
掌握基础结构：表（table）→ 链（chain）→ 规则（rule）
nftables 中，规则组织为三层：
-
table：按用途分组，常用有
inet filter（IPv4/v6 通用过滤）、ip filter（仅 IPv4） -
chain：挂载点，对应网络流向，如
input（进本机）、output（本机发出）、forward（转发） -
rule：具体条件 + 动作，例如
tcp dport 22 accept
新建一个最小可用规则集示例：
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \;}
nft add rule inet filter input iifname "lo" accept
nft add rule inet filter input ip saddr 192.168.1.0/24 accept
nft add rule inet filter input tcp dport {22, 443} ct state established,related, new accept
注意：policy drop 设为默认策略后，显式 accept 的规则必须放在它前面，否则全被拦截。
避免典型错误：顺序、状态、回环与保存
很多问题不是语法错，而是逻辑陷阱：
- 规则顺序很重要：nftables 自上而下匹配，第一条匹配即执行动作，不再继续。把宽泛规则（如“accept all from LAN”）写在严格规则（如“drop IP X”）之前，后者就失效
-
别忘了连接状态：只写
tcp dport 22 accept不够，客户端发来的第一个 SYN 包会匹配，但返回包若没允许ct state established，连接仍不通。推荐统一加ct state established,related, new并配合连接跟踪 - 回环（lo）接口必须放开：Docker、systemd、本地服务依赖 lo，漏掉会导致系统异常（如 journalctl 报错、DNS 解析失败）
-
规则重启即丢失：运行中生效 ≠ 持久化。Ubuntu 用
nft list ruleset > /etc/nftables.conf，再启用 systemd 服务sudo systemctl enable nftables；CentOS/RHEL 用nft list ruleset | sudo tee /etc/sysconfig/nftables.conf并确保服务启动
调试与验证：看到真实流量才能信得过
写完别急着上线，三步验证：
-
看规则是否加载：
nft list ruleset -a（加-a显示句柄，方便后续删除） -
查实时计数：
nft list chain inet filter input -n查每条规则匹配包数，确认 SSH 规则有 hit，拒绝规则也在计数 -
抓包比对：用
tcpdump -i eth0 port 22在另一终端观察握手过程，结合ss -tuln确认端口监听正常；从外网用nc -zv your-ip 22测试连通性
如果连不上，先临时 nft flush chain inet filter input 清空测试，再逐条加回，快速定位哪条规则拦住了。
基本上就这些。规则不在多，在准；配置不在快，在稳。把表链结构记牢、按流量方向思考、每次改完验证一次，防火墙就能从“玄学模块”变成你手里的确定性工具。
