nftables 不监听接口状态变化，其规则静态生效且依赖数据包当前属性匹配；可通过 systemd 服务重载、命名集动态更新、meta iiftype/iifkind 匹配接口类型三种方式实现策略自动适配。
nftables 本身不监听或响应系统网络接口的运行状态变化（如 up/down、地址增删、link flap），它没有内置的“接口热插拔事件驱动机制”。它的规则在内核 netfilter 框架中静态加载并持续生效，所有匹配逻辑基于数据包到达时的当前上下文（如 iifname、oifname、ip saddr 等字段值），而非主动感知接口启停。
但你可以通过组合 nftables 与外部机制，实现对接口状态变化的策略自动适配。关键在于：nftables 规则不变，而规则中引用的动态元素（如命名集、接口名、变量）可被外部程序实时更新。
以下是最常用、最可靠的三种实践方式：
接口名硬编码规则 + systemd 服务联动重启
适用于接口名固定（如 eth0、ens33）、且能接受短暂策略中断的场景。
当接口 down 后又 up，若其 IP 或路由变更，原有规则仍有效（因 iifname 匹配的是设备名，不是 IP）。但若需根据新 IP 调整规则（如仅允许某子网访问），则需触发重载：
- 编写
nft规则时，用iifname "eth0"显式限定物理接口 - 创建 systemd service（如
/etc/systemd/system/nft-reload-on-eth0.service），监听network-online.target或使用udev规则捕获netdev事件 - 在 service 的
ExecStart=中调用nft -f /etc/nftables.conf重载完整配置 - 注意：此方式有毫秒级丢包风险，不适合高可用服务
使用命名集（named sets）动态绑定接口关联地址
这是推荐做法——解耦规则与具体地址，让规则保持稳定，只更新数据。
# 创建一个动态地址集
nft add set inet filter trusted_if_addrs { type ipv4_addr\; }
# 规则中引用该集（不依赖接口是否 up，只看包源地址是否在集中）
nft add rule inet filter input ip saddr @trusted_if_addrs accept
# 当 eth0 获取新 IP（如 DHCP 更新），由 dhcpcd/dhclient 脚本执行：
nft add element inet filter trusted_if_addrs { 192.168.1.100 }
nft delete element inet filter trusted_if_addrs { 192.168.1.99 }-
@trusted_if_addrs是实时生效的集合，增删元素无需 reload 规则 - 可配合 NetworkManager 的
dispatcher.d脚本或systemd-networkd的.network文件中的[Network]→ConfigureWithoutCarrier=yes+Address=配置自动同步
利用 meta iiftype / iifkind 匹配虚拟/逻辑接口类型
对容器、桥接、bond、vlan 等动态接口更鲁棒：
# 允许所有桥接接口（br0, docker0, cni0）入向流量 nft add rule inet filter input meta iiftype bridge accept # 拒绝所有 bond 接口上的新连接请求（防止误用） nft add rule inet filter input meta iiftype bond ct state new drop # 匹配 vlan 子接口（需内核 >= 5.10） nft add rule inet filter input meta iifkind "vlan" ip protocol icmp icmp type echo-request drop
-
iiftype和iifkind是内核提供的元数据，随 skb 生成即确定，不依赖用户空间状态同步 - 即使
br0临时无 IP 或未启用 STP，只要数据包经该接口进入，规则即匹配
不需要为每个接口单独写规则，也不必监听 ip link 输出变化。
nftables 的设计哲学是“数据包即事实”，它只关心此刻流经它的包携带什么属性。接口状态变化本身不是事件源，而是影响后续包的 iifname、ip saddr 或 meta iiftype 值。真正要做的，是让这些字段的表达方式足够健壮——用类型代替名字，用集代替字面量，用钩子位置代替轮询。
