提到Linux防火墙，现在绕不开nft了。它已经取代iptables，成为主流发行版的默认选择。别被“下一代防火墙”这个名头唬住，它并非碘伏性的新事物，更像是把旧工具的逻辑彻底重构了一遍，变得更干净、更统一。对于新手来说，最快的学习路径不是啃完所有语法，而是直接动手配置，在操作中理解。
怎么快速建一个能用的 filter 表
大部分场景下，我们只需要管理入站流量，比如只开放SSH端口，其他一概拒绝。这时候，使用inet地址簇是最省心的选择，它能同时处理IPv4和IPv6，避免为两种协议写两套重复的规则。
搭建一个基础防火墙，四步就够了：
- 创建表：
nft add table inet filter - 添加基链：
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }。这里有个细节要注意，末尾的反斜杠和分号是Shell环境下的转义要求。policy drop将默认策略设为拒绝，这是构建安全规则的最佳起点。 - 放行回环接口：
nft add rule inet filter input iifname "lo" accept - 允许已建立的连接：
nft add rule inet filter input ct state established,related accept（这里的ct是conntrack的缩写）
执行完这四条命令，运行nft list ruleset就能看到完整的规则结构了。不过，这时候SSH还连不上——因为还没有明确放行22端口，这一点和iptables的逻辑是一致的。
为什么 tcp dport 22 accept 有时不生效
一个常见的问题是：明明添加了SSH端口规则，连接却依然失败。nft list ruleset显示规则存在，ss -tlnp | grep :22也确认sshd服务在监听。问题往往出在细节上。
首先，tcp dport 22只匹配TCP协议。虽然极其罕见，但如果客户端的SYN包在传输过程中被某些中间设备修改了协议类型，或者规则中误用了ip protocol tcp这类冗余写法，都可能导致匹配失败。
其次，规则的位置至关重要。nft会按照链内的顺序逐条匹配。如果把一条类似ct state invalid drop的兜底规则放在了SSH规则前面，那么新的连接请求会在匹配到SSH规则之前就被丢弃。
最后，地址簇的选择是个隐形陷阱。如果只在ip（仅IPv4）表里添加规则，而客户端实际通过IPv6连接，规则自然就失效了。这也是为什么一开始就推荐使用inet表。
一个更稳妥的写法是：nft add rule inet filter input tcp dport 22 ct state new accept。它明确限定只放行新连接（SYN包），既精准，又提升了安全性。
nft 规则重启后丢失怎么办
通过命令行添加的规则只存在于内存中，系统重启就会消失。实现持久化，标准路径其实很清晰：
- 导出规则到文件：
nft list ruleset > /etc/nftables.conf - 启用系统服务：
systemctl enable nftables。这里需要注意，像RHEL 8+或AlmaLinux这类发行版可能默认已启用，而Debian或Ubuntu则需要先手动安装nftables软件包，再启用服务。 - 检查服务配置：运行
systemctl status nftables，确认“Loaded”一行指向的配置文件路径是/etc/nftables.conf。
记住，不要画蛇添足地使用rc.local或自定义脚本去重新加载规则。nftables服务本身就会在启动时读取/etc/nftables.conf文件并载入规则，额外操作反而容易引入错误。另外，/etc/sysconfig/nftables.conf是旧版RHEL/CentOS 7使用的路径，新版本系统已经统一到了/etc/nftables.conf。
日志和调试最实用的三招
当规则不按预期工作时，光查看nft list的输出可能不够，我们需要确认数据包是否真的“走”到了那条规则。下面三个方法非常实用：
- 使用
counter计数器：在规则后加上counter，例如nft add rule inet filter input tcp dport 22 counter accept。之后通过nft list chain inet filter input查看pktcnt（包计数）和bytecnt（字节计数）是否增长，就能直观判断规则是否被命中。 - 添加
log日志记录：使用nft add rule inet filter input tcp dport 22 log prefix "SSH-ATTEMPT: " counter accept。这样匹配的包会被记录到内核日志，通过journalctl -k | grep "SSH-ATTEMPT"命令可以实时观察连接尝试。 - 结合
tcpdump验证：用tcpdump -i any port 22 and host来确认数据包是否真的到达了本机。再对比nft计数器的数据，就能分辨问题是包被丢弃了，还是根本没匹配上规则。
这里有个关键点：log语句本身不会终止规则的执行，所以它后面必须显式地跟上accept或drop动作。否则，数据包会继续向下匹配，可能被后续的规则意外处理。
说到底，配置nft真正的难点往往不在语法本身，而在于规则顺序、地址簇选择这些设计逻辑，以及忘记了counter和log这两个强大的调试工具。养成一个好习惯：每写完一条关键规则，立刻挂上一个counter验证其是否被命中，这比反复猜测失败原因要高效得多。
