Hostease 专区实测讨论：nftables 链与表管理实战：服务器防火墙规则编写与验证需要验证哪些指标

对运行在 VPS（虚拟专用服务器）或独立服务器上的业务来说，防火墙是暴露在公网的第一道防线。配置错了可能直接导致业务不可达，甚至服务器失守。这篇指南教你掌握 nftables 的“表-链-规则”三层管理方式，并学会编写、加载、验证一套能回滚的服务器防火墙规则，避免只背几条命令却不知道如何验证。

先说结论：nftables 是取代 iptables 的下一代 Linux 内核防火墙框架，核心设计是表按地址族划分、链决定数据包处理阶段、规则按顺序匹配。相比 iptables 把规则分散在多张内置表里，nftables 的层级更清晰、脚本化更强。如果你正在选型，也可以先看 VPS主机 分类里的基础方案，再用同一套方法验证稳定性。

TL;DR：先理解三层结构，再动手写规则

我通常用三条线判断一套 nftables 规则是否合格：结构是否清晰、顺序是否正确、验证与回滚是否到位。结构上，表按协议分域、链按处理阶段组织、规则按顺序匹配；顺序上，先放行既有连接、再管理新建连接、默认策略兜底；验证上，改动前备份、改动后校验、必要时回滚。

• 表（table）：按地址族划分的规则容器，如 inet 同时覆盖 IPv4 和 IPv6。
• 链（chain）：规则的有序集合，基链绑定钩子与策略，普通链只作跳转目标。
• 规则（rule）：匹配条件加动作的条目，命中即执行 accept、drop 等动作。

下面用一台 Debian 12 的服务器做示例，命令适用于多数 Linux 发行版。

一、表与链的创建和管理

创建一张表需要指定地址族与表名。地址族决定这张表处理哪种数据包：inet 同时覆盖 IPv4 和 IPv6，ip 只处理 IPv4，ip6 只处理 IPv6，netdev 用于网卡入口。日常服务器建议优先用 inet，避免 IPv4 与 IPv6 各写一套。

nft add table inet filter
nft list tables
nft list table inet filter

上面第一条命令创建名为 filter 的表，第二条列出所有表，第三条查看表内结构。表名可自定义，但建议保持语义清晰，比如 filter 放过滤规则、nat 放地址转换规则，互不混用。

链分两种：基链（base chain）和普通链。基链需要绑定钩子（hook，数据包在内核中经过的特定处理点，如 input、forward、output）与策略（policy），是数据包真正会流经的链；普通链只作为跳转目标，帮助把复杂规则拆成可复用的片段。创建一条绑定到 input 钩子的基链示例如下：

nft add chain inet filter input '{ type filter hook input priority 0; policy accept; }'

这里 type filter 表示过滤型链，hook input 表示处理进入本机的数据包，priority 0 表示在同类钩子中的执行顺序，policy accept 是链内没有任何规则命中时的默认动作。优先级数值越小越先执行，多个钩子重叠时要留意这一点，避免规则被其他链的 drop 抢先。

二、规则的编写与顺序

规则由匹配条件与动作组成，nft 命令把规则追加到链尾，规则按自上而下的顺序匹配，命中的第一条决定结果。下面为 input 链添加一条放行 22 端口（SSH）的规则：

nft add rule inet filter input tcp dport 22 accept

这条规则匹配 TCP 目的端口 22 并放行。若想插入到链的特定位置而非末尾，用 insert 或指定 handle（句柄，规则的唯一编号）插入。规则的顺序非常关键：如果先写了一条 drop all 的默认拒绝规则，再往链尾追加放行 22 的规则，放行永远不会生效，因为数据包在到达放行规则前已经被丢弃。

多条件组合可以用逻辑运算符。下面这条规则放行来自内网网段对 3306 端口的访问，其余来源一律由后面的默认策略处理：

nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport 3306 accept

ip saddr 指定源地址，192.168.1.0/24 是内网网段示例。规则里可以组合源地址、目的地址、端口、协议、接口（interface，网卡名称）等多个维度，例如 iifname 限制入口网卡、ct state 匹配连接状态，让放行范围精确到最小权限。

端口变化频繁或要统一管理放行清单时，可以用命名集合（named set）把多个地址或端口放进一个集合，规则里直接引用集合名，后续只需改集合而不用改每条规则，降低误改风险。

三、NAT 与状态跟踪

除了过滤，nftables 也承担 NAT（Network Address Translation，网络地址转换）工作。NAT 链通常放在名为 nat 的表中，绑定 postrouting 或 prerouting 钩子。典型的出站源地址转换（把内网地址转成出口公网地址）写法如下：

nft add table ip nat
nft add chain ip nat postrouting '{ type nat hook postrouting priority 100; }'
nft add rule ip nat postrouting ip saddr 10.0.0.0/24 masquerade

masquerade 适合出口地址动态变化的场景，它会自动取当前出接口地址作为转换后的源地址。若出口地址固定，可以用 snat 指定具体地址。这里 10.0.0.0/24 是内网网段示例，实际按你的网络填写。注意 NAT 与过滤是不同的表，改 NAT 不会影响过滤链，两者配合时先理清数据包流向再写，避免出现“过滤放行了但 NAT 没配”或反之的漏网情况。

状态跟踪（stateful tracking）是防火墙高效放行的关键。通过 ct state 可以只对“新建连接”做严格判断，已建立或相关的回包直接放行，避免为每个回包写单独规则。典型写法是在 input 链开头放行 established 与 related 状态，只对 new 状态做业务规则匹配。

四、规则的持久化与加载

nft 命令的修改只在内存中生效，重启后丢失。要让规则在开机时自动恢复，需要把当前规则集导出成脚本并配置开机加载。查看完整规则集并保存：

nft list ruleset > /etc/nftables.conf
systemctl enable nftables
systemctl restart nftables

/etc/nftables.conf 是 nftables 服务的默认加载文件，systemd（Linux 的服务管理框架）会按该文件在开机时重建规则。改规则的正确流程是：先编辑脚本文件，再用 nft -f 语法检查，最后用 systemctl reload 或重启服务加载，避免直接敲命令导致脚本与实际状态脱节。

保存前务必确认脚本语法无误。可以用 nft -c -f /etc/nftables.conf 做一次只检查不生效的语法校验（-c 表示 check）。若加载后发现自己被锁在服务器外，多半是规则顺序或默认策略把 SSH 也拒绝了，所以任何防火墙改动都要保留一个可回滚的手段，具体排错方法见下一节。

五、规则验证与安全回滚

防火墙上线前必须验证，否则一次手误就可能让整个业务不可达。最稳妥的做法是“脚本化 + 定时回滚”：把规则写进脚本，加载前记录当前规则集哈希，加载后启动一个延迟定时器，若在倒计时内未手动确认，就自动恢复旧规则。下面是一个可选的回滚辅助思路：

# 备份当前规则
nft list ruleset > /root/fw_backup.conf
# 加载新规则
nft -f /etc/nftables.conf
# 倒计时后若未确认则恢复
sleep 60 && nft -f /root/fw_backup.conf

上面的 60 秒属于示例值，可按你的排障速度调整。实际更推荐的做法是开两个 SSH 会话：一个会话加载新规则，另一个会话保持心跳连接，一旦发现断开立即用备份恢复。恢复前先用 nft list ruleset 对比规则是否与预期一致，确认是新规则导致的问题再回滚。

排查连通性问题时，先分清是规则放行、路由还是监听问题。用 nft list chain inet filter input 查看链内规则与命中计数，观察数据包是否被规则 drop。若计数不增长，说明数据包根本没到这条链，应转向查路由或服务监听。

如果服务器需要通过监控持续观察端口与流量变化，可以把关键端口的状态接入告警体系，这样防火墙规则变更后，业务指标是否有异常波动一目了然。需要同时管理多台服务器的防火墙基线时，还可以参考配置快照与恢复点的管理思路，为每台机器的规则集保留可追溯的版本。

总结：把验证指标写进验收清单

总结一下，nftables 防火墙管理的核心是把握三层结构：表按协议分域、链按处理阶段组织、规则按顺序匹配。写规则要遵循“先放行既有连接、再管理新建连接、默认策略兜底”的顺序，改动前备份、改动后验证、必要时回滚。对重视中文沟通和跨境线路的用户，Hostease 这类带中文支持的服务商沟通成本会低一些，但最终仍要以实测数据为准。

如果你需要同时管理多台服务器，也可以参考 服务器排名 分类里的选型文章，结合 香港高防云服务器（云服务器（即按需分配计算资源的虚拟化主机））的对比，把防火墙基线统一到一套可复用的脚本里。只要坚持“先验证再生效、留好回滚”这两条，nftables 完全可以安全地承担服务器的网络边界防护。