snat不生效的根源在于流量未到达nat网关：需确认网关已绑定子网和公网ip、路由指向正确、指标显示连接未建立或丢包，同时排除客户端conntrack残留干扰。

SNAT不生效，不是规则没写，而是流量根本没走到那一步。排查要从数据平面出发，看包是否真被转换，而不是只盯着配置文件。

确认NAT网关已正确绑定子网和公网IP

这是最基础但常被跳过的环节。NAT网关必须显式关联子网（即“出站流量来源”）和至少一个公网IP（用于地址替换），缺一不可。

• 检查Azure门户或CLI中该NAT网关的“子网关联”列表，确保目标虚拟机所在子网已加入
• 查看“公共IP地址”部分：至少有一个IP状态为“已分配”，且未被其他资源（如负载均衡器、公网IP直挂ECS）独占
• 若近期移除了IP或解绑了子网，会直接导致所有SNAT流量静默失败——此时无错误日志，只有连接超时

验证流量路径是否真正经过NAT网关

即使NAT网关存在，若路由未指向它，流量仍走默认路径（比如直连Internet或经其他网关），SNAT自然不会触发。

• 登录受影响的ECS实例，执行ip route show，确认默认路由（default via）下一跳是NAT网关的内部接口地址（通常为子网网关地址，如10.0.0.1）
• 检查VPC路由表：是否存在优先级更高、目的地址更具体的路由（如0.0.0.0/0指向另一个网关），覆盖了NAT网关路由
• 特别注意：某些场景下，实例设置了自定义路由或策略路由，绕过了系统默认路由，需单独检查ip rule show和ip route show table xxx

查指标：用数据说话，定位是端口耗尽还是规则未命中

不要猜，直接看NAT网关暴露的实时指标。关键看三项：

• SNAT连接总数：若接近单IP 50,000上限（或16个IP合计逼近200万），说明端口耗尽；若数值很低但连接失败，说明根本没建立连接
• 失败的SNAT连接数：非零值直接指向SNAT端口不足或连接限制已达阈值
• 丢弃的数据包：若与连接失败时间点强相关，可能是底层路径异常（如子网未关联、IP未就绪）导致包被内核丢弃，而非NAT处理失败

排除客户端侧干扰：确认不是本地连接跟踪残留

对Linux类客户端（如跳板机、容器节点），已有连接可能缓存在conntrack中，新SNAT规则对其无效。

• 在客户端执行conntrack -L | grep "src=内网IP"，确认是否有旧连接残留
• 临时清空对应连接：conntrack -D -s 内网IP（慎用，会中断活跃连接）
• 测试时尽量用新源端口发起连接（如curl --local-port 10001 http://example.com），避免复用旧五元组