videocalling
glossary.backToGlossary
NAT（网络地址转换）

NAT（网络地址转换）

技术

允许多个设备共享单个公网 IP 地址的技术

什么是 NAT？

网络地址转换（Network Address Translation，简称 NAT）是一种网络技术，允许私有网络上的多个设备在访问互联网时共享单个公网 IP 地址。可以把 NAT 想象成大型办公楼的前台——外部访客只看到一个地址（楼的地址），而内部有数百个独立办公室，各有自己的内部编号。

你的家庭路由器使用 NAT 让笔记本电脑、手机、智能电视和其他设备通过 ISP 提供的一个公网 IP 地址访问互联网。每个设备获得一个私有 IP 地址（如 192.168.1.100、192.168.1.101 等），仅在本地网络内有效。当这些设备与互联网通信时，路由器将其私有地址转换为公网地址，并跟踪每个连接属于哪个设备。

虽然 NAT 解决了 IPv4 地址耗尽的关键问题，但它给 WebRTC 视频通话等点对点应用带来了重大挑战。理解 NAT 对于理解 STUN 和 TURN 服务器存在的原因至关重要。

NAT 存在的原因

互联网设计时使用 IPv4 地址——32 位数字，可以提供约 43 亿个唯一地址。在 1980 年代，这似乎取之不尽。但随着智能手机、物联网设备以及每个家庭的多个联网设备，我们早已耗尽了 IPv4 地址。

NAT 作为实用的解决方案应运而生：不是给每个设备分配公网 IP 地址，而是给每个家庭或组织一个公网 IP，让路由器在内部管理私有 IP 地址。这将 IPv4 耗尽推迟了数十年，即使 IPv6 逐步推出（IPv6 将消除 NAT 的需求，但截至 2025 年全球采用率仍低于 40%），NAT 仍然是主流方法。

NAT 还提供了安全优势：NAT 后面的设备默认情况下无法从互联网直接访问，形成了天然防火墙，阻止未经请求的传入连接。

NAT 工作原理：转换过程

出站连接

当你的笔记本电脑（私有 IP 192.168.1.100）向网站发出请求时：

  1. 笔记本电脑发送源地址为 192.168.1.100:54321（私有 IP 和随机端口）、目标地址为 93.184.216.34:443（网站的公网 IP 和 HTTPS 端口）的数据包
  2. 路由器接收此数据包，将源地址替换为自己的公网 IP 和分配的端口，比如 203.0.113.45:60001
  3. 路由器在其 NAT 表中记录此映射：192.168.1.100:54321 ↔ 203.0.113.45:60001
  4. 数据包到达网站服务器，服务器看到的源地址是 203.0.113.45:60001，完全不知道它实际来自私有网络

入站响应

当网站响应时：

  1. 响应数据包的目标地址是 203.0.113.45:60001
  2. 路由器在其 NAT 表中查找端口 60001，发现它映射到 192.168.1.100:54321
  3. 路由器将目标地址替换为私有 IP，并将数据包转发给你的笔记本电脑
  4. 笔记本电脑收到响应，一切无缝运行

这对于你发起连接的客户端-服务器通信完美有效。但它破坏了点对点连接。

点对点连接问题

想象你想与朋友开始 WebRTC 视频通话。你们都在 NAT 路由器后面。你不能告诉朋友连接到 192.168.1.100，因为那是私有地址——它在公共互联网上不存在，即使存在，数百万网络也使用相同的私有 IP 范围。

即使你分享了路由器的公网 IP，还有另一个问题：路由器的 NAT 表只有你发起的连接的映射。如果你的朋友尝试向你路由器的公网 IP 发送数据包，路由器不知道应该将其路由到哪个内部设备，会丢弃该数据包。

这是 WebRTC 的根本 NAT 问题：两个对等点都只能通过其路由器的公网 IP 访问，但路由器都不知道如何将传入的点对点连接尝试路由到正确的内部设备。

NAT 类型

并非所有 NAT 实现都相同。不同的 NAT 类型对 WebRTC 连接成功率的影响截然不同。关键区别在于锥形 NAT（宽松）和对称 NAT（严格）。

完全锥形 NAT

最宽松的类型。一旦路由器创建了从内部 IP:端口到外部 IP:端口的映射，任何外部主机都可以向该外部地址发送数据包，它们将被转发到内部设备。

示例：你的笔记本电脑 192.168.1.100:54321 向任何地方发送数据包，路由器将其映射到 203.0.113.45:60001。现在任何互联网主机都可以向 203.0.113.45:60001 发送数据包并到达你的笔记本电脑。

WebRTC 影响：STUN 完美工作。你可以发现公网地址并与可以直接连接的对等点分享。成功率：约 95%。

受限锥形 NAT

稍微严格一些。路由器创建相同的一致映射，但只接受来自内部设备之前联系过的 IP 地址的传入数据包。

示例：你的笔记本电脑向 93.184.216.34 发送数据，创建映射 192.168.1.100:54321 ↔ 203.0.113.45:60001。现在只有 93.184.216.34 可以向端口 60001 发送数据包。任何其他 IP 尝试访问 60001 都会被阻止。

WebRTC 影响：通过 ICE 的同时连接尝试，STUN 仍然有效。两个对等点同时向对方发送数据包，创建必要的映射。成功率：约 85%。

端口受限锥形 NAT

更加严格。类似受限锥形，但还检查源端口。路由器只接受来自内部设备联系的确切 IP:端口组合的传入数据包。

示例：你的笔记本电脑向 93.184.216.34:443 发送数据。只有来自 93.184.216.34:443 的数据包可以通过 NAT 映射到达你的笔记本电脑。来自 93.184.216.34:8080（相同 IP，不同端口）的数据包会被阻止。

WebRTC 影响：通过适当的 ICE 协商，STUN 仍然可以工作，但成功取决于双方对等点的 NAT 类型。成功率：约 75-80%。2025 年大多数消费级路由器表现为端口受限锥形 NAT。

对称 NAT

对 WebRTC 最严格和最有问题的类型。对称 NAT 为每个目的地创建不同的端口映射。当你向不同的外部地址发送数据包时，路由器为每个连接分配不同的外部端口。

示例：你的笔记本电脑 192.168.1.100:54321 向 STUN 服务器 64.233.160.127:19302 发送数据，路由器将其映射到 203.0.113.45:60001。很好！但当你的笔记本电脑向对等点 198.51.100.50:55555 发送数据时，路由器创建了完全不同的映射：203.0.113.45:60002（不同的外部端口）。

问题在于：STUN 发现的是 203.0.113.45:60001，但该地址仅适用于与 STUN 服务器通信。当你与对等点分享此地址并且他们尝试连接时，你实际上是从不同的端口（60002）向他们发送数据，因此连接失败。

WebRTC 影响：STUN 无用。唯一的解决方案是 TURN 中继。没有 TURN 的成功率：约 0%。有 TURN：100%。

现实世界中的 NAT

消费级路由器

大多数家用和小型企业路由器实现端口受限锥形 NAT。这在安全性和连接性之间提供了良好的平衡。Linksys、Netgear、TP-Link 和 ASUS 等品牌通常使用这种方法，这就是为什么 75-85% 的 WebRTC 连接仅使用 STUN 就能成功。

运营商级 NAT（CGNAT）

移动网络和一些 ISP 使用 CGNAT——在 ISP 级别实施的 NAT，以在数百或数千客户之间共享公网 IP。CGNAT 几乎总是对称 NAT，这就是为什么移动 WebRTC 通话经常需要 TURN 中继。

如果你使用移动数据并注意到视频通话通过服务器路由而不是直接连接，CGNAT 可能就是原因。

企业网络

企业网络通常将对称 NAT 与严格防火墙结合使用，使直接的点对点连接几乎不可能。这就是为什么针对企业用户的 WebRTC 应用必须提供充足的 TURN 中继容量——预计 40-50% 的企业用户需要 TURN，而一般消费者使用率为 15-25%。

双重 NAT

一些用户遇到双重 NAT：他们的路由器在 ISP 的路由器后面，或者个人路由器在建筑物路由器后面。这加剧了问题——数据包必须穿越两层 NAT，每层都有自己的映射表。虽然 STUN 有时仍然可以工作，但成功率显著下降，TURN 变得更加关键。

WebRTC 如何解决 NAT：三管齐下的方法

1. STUN（发现）

STUN 服务器帮助你发现从互联网看到的公网 IP 和端口。通过查询 STUN 服务器，你了解路由器的外部地址，这对锥形 NAT 类型有效。STUN 轻量且运营成本低，这就是为什么存在公共 STUN 服务器。

2. ICE（智能选择）

ICE 框架同时尝试多种连接策略：直接 LAN 连接、STUN 发现的公网地址和 TURN 中继地址。它测试所有可能性并选择最佳工作路径。这种系统方法最大化了连接成功率。

3. TURN（最后手段）

当 STUN 失败时（对称 NAT、严格防火墙），TURN 提供双方对等点都能访问的中继服务器。所有媒体流经 TURN 服务器，这成本高昂但保证连接性。对于 NAT 类型阻止直接通信的 15-25% 的连接，TURN 是必不可少的。

NAT 组合的连接成功率

实际连接成功率取决于双方对等点的 NAT 类型：

  • 双方都是完全锥形：约 95% 使用 STUN 成功
  • 双方都是受限锥形：约 90% 使用 STUN + ICE 成功
  • 双方都是端口受限锥形：约 80-85% 使用 STUN + ICE 成功
  • 一方对称，一方锥形：约 30-40% 成功（取决于锥形类型），建议使用 TURN
  • 双方都是对称：没有 TURN 约 0% 成功，有 TURN 100% 成功

Chrome 的遥测数据显示，在所有互联网流量中，直接连接（主机 + 服务器反射候选）在大约 75-80% 的会话中成功，其余 20-25% 需要 TURN 中继。这与消费者网络中端口受限锥形 NAT 的普遍性以及移动/企业环境中对称 NAT 的存在一致。

NAT 与 IPv6

IPv6 有 340 涧个地址（340 万亿万亿万亿）——足以给地球上的每个设备多个唯一的公网地址。理论上，IPv6 完全消除了对 NAT 的需求，解决了点对点连接问题。

然而，IPv6 采用仍然缓慢。截至 2025 年，Google 报告约 40-45% 的流量通过 IPv6 到达，这意味着大多数仍然使用 IPv4 + NAT。即使在启用 IPv6 的网络中，路由器通常也会实施模拟 NAT 行为的防火墙规则以确保安全，因此连接挑战并未完全消失。

对于 WebRTC 开发者来说，在可预见的未来规划 NAT 穿透仍然至关重要。STUN 和 TURN 基础设施将在未来多年内必不可少。

调试 NAT 问题

当 WebRTC 连接失败时，NAT 通常是罪魁祸首。检查以下指标：

  • ICE 收集完成但所有连接尝试超时 → 可能双方都是对称 NAT 且没有 TURN
  • 收集了服务器反射候选但连接失败 → 防火墙阻止 STUN 发现的端口
  • 只有中继候选有效 → 一方或双方在对称 NAT 后面
  • WiFi 上连接有效但移动数据上失败 → 移动运营商使用 CGNAT（对称 NAT）

WebRTC 故障排除工具或检查 chrome://webrtc-internals 可以显示哪些候选类型成功，帮助识别与 NAT 相关的问题。

总结

NAT 是现代互联网架构的必要之恶。它解决了 IPv4 地址耗尽问题，但创建了 WebRTC 必须克服的点对点连接问题。理解 NAT 类型——特别是认识到对称 NAT 会使 STUN 失效——对于规划 WebRTC 基础设施至关重要。

跨网络的 NAT 多样性（消费级路由器、CGNAT、企业防火墙）意味着你不能仅依赖 STUN。TURN 中继基础设施对于生产级 WebRTC 应用是强制性的，即使只有 15-25% 的连接需要它。替代方案——接受四分之一的用户根本无法连接——对于任何严肃的应用来说都是不可接受的。

NAT 不会很快消失。IPv6 采用是渐进的，即使在纯 IPv6 环境中，出于安全考虑通常仍保留类似防火墙的限制。对于 2025 年及以后的 WebRTC 开发者来说，通过 STUN、TURN 和 ICE 掌握 NAT 穿透是不可协商的。

参考资料

相关术语

STUN（NAT 会话穿透工具）TURN（NAT 中继穿透）ICE（交互式连接建立）
glossary.backToGlossary