概述：你手机上网用的那个“公网IP”，很可能不是你一个人的——它背后挤着几百上千个用户。这一切的幕后装置叫 CGNAT（运营商级NAT）。它平时安静，一出问题就是最刁钻的那类：单用户可复现、批量难归因，“部分网站打不开”“游戏联机失败”“账号莫名被封”全是它的锅。本文以 IETF 两份核心文档——RFC 6269《Common Issues with IP Address Sharing》与 RFC 7422《Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments》——为解读主轴，把 CGNAT 的原理账、故障账和日志合规账一次算清，并给出一份一线排查流程与经验清单。读者对象：核心网/数通运维工程师、网络优化与支撑系统同事。

目录

• 一、先算账：为什么一千人挤一个IP
• 二、五分钟原理：NAT444、地址池与端口块
• 三、四类高频故障：全都写在RFC里的坑
• 四、日志海啸：合规账单与RFC 7422的算术
• 五、一次典型排查的完整推演
• 六、写给同行的十条经验
• 结语

一、先算账：为什么一千人挤一个IP

IPv4 只有约 43 亿个地址，而全球联网设备早已是百亿量级。这场枯竭是有明确时间表的：APNIC（亚太）在 2011 年 4 月用完最后一个 /8，RIPE NCC（欧洲）在 2012 年 9 月见底，ARIN（北美）2015 年 9 月宣告枯竭，2019 年 11 月 RIPE 分完最后的 /22，自由池彻底清零。此后想拿新地址只有一条路——去 IPv4 交易市场买二手，据行业交易报道，单个地址价格已炒到几十美元，一个 /24 卖出上百万美元的新闻并不稀奇。

对运营商来说，账很好算：一千万宽带用户，如果人手一个公网IP，光买地址就是一笔天文数字，而且有钱也未必买得到。于是行业找到了那个心照不宣的答案：用户侧发私网地址，出口处做一次大地址翻译。这就是 CGNAT（Carrier-Grade NAT），也叫 NAT444——用户私网、运营商侧再来一层NAT，一个公网IP背后叠几百上千个用户。

移动网更彻底。3GPP 体系下 UE 拿到的 IPv4 地址本来就是运营商内网地址（10/8 居多），所有流量从 PGW/UPF 出来后几乎必然要过一道NAT才能访问互联网。换句话说，在移动核心网干活的工程师，你的用户每天都在 CGNAT 后面，只是它不出事时没人记得它。

有一个容易被忽略的细节：IETF 专门为 CGNAT 的内层划了一个段——100.64.0.0/10（RFC 6598，“共享地址空间”）。你在现网看到用户地址是 100.64.x.x，基本可以断定这是 CGNAT 架构，而它既不是私网地址也不是公网地址，防火墙策略、路由规划、日志系统稍不留神就会把它当普通地址处理，埋下第一批坑。

二、五分钟原理：NAT444、地址池与端口块

CGNAT 的本质不复杂：把「用户私网IP + 端口」映射到「公网IP + 公网端口」，靠一张会话表维持状态。真正的工程含量全在参数里。

先说三个关键构件：

• 地址池：对外可用的公网IP集合。注意公网IP的 TCP/UDP 可用端口约 64K，一个IP理论上限也就六万多个并发端口，池子大小直接决定并发容量。
• 端口块（port-block）：为了管理和溯源，多数部署把一个公网IP的端口切成块（比如每块 1024 或 4096 个端口），按块分给用户。一个 4096 端口的块意味着一个IP最多服务 16 个用户。
• 会话表：五元组映射 + 超时定时器。表容量和超时时间是 CGNAT 的两大命门。

表1：CGNAT 行为基线（IETF 标准要求摘录）

需要说明：上表是标准给所有 CGN 实现划的公共基线，具体默认值与可调范围，标准允许多种实现，以各厂家官方文档为准。但现网最大的教训恰恰在于——很多设备出厂默认值并不落在基线上。笔者见过 TCP ESTABLISHED 超时被配成一小时、UDP 只有 30 秒的现网配置，省的是会话表内存，坑掉的是全网的长连接和推送通道。

三、四类高频故障：全都写在RFC里的坑

RFC 6269 专门用一整篇文档罗列了地址共享的“副作用清单”。对照一线经验，故障基本逃不出四类：

第一类：端口与会话耗尽。 单用户被分配的端口块用完，新连接建不起来——典型表现是“网页一半打得开一半打不开”、下载到一半速率骤降。更隐蔽的是病毒或P2P类应用在端口块内疯狂建会话，把同块用户的额度也吃光。RFC 6888 为此专门要求 CGN 具备按用户限制会话数的能力，这条要求落地与否，直接决定你是“精准限流一个异常用户”还是“全区域用户陪葬”。

第二类：超时配置失当。 手机端的即时消息、推送、心跳全靠长连接活着。UDP 超时太短，连接被反复掐断重建，用户感知是“消息要等、推送迟半天”，后台感觉是信令量莫名上涨（重连风暴），终端电池加速耗电。这类故障最冤：锅出现在 CGNAT，投诉却全砸在无线和核心网头上。

第三类：回环与ALG。 同一个 CGNAT 后面两个用户互访，报文本应“绕回”内部完成翻译（hairpinning）。这一项支持不佳时，用户访问同城同区域的服务反而绕出去绕不回来。ALG（应用层网关）则是另一个雷区：SIP、FTP 这类报文里内嵌地址协议的应用，ALG 自作聪明改写内嵌地址，改错了就表现为“注册成功通话单通”“传真必失败”。

第四类：误伤与信誉污染。 这是 CGNAT 最反直觉的一类。一个公网IP后面一千个人，前任干了坏事，IP 进了黑名单，继任者无辜背锅——发邮件被反垃圾系统拦截（Spamhaus 的 PBL 名单从设计上就默认“共享地址段不该直接发信”）、访问网站疯狂弹验证码、游戏或社交账号被平台风控误封。RFC 6269 还专门点名了执法场景：靠 IP 追踪当事人，在地址共享时代可能定位到一整批无辜用户，溯源必须依赖运营商的映射日志。

表2：症状速查表（一线经验版）

四、日志海啸：合规账单与RFC 7422的算术

如果说前三类故障是技术账，这一节是钱袋账，也是 CGNAT 运维最重的负担。

《中华人民共和国网络安全法》第二十一条要求网络日志留存不少于六个月。对 CGNAT 来说，这条规定的杀伤力在于：动态分配模式下，每一次地址翻译都必须记日志，否则出了事无法回答“当时这个公网端口是谁的”。RFC 6888 同样把可溯源的日志能力列为 CGN 的硬性要求。

来算一笔账（以下为笔者按经验参数的估算，仅供量级参考）：一百万在线用户，人均每天产生约 1500 条NAT会话日志，每条含双端五元组与时间戳约 250 字节——

• 每天原始日志：100万 × 1500 × 250B ≈ 375 GB
• 六个月留存：约 68 TB
• 这还只是裸数据。日志进 Elasticsearch 这类系统，索引膨胀和副本通常再乘 2～3 倍，存储与检索成本直接翻上 150～200 TB 量级，还不算为支撑查询而常年运转的计算资源。

这就是 2015 年 IETF 发布 RFC 7422 的动机。它的思路一句话能说清：把“动态随机分配 + 全量日志”换成“静态算定 + 极少日志”。每个用户的端口块由算法从地址池中确定性推出，同一时间永远可复算，于是只需要记“哪个用户拿到了哪个块”（分块日志），而不必记每一条会话。RFC 7422 自己给出的算例显示，日志量可以下降几个数量级；代价是用户占用块的时间粒度变粗、并发容量上限被块大小锁死，且映射规则一旦发布就难以频繁调整。

沿 RFC 7422 的思路自行演算一笔：单IP约 64K 可用端口、按 4096 一块，一个IP固定服务 16 个用户；一百万用户约需 6.3 万个公网IP（一个 /16 略多）；分块日志按用户记，一百万条、约 0.25 GB，一次性入库、六个月不增长。与动态方案的每天 375 GB 相比，是三个数量级的差距。

表3：三条技术路线对比

顺带一提 IPv6：它是唯一的终局答案，但从 APNIC 的公开测量看，全球部署率过半的市场也才少数，过渡期里 464XLAT（无状态NAT46+有状态NAT64 组合，部署指南见 RFC 8683）这类方案让“IPv6-only 接入 + 兜底翻译”跑通了手机网络。对运维而言那又是另一套故障域——DNS64 合成地址、应用写死 IPv4 字面量，都是后话。

五、一次典型排查的完整推演

下面这个场景是多起公开报告与一线实践中反复出现的典型模式，细节已做脱敏与通用化处理，但它能完整串起前文所有知识点。

某区域陆续进线：用户反映“网页大部分正常，个别网站打不开”，且主要集中在游戏和社交平台。第一直觉是内容网问题，但跨网站、跨时段都有，排除。第二天投诉升级：有用户发现自己的游戏账号被平台封禁，而他自己坚称什么都没干。

到这里，CGNAT 的嫌疑才浮出水面。排查链如下：

flowchart TD
    A[个别网站打不开投诉] --> B{单用户还是批量}
    B -->|单用户| C[查账号与公网出口IP]
    B -->|批量且同区域| D[查NAT资源池告警]
    C --> E[还原端口块归属记录]
    D --> F{会话表占用率}
    F -->|超阈值| G[端口耗尽或扫描流量]
    F -->|正常| H[比对超时模板基线]
    G --> I[扩池并定位异常源]
    H --> J[按RFC基线调参]
    E --> K{IP是否被外部拉黑}
    K -->|是| L[换池并提交解封申诉]
    K -->|否| M[抓包比对内外映射]
    I --> N[复盘固化告警基线]
    J --> N
    L --> N
    M --> N

推演中的几个关键动作值得展开：

1. 还原归属。 从认证系统取该用户的上线时间窗，再从 CGNAT 的块分配日志确认他在投诉时段占用的公网IP和端口块。动态模式下这一步必须逐会话对日志，确定性模式下直接复算——这也是为什么本文反复强调日志方案选型。
2. 查前科。 拉出同一端口块在该用户之前 24 小时的使用者。典型结论：前任是中毒终端，在块内对目标网站发起了扫描或攻击，目标平台把整个IP/端口段拉黑，继任者全军覆没。误封的账号案也在此告破。
3. 验证翻译行为。 在 CGN 内外两侧同步抓包，比对内层五元组与外层映射，重点看超时是否符合基线、ALG 是否在改写。若发现 UDP 映射远短于 5 分钟，推送延迟的那批投诉同时闭环。
4. 闭环固化。 处置完成不算完：把“单用户会话数”“会话表占用率”“块内信誉变更”固化为告警项和巡检基线，把这次的事故模式写进下一轮预案。标准允许多种实现，各网元的默认参数差异不小，基线必须以自己现网的验证结果为准。

六、写给同行的十条经验

1. 把 CGNAT 纳入核心网故障域，而不是当数通设备甩给数据专业。 移动网里它就是 SGi/Gi 上的必经之路。
2. 超时参数照 RFC 基线过一遍：TCP ESTABLISHED 不低于 7440 秒（RFC 5382），UDP 不短于 2 分钟、建议 5 分钟量级（RFC 4787）。任何想调短的冲动，先想想重连风暴。
3. 按用户限会话是必配项（RFC 6888 要求项），否则一个中毒终端能拖垮整个端口块。
4. 日志方案在建设期就要选：用户规模上了百万级，动态全量日志的存储账单会逼你重构，RFC 7422 的确定性方案宜早不宜迟。
5. 100.64.0.0/10 单独建地址组策略，别和 RFC1918 私网混在一个安全域里。
6. 建一份“IP信誉”视角的监控：出口IP被外部拉黑，要能告警到运维而不是等用户投诉。
7. ALG 默认关闭、按需开启，每开一个都要有对应的回归验证。
8. 投诉分类里加一条“部分网站/平台异常”的标记，它是最典型的 CGNAT 症状指纹，能帮一线少走三天弯路。
9. hairpinning 上线前实测，尤其同城有自建业务节点时，回环路径的性能经常被高估。
10. IPv6 是唯一的解药。每多一分 IPv6 流量占比，CGNAT 的会话表、日志和误伤面就小一分。

结语

CGNAT 是 IPv4 时代运营商给全行业上的最后一道补丁：它让几十亿人挤在 43 亿个地址里继续上网，也把地址稀缺的代价转化成了日志成本、排障复杂度和“连坐式误伤”。RFC 6269 早就把这份代价清单写得明明白白，RFC 7422 则给出了工程上最划算的对冲。对一线工程师，它不值得怕，只值得被认真对待——把参数锚在标准基线上、把日志账在建设期就算清、把“千人一IP”的副作用写进告警基线，CGNAT 就会重新变回那个安静的隐形人。而在地平线上，IPv6 每涨一个百分点，这道补丁就离退役近一步。

参考来源

1. RFC 6269: Common Issues with IP Address Sharing — IETF 对地址共享副作用的最权威清单：应用破坏、黑名单误伤、地理定位漂移、执法溯源难题，本文第三节的主轴
2. RFC 7422: Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments — 确定性NAT降日志的标准方案，含官方算例，本文第四节主轴
3. RFC 4787: NAT Behavioral Requirements for Unicast UDP — UDP 映射方式、保活时长与回环要求的出处
4. RFC 5382: NAT Behavioral Requirements for TCP — TCP ESTABLISHED 7440 秒超时基线的出处
5. RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs) — CGN 按用户限制与可溯源日志能力的合规要求

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。