排查NAT网关转发丢包，核心是确认“包在哪一环被丢”：先通过入向/出向抓包定位丢包位置，重点检查conntrack表状态（insert_failed、table full）、NAT/安全策略冲突（iptables规则、安全组、ACL、rp_filter）、MTU与分片问题（ping -M do测试、TCP MSS clamp）。

排查 NAT 网关转发丢包，核心是确认“包在哪一环被丢”——不是看 NAT 是否工作，而是看它在连接建立后、报文转发过程中是否因资源、策略或配置异常而静默丢弃。

先确认是不是 NAT 网关真丢了包

很多“丢包”其实是下游设备（如客户端、后端服务器）或上层协议（如 TCP 重传超时）误判。必须区分：
• 是 NAT 网关自身接口统计显示丢弃（rx_drop / tx_drop / overruns）
• 还是业务侧看到连接失败、响应慢、重传多？
建议在 NAT 网关入向和出向接口分别抓包：
• 入向有包、出向无对应包 → 极可能 NAT 转发环节丢弃
• 入向无包 → 问题在上游（如 ACL、路由、物理链路）
• 出向有包但下游收不到 → 问题在下游或中间链路

重点查 conntrack 表状态

NAT 网关依赖连接跟踪（conntrack）维持五元组映射，这是丢包最常见根因：
• 查失败计数：conntrack -S | grep insert_failed —— 持续增长说明高并发下新建连接插入冲突
• 查表满日志：dmesg | grep "nf_conntrack: table full" 或 journalctl -k | grep "table full"
• 查当前条目数：conntrack -C
• 解决方案：
 – 临时扩容：sysctl -w net.netfilter.nf_conntrack_max=2000000
 – 永久生效：写入 /etc/sysctl.conf
 – 缩短超时：sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300（避免长连接占满）

检查 NAT 规则与安全策略冲突

丢包常不报错，只静默过滤：
• 列出所有 NAT 规则：iptables -t nat -L -n -v（Linux）或查云厂商控制台 SNAT/DNAT 规则命中数
• 检查是否被后续规则拦截：iptables -L -n -v（filter 表）中是否有 DROP/REJECT 匹配到已 NAT 后的流量
• 云环境特别注意：
 – 安全组是否放行“回程流量”的源端口（如 DNAT 到 80，回程包源端口是随机高位端口）
 – 网络 ACL 是否限制了 ephemeral port 范围（通常 32768–65535）
 – 是否启用了“反向路径过滤”（rp_filter=1）导致非对称路由丢包：sysctl net.ipv4.conf.all.rp_filter

验证 MTU 与分片处理能力

NAT 网关若需修改 IP 头（如做 DNAT+SNAT），可能触发分片；若设备禁用分片或 MTU 不一致，大包直接丢弃：
• 在客户端和服务端同时执行：ping -s 1472 -M do 目标IP（1472 + 28 = 1500）
• 若不通，逐步减小 -s 值，定位最小 MTU
• 检查 NAT 网关网卡 MTU：ip link show dev eth0 | grep mtu
• 若使用 VXLAN/GRE 封装，需预留额外开销（如 VXLAN +50 字节），建议主干链路 MTU ≥ 1550
• 关键动作：在 NAT 网关上启用 TCP MSS clamp：iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu