加载或修改nftables规则时，nft可能返回Could not process rule: No such file or directory。这里的“文件”经常不是磁盘文件，而是内核规则集中找不到被引用的表、链、集合或规则句柄。
远程VPS修改防火墙前，先保留云控制台或第二条管理通道，并导出当前完整规则集。
这条错误实际指向什么
nftables对象有明确层级：规则属于链，链属于表，表还带有ip、ip6、inet等族。命令引用了不存在的上级对象、集合、映射或旧句柄时，内核会拒绝请求。
相同表名位于不同规则族时也是不同对象。脚本里写table ip filter，不能自动匹配现有的table inet filter。
先列出真实规则集与句柄
先执行nft list ruleset -a，保留表、链、集合以及规则句柄；需要缩小范围时可用nft list tables、nft list table inet filter和nft list chain inet filter input。再将报错命令中的族、表名、链名和集合名逐项对照。
规则句柄会随删除和重建变化，不能把测试机上的handle长期复制到生产脚本。若报错带行列位置，应从该位置向前检查首次引用的对象。
验证文件后再整体加载
规则保存在文件时，先执行nft --check --file /etc/nftables.conf做语法与对象引用检查；通过后再在有回滚通道的维护窗口执行nft --file /etc/nftables.conf。被跳转的自定义链和被引用的集合应先在同一事务中定义。
不要为消除报错而先执行flush ruleset。清空规则会立即移除现有访问控制，也可能切断SSH恢复路径。
修复对象顺序与持久配置
确认对象确实缺失后，在准确的规则族和表中创建表、链或集合，再添加引用它的规则；若只是删除旧规则，应先用当前-a输出取得句柄。由firewalld、容器运行时或其他管理器维护的表，不应同时交给独立脚本接管。
修复应落到系统实际加载的持久配置源。只在命令行临时补对象，重启服务后错误往往会再次出现。
变更后的验收标准
执行nft --check -f和nft list ruleset -a确认对象关系，再从新连接测试SSH、业务端口及预期被拒绝的端口。可在萤光云或LightNode的隔离VPS复现规则族差异。验收标准是规则能完整加载、管理连接不断开、放行与阻断结果符合设计，重启nftables服务后状态一致。
FAQ
问：报错一定是配置文件不存在吗？答：不一定；若文件本身能被读取，错误更常指规则对象或句柄不存在。
问：ip表和inet表能互相引用吗？答：不能把它们视为同一个表；规则族是对象身份的一部分。
问：为什么删除规则时旧handle失效？答：句柄对应当前内核规则对象，重载或重建后应重新查询。
问：可以逐行执行规则文件吗？答：这样可能暴露中间状态；更适合先检查并以完整文件事务加载。
问：修好后重启又失败怎么办？答：检查服务实际读取的文件，以及firewalld、容器运行时等是否同时管理同一对象。
温馨提示
温馨提示：每次变更前保存带句柄的规则集和已验证配置副本。涉及默认拒绝策略时，安排可自动恢复的回滚方案，并始终保持带外控制台可用。
