masquerade 和 snat 不是一回事，前者是后者的特化形式：masquerade 自动获取出口接口动态ip并隐含启用conntrack端口映射，snat需手动指定固定源地址且不强制端口重写。
masquerade 和 SNAT 在 nftables 里到底是不是一回事？
不是一回事，但效果高度重叠。在 nftables 中，masquerade 是 snat 的一个特化形式：它自动读取出口接口的当前 IP 地址（比如 DHCP 分配的动态公网 IP），而 snat 必须显式指定固定源地址。这意味着如果你的出口网卡 IP 会变（如家用宽带、云主机弹性 IP 未绑定），用 snat 就会失效，必须换 masquerade。
-
masquerade隐含启用连接跟踪（conntrack）端口映射，适合小规模 NAT；snat不强制端口重写，可保留原始端口（需加to :1024-65535手动控制） - 二者都只能放在
postroutinghook，且仅对已建立连接的**应答包**不重复处理（靠 conntrack 识别） - 性能上无本质差异——底层调用的是同一组 Netfilter NAT hooks，
masquerade多一次接口地址查询，但开销可忽略（纳秒级）
nftables 的 DNAT 和 iptables 的 DNAT 行为一致吗？
基本一致，但触发时机和链位置更严格。nftables 要求 DNAT 规则必须定义在 prerouting 链（或 output 链用于本地发起的请求），且必须属于 nat 类型表；iptables 允许在 INPUT 链做“伪 DNAT”，nftables 明确禁止这种用法。
- 常见错误：
nft add rule ip nat prerouting tcp dport 80 redirect to :8080—— 这是错的，redirect是本机端口转发，不是 DNAT；DNAT 必须用dnat to 192.168.1.100:8080 - DNAT 后，返回包自动完成反向转换，无需额外规则——前提是系统开启 IP 转发（
/proc/sys/net/ipv4/ip_forward = 1）且 conntrack 正常工作 - 如果目标服务在本机，DNAT 到 127.0.0.1 会失败（Linux 内核限制 loopback DNAT），应改用
redirect或调整服务监听地址
为什么把 iptables 的 SNAT 改成 nftables 后，内网机器上不了网？
最常见原因是漏掉了 masquerade 所依赖的隐含前提：没有启用连接跟踪模块，或规则没加在正确的表和链上。
- 检查内核是否加载了必要模块：
lsmod | grep nf_nat应输出nf_nat、nf_nat_masquerade_ipv4（IPv4）或nf_nat_masquerade_ipv6（IPv6） - nftables 的 NAT 规则必须放在
ip或inet地址族的nat表中；写成ip6表却处理 IPv4 流量，或写成filter表，规则直接被忽略 - 典型正确写法：
nft add rule ip nat postrouting ip saddr 192.168.1.0/24 oifname "eth0" masquerade—— 注意oifname是接口名，不是设备别名（如ens3而非eth0），且不能用通配符（oifname != "lo"不生效）
大规模并发场景下，masquerade 比 SNAT 更耗资源吗？
不会。两者在 conntrack 表项生成、哈希查找、NAT 转换等关键路径上完全共用同一套 Netfilter 逻辑。真正影响性能的是连接数规模和 conntrack 表大小，而不是用 masquerade 还是 snat。
- 瓶颈通常出现在：
/proc/sys/net/netfilter/nf_conntrack_max设置过小（默认常为 65536），导致新建连接被丢弃，现象是“间歇性无法上网” -
masquerade在多出口场景下略慢——每次需要查接口 IP，但现代内核已缓存该值，实际差异在微秒级，远低于 TCP 建连开销 - 真正要优化的地方是：用
ct state established,related accept提前放行回程包，避免每包都进 NAT 链；以及关闭不需要的协议跟踪（如禁用nf_conntrack_ftp模块）
最容易被忽略的一点：nftables 的 NAT 规则不支持“条件跳转”，所有匹配都必须在一条规则里写死。比如你想对部分源 IP 做 masquerade、另一部分做 snat，不能像 iptables 那样分两条规则靠顺序控制，而必须拆成两个独立规则并确保它们不冲突——否则第二条规则永远不会执行。
