打开一个电商大促页面，秒杀开始那一瞬间，后台可能正扛着每秒几十万的请求。这时候你猜——它家服务器还在用NAT（网络地址转换）做出口网关吗？
先说答案：基本不用了
不是NAT不行，而是大型网站早就不靠它来解决“地址不够”或“安全隔离”这类问题了。NAT在家庭路由器、中小公司出口防火墙里很常见，但到了BAT级别、头部云厂商、或者自建超大规模IDC的场景，它反而成了性能瓶颈和运维负担。
为什么不用？三个现实原因
第一，端口耗尽太要命。传统NAT设备靠四元组（源IP+源端口+目标IP+目标端口）做映射。一台Web服务器对外发起连接时，比如调用下游订单服务、缓存、日志中心……每个连接都要占一个NAT端口。Linux默认可用端口范围是32768–65535，也就3万多。高并发下，几台机器一齐发请求，很容易就卡在“Cannot assign requested address”上。
第二，连接跟踪（conntrack）成定时炸弹。NAT必须维护一张连接状态表。当QPS破万、连接生命周期又短（比如HTTP/1.1短连接），这张表会疯狂膨胀。某次线上故障排查发现，一台NAT网关的conntrack表项突破百万，CPU软中断直接飙到90%，新连接建立延迟从几毫秒涨到2秒以上。
第三，调试和监控变复杂。后端服务查日志，看到的源IP全是NAT设备的内网地址；链路追踪里，真实客户端IP被抹掉；做限流、封禁、地域分析，全得靠X-Forwarded-For这种不可信头字段补救——而这些头还能被伪造。
那他们用什么？
主流做法是：公网直通 + 云原生网络模型。
比如阿里云的ENI多IP模式、AWS的Elastic IP绑定、腾讯云的弹性网卡直挂公网——每台应用服务器都配一个或多个真实公网IP，流量直入直出，不经过集中NAT网关。再配合BGP Anycast、Anycast DNS、智能DNS调度，把用户请求就近分发到有公网IP的节点。
内部通信更干脆：IDC里用大二层或VXLAN覆盖网络，所有服务器走私网互通，根本不需要NAT；对外出口则由高性能LB（如LVS+Keepalived或自研DPDK负载均衡器）做七层转发，只负责分发，不改源IP。
顺手看个对比
小型公司办公网出口：
PC（192.168.1.10） → 路由器NAT → 公网大型网站生产环境：
用户 → Anycast BGP → LVS集群（DR模式，不改IP） → Web服务器（100.64.1.100，带EIP）注意：这里的100.64.1.100是RFC 6598定义的共享地址空间（CGNAT段），但它不是靠NAT转换出去的，而是运营商直接路由到你的机房，属于“可路由私网IP+公网EIP”的混合方案。
例外情况也有
不是绝对不用。比如某些老旧系统迁移过渡期，或边缘计算节点需要复用少量公网IP接入中心管控平台，仍会部署轻量级SNAT规则。但这类NAT是“临时通道”，不是核心流量路径，配置也尽量精简——比如只对特定目标IP段做转换，避免全局conntrack介入。
所以别听人说“NAT是网络安全基石”，对大型网站来说，真正的安全来自零信任架构、微隔离、服务网格mTLS，而不是靠藏IP来糊弄扫描器。