NAT3为什么联机困难？从Full Cone、RFC5780到OpenWrt HNAT，彻底理解家庭网络NAT机制
NAT3为什么联机困难？从Full Cone、RFC5780到OpenWrt HNAT，彻底理解家庭网络NAT机制
Part1 前言
大家好。几乎所有主机玩家、P2P联机用户、家庭组网爱好者，都遇到过一个绕不开的网络问题：NAT类型受限。
在PlayStation、Xbox、Steam以及各类P2P联机游戏里，我们经常能看到NAT1、NAT2、NAT3的分级提示，其中NAT3几乎等同于联机困难、匹配超时、语音掉线、P2P连接失败。
但网上大多教程只讲“怎么改设置”，很少把底层逻辑讲透，也解答不了几个高频疑问：
- 明明已经申请到公网IP，为什么测试出来还是NAT3？
- Full Cone NAT到底是什么，为什么能显著改善联机体验？
- 开启硬件NAT（HNAT）网速更快，反而会让NAT类型变差？
- RFC3489和RFC5780两套标准，到底有什么本质区别？
本文从NAT基础原理开始，顺着「基础认知 → RFC标准演变 → 行为模型与厂商分级 → 工具自测方法 → NAT3成因 → HNAT与Full Cone关联 → 家庭网络最优方案」的主线完整拆解，把家庭组网、游戏联机、P2P场景里的NAT逻辑一次性讲清楚。
参考资料
- RFC3489、RFC5389、RFC5780等IETF标准文档。
- 国内外关于Full Cone NAT、UDP打洞、STUN协议的技术分析文章。
- 各大路由器厂商（OpenWrt、MediaTek、高通等）关于HNAT/PPE硬件加速的技术文档。
声明
关于NAT技术的分析，本文的资料全来自于公开的网络标准和路由器厂商技术文档，根据自己的经验对大量的零碎技术资料进行归纳整理。如果文章有错误或不合理之处，还希望批评指正，我后续会进行更正。
Part2 技术研究过程
下面从基础原理开始，逐步拆解NAT如何影响P2P联机，以及遇到NAT3时应该如何排查。
图1.2：NAPT地址转换原理图
（展示私有 IP:Port 如何通过路由器映射表转换为公网 IP:Port，NAPT 同时转换地址与端口）
NAT诞生的核心背景：IPv4地址枯竭
互联网初代基于IPv4协议设计，地址长度为32bit，理论总地址量约42亿个。但由于地址分类、保留地址、路由聚合等因素，可实际分配的公网IPv4地址远少于理论数量。随着全球联网设备爆发式增长，公网IP资源早已枯竭，不可能为每一台手机、电脑、NAS、游戏机都分配独立的公网地址。
为了解决这个问题，网络体系中划分出了私有地址段，这类地址仅能在局域网内部使用，无法直接被互联网路由访问。最常见的家庭内网段就是：
192.168.1.0/24
一个典型的家庭网络，内部设备都使用私有地址：
手机：192.168.1.103
电脑：192.168.1.200
NAS：192.168.1.244
游戏机：192.168.1.150
而 NAT（Network Address Translation，网络地址转换） 技术，就是让所有内网设备共享同一个公网IP接入互联网的核心方案。
技术补充
家庭路由器中实际使用的是 NAPT（Network Address Port Translation），通过同时转换IP地址和端口（例如192.168.1.100:50000→122.246.116.13:40001），让多个内网设备共享一个公网IPv4地址访问互联网。实际上家庭路由器不仅负责地址转换，同时承担状态检测防火墙（Stateful Firewall）功能——这正是后文讨论Full Cone与防火墙关系时的重要前提。
NAT的核心工作原理
NAT部署在路由器的出口位置，核心作用是完成「内网私有地址端口 ↔ 公网地址端口」的双向转换，同时维护一张NAT映射表，保证数据包能准确往返。
举一个完整的访问流程：
- 内网设备
192.168.1.100:50000主动向外网发起请求 - 路由器经过NAT转换，将源地址替换为公网
122.246.116.13:40001 - 路由器在映射表中记录：公网40001端口 → 对应内网
192.168.1.100:50000 - 外网数据返回时，路由器查表后将数据包转发回对应的内网设备
简单来说：NAT就是家庭网络的统一出入口“翻译官”。
三种主流的地址转换方式
按照转换对象和适用场景，家庭网络里的NAT主要分为三类。
1. SNAT（源地址转换）
SNAT全称Source NAT，只修改数据包的源IP地址，将内网私有IP替换为公网IP。这是家庭设备主动访问互联网时最常用的模式。
转换示例：192.168.1.100 → 122.246.116.13
2. DNAT（目标地址转换）
DNAT全称Destination NAT，只修改数据包的目标IP地址，用于外网主动访问内网服务，也就是我们常说的「端口转发」。
转换示例：公网 122.246.116.13:27015 → 内网 192.168.1.244:27015
常用于游戏服务器、Web服务、NAS外网访问等场景。
3. MASQUERADE（地址伪装）
MASQUERADE是SNAT的一种特殊形式。区别在于SNAT适用于固定公网IP的场景，而MASQUERADE会自动适配当前的出口IP。在公网地址动态变化的家庭宽带环境中，MASQUERADE较为常见。
为什么NAT类型会直接影响游戏体验？
普通的网页浏览、视频播放、文件下载，都是内网主动发起、外网被动响应的单向请求模式，NAT严格与否基本不影响使用。
但游戏联机、语音通话、P2P传输完全不同——它们需要玩家与玩家之间双向主动建立连接。如果双方都处在NAT后方，就必须经过NAT穿透才能通信。
通常情况下，NAT规则越严格，穿透的成功率就越低。最终表现到用户侧就是：匹配超时、联机失败、游戏丢包、语音断断续续。这也是NAT3之所以“臭名昭著”的根本原因。
图1.3：UDP Hole Punching时序图
（展示两端借助STUN/信令服务器交换映射端口并建立直连全过程）
UDP Hole Punching：P2P是如何穿透NAT的？
在深入NAT分类之前，有必要先理解游戏和P2P应用具体是如何尝试穿透NAT的。
目前最主流的穿透技术是 UDP Hole Punching（UDP打洞），其基本流程如下：
- 玩家A和玩家B分别向STUN服务器发起请求，获取自己的公网IP和端口映射
- 双方通过信令服务器（或游戏匹配系统）交换彼此的公网地址
- A向B的公网地址持续发送UDP包，B也同时向A的公网地址持续发送UDP包
- 双方NAT根据已有UDP映射状态（binding）以及各自的过滤策略（Filtering Policy）共同判断是否允许该外部UDP数据包进入。如果映射仍有效且过滤规则允许，则数据包可以通过
- 双向通道建立后，双方即可直接P2P通信，无需经过中继服务器
这个“打洞”过程对NAT的行为有严格要求：
- 映射行为越稳定（EIM），对方越容易找到正确的公网端口
- 过滤行为越宽松（EIF），对方发来的包越容易被放行
如果NAT存在地址/端口依赖映射，或者过滤策略过于严格，UDP打洞成功率会明显下降——这是传统P2P穿透失败的重要原因之一。
图1.4：NAT1 / NAT2 / NAT3 / NAT4 分级示意图
（对比不同NAT等级在网络拓扑、公网IP状态及P2P联机体验上的差异）
注：PlayStation 官方只有 NAT Type 1/2/3。社区和部分工具会把 Symmetric 额外称为 NAT4，本文技术部分会兼顾两种说法。
早期分型RFC3489：四类经典NAT
早期的RFC3489标准，按照严格程度从低到高，把NAT分成了四类，也对应着联机体验从优到劣。
1. Full Cone NAT（完全锥形NAT）
内网端口一旦映射到公网端口，映射关系就保持固定。对于NAT映射而言，外部任意地址均可以访问该公网映射端口（是否最终进入内网仍取决于防火墙策略）。
- 优势：P2P穿透成功率最高，游戏联机最稳定，适配所有P2P场景
- 劣势：NAT层面的访问限制较少，需要依赖防火墙策略提供额外保护
重要说明
Full Cone NAT描述的是NAT映射行为本身，并不代表防火墙完全开放。实际通信仍然受到路由器的防火墙Zone、INPUT策略、WAN入站规则等独立配置的约束。开启Full Cone不等于“网络裸奔”。
2. Restricted Cone NAT（地址限制锥形NAT）
只有内网设备主动访问过的公网IP，才能反向回传数据，陌生IP会被直接拦截。
比如内网访问过 8.8.8.8，就只允许 8.8.8.8 返回数据，其他地址一律拒绝。
3. Port Restricted Cone NAT（端口限制锥形NAT）
限制进一步升级，必须外网IP + 端口同时匹配，才能反向穿透，陌生端口会被直接拦截。
4. Symmetric NAT（对称型NAT）
访问不同的外部目标时，会生成完全不同的公网端口映射。
比如访问 8.8.8.8 时公网用40000端口，访问 1.1.1.1 时就换成40001端口。
- 优势：安全性最高
- 劣势：NAT穿透极难成功，P2P联机基本失效
注
在RFC3489时代，Symmetric NAT通常被认为是最难穿透的类型；但在现代RFC5780模型中，NAT行为由映射和过滤两个维度共同决定，不能简单用“严格程度”单轴排序。
图2.1：RFC3489四类NAT分类模型
（Full Cone / Restricted / Port Restricted / Symmetric 四类对比，RFC3489已被RFC5389/RFC5780取代）
RFC5780：从“贴标签”到行为判定
RFC3489最大的问题在于：它试图把NAT简单归为固定的四类。
但现实中路由器厂商的实现千差万别，同一台设备访问不同服务器时，NAT行为都可能不一样，固定分型很容易出现误判。
需要说明的是协议演变关系：
RFC3489（STUN Classic，2003年）
↓ 协议被废弃重写
RFC5389（新STUN协议，2008年）
↓ 基于新STUN协议
RFC5780《NAT Behavior Discovery Using STUN》（2010年）
RFC5780的全称是 《NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)》，它是在RFC5389 STUN协议基础上定义的NAT行为发现机制，用于检测NAT的映射行为（Mapping Behavior）和过滤行为（Filtering Behavior）。
简而言之：RFC5780不是RFC5389的“功能扩展”，而是一套基于STUN的测试方法规范，用于精准描述NAT的实际行为。
RFC5780不再笼统地给NAT“贴标签”，而是从两个核心维度去精准描述NAT的行为。因此现代网络研究中，RFC3489中的Full Cone、Symmetric NAT等标签更多用于历史兼容，而RFC5780的行为模型更加准确——这也是本文后续分析的核心框架。
图2.2：RFC5780二维行为模型矩阵
（映射 Behavior × 过滤 Behavior 的 3×3 矩阵。左上角 EIM+EIF 为 Full Cone 最优解，右下角为 Symmetric 联机噩梦）
1. Mapping Behavior（映射行为）
决定内网端口转换成公网端口时的变化规律：
- 端点无关映射（EIM）：无论访问任何外网地址，内网端口对应的公网映射都保持一致（最友好）
- 地址依赖映射（ADM）：公网映射随目标IP变化而变化
- 地址+端口依赖映射（APDM）：公网映射随目标IP和端口共同变化（最严格）
图2.3：Mapping Behavior映射行为对比
（EIM 端口固定不变；ADM 随目标IP变；APDM 随IP+端口都变）
2. Filtering Behavior（过滤行为）
决定外部哪些来源可以反向访问回来：
- 端点无关过滤（EIF）：任何外部来源都可以回连
- 地址依赖过滤（ADF）：只有内网访问过的IP可以回连
- 地址+端口依赖过滤（APDF）：只有访问过的IP+端口可以回连
换句话说，RFC5780不再回答“你是什么NAT”，而是回答“你的NAT映射是否稳定、过滤是否宽松”。
一个关键认知：NAT行为 vs 游戏NAT等级
在继续往下读之前，有必要先厘清一个容易被混淆的概念：
RFC5780描述的是NAT的底层行为（映射+过滤），而游戏厂商的NAT1/2/3描述的是“游戏连接可达性”。
两者的关系是：
RFC5780测试
↓
得出NAT行为（EIM/EIF/ADM/APDF等）
↓
游戏平台根据自身算法
↓
映射为NAT1 / NAT2 / NAT3
- RFC5780是技术标准，描述“NAT实际做了什么”
- NAT1/2/3是应用层评价，描述“游戏能不能连上”
不同平台的映射算法不同，同一个NAT行为在不同游戏平台上可能被标为不同等级。因此在阅读下文对照表时，需理解这只是一个通用参考，而非一一对应的数学公式。
RFC5780行为与游戏NAT1/NAT2/NAT3的参考对应
需要特别说明的是：NAT1/2/3并不是RFC官方标准，是PlayStation、Xbox、Steam等游戏厂商自定义的网络分级，不同平台的判定细则略有差异。
以PlayStation传统定义为例，NAT Type 1通常表示设备直接连接互联网，没有经过路由器NAT（如直接PPPoE拨号、DHCP公网或光猫桥接后设备直连）；在“光猫拨号+路由器二级路由”的典型家庭组网下，即便主路由器拿到了公网IP，内网设备依然属于NAT2或NAT3，极少被标为NAT1。
此外，NAT2覆盖范围较宽。Full Cone NAT通常可以获得最佳的P2P联机体验，但它并不严格等价于NAT2，更准确的说法是——Full Cone是NAT2分级中最优的一种子集。
为了方便对照，下面给出更详细的对应参考：
| 映射行为 | 过滤行为 | 常见厂商分级参考 | 对应早期分型 | 联机体验 |
|---|---|---|---|---|
| 无NAT（公网直连） | 无NAT（公网直连） | NAT1 | —— | 最优 |
| EIM | EIF | 通常对应NAT2（最优子集） | Full Cone | 极佳 |
| EIM | ADF / APDF | 通常对应NAT2（一般情况） | 限制锥形NAT | 良好 |
| ADM / APDM | 严格过滤 | 可能为NAT3 | Symmetric NAT | 差，穿透困难 |
| 任意 | 任意（CGNAT/Double NAT） | 通常为NAT3 | 多层NAT | 差，穿透失败 |
补充说明
上表的对应关系基于绝大多数主流平台的通用判定逻辑，但ADM/APDM并不一定100%对应NAT3，具体取决于游戏平台的测试算法和容忍度。最终请以实际游戏联机表现为准，表格仅作为技术参考。
用NatTypeTester自测NAT等级
讲完标准对应关系，我们可以用工具实际测试自家网络，对照上面的规则精准判断NAT等级。NatTypeTester 是Windows平台一款轻量级的NAT类型检测工具，基于STUN协议实现，支持基于RFC3489的快速分型和NAT行为检测（部分测试项参考RFC5780中的NAT行为发现思想），是玩家和组网爱好者常用的验证工具。
1. 快速测试（RFC3489快速分型）
打开工具后默认进入快速测试页，选择STUN服务器（默认 stun.miwifi.com 即可，也可自行添加公共STUN地址），点击「测试」即可得到结果。
这一页的结果对应RFC3489标准：
- NAT类型：显示
FullCone即完全锥形NAT，是最优结果 - 本地地址/公网地址：本地端口与公网端口一一对应，正是Full Cone NAT的典型特征
- 界面黄色提示「该协议已过时」，正好对应RFC3489被RFC5389替代的历史——仅作快速参考
注意
NatTypeTester的快速测试页基于RFC3489标准，该标准已被废弃，结果仅作为初步参考。精准判断需要切换到行为测试页。
2. 行为测试（基于RFC5780思想）
切换到侧边栏第二个标签页，即可进行更精准的NAT行为检测，分别验证映射行为和过滤行为。游戏联机主要依赖UDP，默认选择UDP协议即可。
各项结果解读：
- 绑定测试 Success：STUN服务器通信正常，测试结果有效
- 映射行为 EndpointIndependent：端点无关映射，公网端口映射稳定
- 过滤行为 EndpointIndependent：端点无关过滤，回连规则最宽松
对照前面的行为模型，这属于Full Cone行为；在多数主机游戏平台中通常会获得NAT2级别的联机体验。
3. 完整自测步骤
- 下载并打开 NatTypeTester
- 在第一页选择STUN服务器(添加stun.miwifi.com 国内stun地址即可)，下拉没有ip选择0.0.0.0/0，点击「测试」，快速获取NAT类型分型
- 切换到行为测试页，分别点击「映射行为」「过滤行为」右侧的播放按钮，获取基于RFC5780思想的精准行为检测结果
- 对照上文的对应表与判定步骤，确定自己的NAT等级与联机兼容性
图1.5：NAT3排查流程图
（从检查公网IP → 消除双重NAT → 开启UPnP → 调整Full Cone → 验证HNAT冲突的完整排查路径）
高频误区：有公网IP不等于一定是NAT2
很多人都有一个误解：只要运营商给了公网IP，网络就一定是NAT1或NAT2。
实际上并非如此。
公网IP只说明路由器WAN口拿到了一个公网地址，但NAT等级的高低，并不只由有没有公网IP决定，它还取决于路由器的映射策略、过滤规则、UPnP状态、防火墙配置。
哪怕路由器有公网IP，只要满足下面任意一条，都可能被判定为NAT3：
- 防火墙过滤策略严格
- 关闭了UPnP且没有手动端口转发
- NAT默认行为是端口限制锥形或对称型
- 运营商侧存在CGNAT（运营商级NAT）或多层NAT（Double NAT），这是移动宽带、校园网以及部分运营商接入环境中导致NAT3的重要原因之一
这也是很多人明明办了公网宽带，联机依然出问题的核心原因。
UPnP / NAT-PMP：自动端口映射的辅助机制
UPnP全称Universal Plug and Play（通用即插即用），它的作用是让内网设备自动向路由器申请端口映射，无需用户手动配置。
比如一款游戏需要使用UDP 50000端口联机，它会自动向路由器发起请求：
请帮我开放公网UDP 50000端口，映射到我这台设备的50000端口
路由器收到合法请求后，会自动创建映射规则，保证联机流量能正常转发回来。
如果没有UPnP，每款游戏、每个P2P软件都需要用户手动配置端口转发，维护成本非常高，也很容易出错。
但需要说明的是，UPnP并非游戏联机的“必须条件”。现代游戏通常同时采用多种手段组合来提高连接成功率：
UDP Hole Punching（NAT打洞）
+ STUN服务器（获取公网映射）
+ UPnP / NAT-PMP（自动端口映射）
+ TURN中继服务器（打洞失败的保底方案）
UPnP主要作用是自动创建端口映射，减少手动配置成本；在部分场景下可以改善入站连接能力，但它并非唯一的通路。
补充
除UPnP外，Apple提出的NAT-PMP（NAT Port Mapping Protocol）以及后续标准化的PCP（Port Control Protocol）也提供类似的自动端口映射能力。UPnP和NAT-PMP在功能上重叠，家用路由器通常至少支持其中一种。
HNAT是什么？为什么开启后可能影响NAT类型
1. HNAT的本质：硬件加速NAT
HNAT全称Hardware NAT，也就是硬件NAT。
软件NAT的转发路径是：
数据包
↓
Linux Kernel
↓
Netfilter / iptables
↓
NAT转换
↓
网络接口
所有地址转换都由CPU负责计算，数据包经过完整的协议栈处理。
而硬件加速（HNAT/Flow Offload）的典型路径是：
首包：
数据包 → Linux Kernel → 建立conntrack → 硬件PPE表项
后续包：
数据包 → PPE硬件引擎 → 直接转发
首次连接仍由CPU建立软件映射表，后续数据包由专用硬件转发芯片完成快速转发，吞吐更高、CPU占用更低，是大带宽路由器的常用功能。
OpenWrt用户注意
OpenWrt中的软件Flow Offloading、硬件Flow Offloading、MediaTek HNAT/PPE虽然目的类似（加速转发），但实现层级不同，不能简单等同：
| 技术 | 位置 | 说明 |
|---|---|---|
| Software Flow Offloading | Linux内核 | 软件层面绕过部分Netfilter处理，降低CPU开销 |
| Hardware Flow Offloading | 驱动/硬件 | 将flow表下发到硬件引擎，由芯片处理后续包 |
| MTK HNAT / PPE | 芯片级硬件引擎 | MediaTek平台专用硬件NAT加速，集成在SoC中 |
2. HNAT与Full Cone NAT的关系
HNAT的目标是极致的转发性能，而Full Cone NAT的目标是宽松的连接行为，两者的设计目标并不完全一致。但HNAT与Full Cone并非必然冲突，具体取决于厂商的硬件NAT实现：
- 部分平台：如果硬件NAT引擎自身实现了对应的EIM/EIF NAT行为，开启HNAT后仍可能保持Full Cone。具体结果取决于BSP、驱动、OpenWrt版本及flow offload实现，不能一概而论。
- 部分平台：HNAT开启后数据包绕过Linux netfilter路径，原本依赖iptables实现的xt_FULLCONENAT模块无法参与转发，NAT行为可能发生变化。
某些实现中，硬件加速路径可能改变NAT映射或过滤行为，使原本的软件NAT行为退化。具体表现取决于硬件引擎和驱动实现，并非所有HNAT都必然导致NAT类型劣化。
.svg)
图2.4：软件NAT vs 硬件NAT路径对比
（左：传统软件NAT完整走Netfilter；右：硬件加速首包建表后后续包直接PPE转发，可能绕过Full Cone规则）
核心结论：HNAT是否影响NAT类型，因平台而异。建议以NatTypeTester实际测试结果为准：
- 若开启HNAT后NAT2保持稳定 → 保持开启
- 若开启HNAT后从NAT2掉到NAT3 → 关闭HNAT
xt_FULLCONENAT：家庭游戏网络的优化组件
xt_FULLCONENAT 是Linux系统下的内核模块，也是开源路由器实现Full Cone NAT的核心组件。但该模块并非Linux内核主线原生自带，也不存在于大多数官方路由器固件中，通常需要第三方固件（如ImmortalWrt、OpenWrt衍生版）或自行编译内核补丁才能获得支持。
OpenWrt生态说明
在OpenWrt生态中，常见实现包括xt_FULLCONENAT、pbr兼容方案以及部分ImmortalWrt集成方案，不同版本和硬件平台的支持情况不同。使用前建议先确认固件是否已包含该模块。
它的作用非常直接：将路由器默认的端口限制锥形NAT，强制调整为完全锥形NAT，让NAT过滤行为更宽松，大幅提升P2P穿透成功率。
技术说明
Full Cone NAT并不是简单“打开一个开关”就能生效。它依赖内核conntrack（连接跟踪）、iptables/nftables的NAT实现框架，以及硬件转发路径是否支持该模块的处理。在开启硬件加速的平台中，如果数据包绕过了netfilter路径，xt_FULLCONENAT可能无法对所有流量生效。
对于主机游戏、Steam联机、点对点传输、语音通话这类场景，它的优化效果非常明显。
但需要理解的是：xt_FULLCONENAT仅改变Linux NAT模块的行为，它本身不是一个“穿透工具”。最终完成P2P连接仍然需要依赖整套技术栈：STUN获取公网映射、ICE协商最优路径、UDP Hole Punching打洞，以及TURN中继服务器作为打洞失败的保底方案。
家庭游戏网络的推荐配置方案
如果你的核心需求是优化主机联机、P2P游戏、NAS外网访问、私人游戏服务器，推荐采用以下组合：
公网IPv4
+ UPnP / NAT-PMP开启
+ Full Cone NAT（如平台支持）
硬件加速方面建议按实际CPU负载取舍：
- 若路由器CPU在软件NAT模式下长期占用超过80%（尤其千兆及以下宽带），可考虑开启HNAT缓解压力
- 若以P2P游戏、主机联机为核心需求，且CPU能扛住软件NAT，优先关闭HNAT以保证Full Cone生效（或确认开启HNAT后NAT2不受影响后再保持开启）
- 最终以NatTypeTester实测结果为准
Part3 总结
最后我们把全文核心结论提炼出来，方便大家快速理解：
-
NAT的核心价值是解决IPv4地址枯竭问题。家庭路由器实际使用的是NAPT（同时转换IP和端口），让多台内网设备共享一个公网IP上网，同时承担状态检测防火墙功能。
-
NAT类型直接决定P2P联机体验。通常情况下，NAT限制越严格，穿透成功率越低；NAT3会导致联机困难。
-
UDP Hole Punching是主流的NAT穿透技术。NAT的映射行为和过滤行为越宽松，打洞成功率越高。
-
RFC标准有明确的演变关系：RFC3489提出四类NAT分型但已被RFC5389替代；RFC5780是基于新STUN协议的NAT行为发现机制，从“映射+过滤”双维度描述NAT。RFC3489中的标签更多用于历史兼容，RFC5780的行为模型更加准确。
-
NAT行为 ≠ 游戏NAT等级。RFC5780是技术标准描述底层行为，NAT1/2/3是应用层评价描述连接可达性，两者是“测试→映射”的关系。
-
NAT2是厂商自定义分级，不等价于Full Cone NAT。Full Cone只是NAT2分级中最优的一种子集。
-
有公网IP ≠ 优质NAT类型。NAT好坏由映射规则、过滤策略、UPnP状态、防火墙配置共同决定，运营商CGNAT是NAT3的重要原因之一。
-
HNAT与Full Cone并非必然冲突，因平台和固件实现而异。OpenWrt中Software/Hardware Flow Offloading和MTK PPE/HNAT实现层级不同，对NAT行为的影响也不同，以实测为准。
-
xt_FULLCONENAT是Linux内核模块，依赖conntrack和netfilter框架，在硬件加速路径下可能无法对所有流量生效。
-
家庭游戏网络的最优解：公网IPv4 + 正确的NAT配置 + UPnP/NAT-PMP开启 + 合理的Full Cone NAT（视平台而定），通常可以获得最佳的联机体验。