STUN（NAT 会话穿透工具）

什么是 STUN？

STUN（Session Traversal Utilities for NAT，NAT 会话穿透工具）是一种网络协议，帮助 NAT 路由器后面的设备发现其公网 IP 地址，并判断是否能够建立直接的点对点连接。可以把 STUN 想象成互联网上的一面镜子——你的设备问 STUN 服务器"我的公网 IP 是什么？"，服务器回答它看到的内容。

STUN 不会中继媒体或数据，它只是一个发现服务，让 WebRTC 客户端了解自己的网络配置。一旦设备知道了自己的公网 IP 和端口，就可以与对等点分享这些信息以尝试建立直接连接。

STUN 标准化于 RFC 5389（RFC 7635 中有扩展），是 WebRTC ICE 框架的基础组件，使大多数浏览器间视频通话能够直接连接，而无需昂贵的中继服务器。

STUN 解决的 NAT 问题

要理解 STUN，必须首先理解它要解决的问题：

你的家庭路由器使用 NAT（网络地址转换）让多个设备共享一个公网 IP 地址。你的笔记本电脑获得类似 192.168.1.100 的私有 IP，这个地址仅在本地网络内有效。当你访问互联网时，路由器将你的私有 IP 转换为其公网 IP，并跟踪每个连接属于哪个内部设备。

这给点对点连接造成了问题：你不能告诉别人连接到 192.168.1.100，因为这个地址是私有的，从互联网上无法访问。你需要知道路由器的公网 IP 以及路由器为你的连接分配的端口。

STUN 提供的正是这些信息。

STUN 工作原理：分步详解

1. 客户端发送 STUN 请求

在启动 WebRTC 连接时，你的浏览器向公共 STUN 服务器（如 stun.l.google.com:19302）发送 STUN 绑定请求。该请求经过你的路由器，路由器通过将私有 IP/端口替换为其公网 IP 和分配的端口来应用 NAT。

2. STUN 服务器观察并响应

STUN 服务器接收请求并记录源 IP 地址和端口——这就是你路由器的公网 IP 和 NAT 转换后的端口。服务器将这些信息在绑定响应中发送回给你。

3. 客户端获知公网地址

你的浏览器收到响应后就知道了："从互联网的角度看，我可以通过 203.0.113.45:54321 访问"。这在 ICE 术语中被称为"服务器反射候选"。

4. 交换候选并尝试连接

双方对等点都执行 STUN 查询，获知各自的公网地址，通过信令交换这些信息，并尝试使用这些公网 IP 直接连接。如果两个路由器都允许该连接（这种情况发生概率为 75-85%），对等点就能建立直接的 WebRTC 连接，无需任何中继。

STUN 何时有效

当 NAT 路由器使用"锥形 NAT"或类似的宽松映射时，STUN 可以成功建立直接连接：

• 完全锥形 NAT：路由器将一个内部 IP:端口映射到一个外部 IP:端口。任何人都可以连接到外部地址。STUN 完美工作
• 受限锥形 NAT：路由器仅接受来自内部设备已联系过的地址的传入数据包。对等点交换地址后 STUN 有效
• 端口受限锥形 NAT：类似受限锥形，但还检查源端口。STUN 在适当协商后仍然有效

这些场景覆盖了大多数消费级路由器和移动网络，这就是为什么 STUN 能够支持大多数 WebRTC 连接。

STUN 何时失败

对称 NAT

STUN 的克星。对称 NAT 为每个目的地创建不同的端口映射。当你查询 STUN 服务器时，路由器分配端口 54321。但当你尝试连接对等点时，路由器分配了完全不同的端口 54322。STUN 发现的公网地址没有用，因为它对对等连接不起作用。

对称 NAT 在企业网络和某些运营商级 NAT（CGNAT）部署中很常见。当双方对等点都在对称 NAT 后面时，STUN 无能为力——必须使用 TURN 中继。

严格防火墙

某些防火墙阻止所有传入的 UDP 流量，即使内部设备发起了连接。STUN 仍然可以发现公网 IP，但连接会失败，因为防火墙丢弃了传入的数据包。

双重 NAT

当你处于多层 NAT 之后（例如，路由器在 ISP 的 NAT 后面），STUN 只能揭示最外层的公网 IP。这可能仍然有效，但增加了复杂性并降低了成功率。

STUN 服务器基础设施

STUN 服务器轻量且运营成本低，因为它们不中继媒体——只是回答简单的查询。这就是为什么存在免费的公共 STUN 服务器：

• stun.l.google.com:19302（Google 的公共 STUN 服务器）
• stun1.l.google.com:19302 到 stun4.l.google.com:19302
• Cloudflare、Twilio 等提供商也提供免费 STUN 服务器

STUN 查询很小（几十字节），响应同样很小。单个 STUN 服务器可以在普通硬件上每天处理数百万次查询。

实践中的 STUN：真实数据

在典型的 WebRTC 部署中：

• 75-85%：连接成功使用 STUN 建立直接的点对点路径
• 15-25%：STUN 失败，连接降级到 TURN 中继
• <1%：STUN 和 TURN 都失败，通常是极其严格的网络

这个高成功率是 STUN 如此有价值的原因——它使大多数通话无需昂贵的中继基础设施。

STUN 与 TURN 的对比

理解这两者的区别至关重要：

• STUN：帮助发现公网 IP。不中继数据。运营成本低。75-85% 的情况下有效。低延迟（无中继意味着直接连接）
• TURN：当 STUN 失败时中继所有媒体。成本高（带宽费用）。必需的降级方案。增加延迟（数据经过中继）

大多数 WebRTC 应用同时配置两者：STUN 服务器用于发现，TURN 服务器作为降级方案。ICE 优先尝试 STUN 发现的直接连接，仅在必要时使用 TURN。

安全考虑

STUN 服务器会看到你的公网 IP，这引发了轻微的隐私担忧。浏览器通过以下方式缓解这一问题：

• 在执行 STUN 查询前要求用户同意摄像头/麦克风访问
• 某些浏览器在隐私模式下限制或混淆 IP 暴露
• WebRTC 加密所有媒体流，因此 STUN 服务器无法访问通话内容

由于 STUN 服务器只看到 IP 地址和端口（而非媒体内容），与获得的功能相比，安全风险微乎其微。

STUN 在 2025 年的重要性

STUN 是 WebRTC 能够在不破产于服务器基础设施成本的情况下提供大规模高质量、低延迟视频通话的原因。通过为绝大多数通话启用直接点对点连接，STUN：

• 最小化延迟（直接连接比中继更快）
• 降低服务器成本（75-85% 的通话无需中继带宽）
• 改善通话质量（无中继瓶颈）
• 增强隐私（媒体不经过服务器）

虽然新技术不断演进，但 STUN 在 2025 年仍是 WebRTC 的基石，与首次标准化时一样重要。任何 WebRTC 应用都需要 STUN 服务器——幸运的是，它们运营成本低，公共提供商通常免费提供。

总结

STUN 是一个简单但强大的协议：它帮助设备发现其公网身份，使它们能够直接连接。虽然它不适用于所有网络配置（对称 NAT 会使其失效），但它的成功率足够高，大大减少了对昂贵中继服务器的需求。

作为 ICE 框架的一部分，STUN 默默地支撑着大多数 WebRTC 连接，通过使点对点通信在 NAT 和防火墙环境下变得可行，实现了基于浏览器的视频通话革命。

参考资料

• STUN 服务器：什么是 NAT 会话穿透工具？ - Metered
• STUN 服务器 - 什么是 NAT 会话穿透工具？ - Stream
• WebRTC 协议简介 - Mozilla 开发者网络
• WebRTC STUN vs TURN 服务器 - Stream
• 免费 STUN 服务器：解锁 WebRTC、VoIP 和 P2P 的 NAT 穿透（2025 指南） - VideoSDK