Localhost WebRTC 演示在欺骗你。

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and code blocks.

本地主机在欺骗你

为什么所有东西在本地主机上都能工作

当你在自己的机器上测试 WebRTC 时，所处的网络环境是最简单的：同一台笔记本、同一浏览器、同一 Wi‑Fi、同一路由器，且没有防火墙阻拦。

你的电脑已经知道如何访问自身，所以 WebRTC 几乎不需要做任何努力。这就是教程看起来神奇的原因。

但一旦你加入手机、朋友的笔记本、不同的网络，或是整个互联网，魔法就会消失。

当现实敲门时

尝试以下任意一种情况：

• 一个对等点使用移动数据
• 一个对等点位于校园 Wi‑Fi 后
• 一个对等点位于企业防火墙后
• 通过 HTTPS 部署应用

突然之间：

• 连接一直卡住
• 视频根本不出现
• 对等点“已连接”，但什么也不发送

而大多数教程在解释原因之前就戛然而止。

教程通常跳过的内容

它们之所以跳过，并不是因为不重要，而是因为太乱。

这就是 WebRTC 从演示阶段转向真实网络的地方。

信令：对等方如何相互发现

WebRTC 是点对点的，但对等方不会凭空发现彼此。它们需要帮助——一个服务器，任何服务器，只用来交换连接细节。

大多数教程的作弊方式是：

• 在标签页之间复制文本
• 硬编码数值
• 假设双方已经连接

在本地主机上可以工作，但在其他环境下会失败。

为什么 “在我的笔记本上能连上” 毫无意义

在真实网络中：

• 你的笔记本在路由器后面
• 你的手机在运营商 NAT 后面
• 你的朋友在另一台路由器后面
• 防火墙会阻止随机端口

因此连接需要备用路径。这就是 ICE、STUN、TURN 等技术悄悄决定你的应用是能用还是会挂掉的地方。

在本地主机上你不会注意到它们，因为那里根本不需要这些。

HTTPS 已不再是可选项

另一个隐蔽的陷阱：浏览器信任 localhost，但 不 信任随意的 HTTP 网站。

摄像头访问、麦克风访问、屏幕共享、WebRTC 数据通道——全部都需要 安全上下文。所以你的应用在本地可以运行，但一旦部署就会崩溃。

再说一遍：这不是你的错。

“真实” WebRTC 实际需要的

不是理论，而是现实：

1. 一种让对等方交换连接信息的方式
2. 一种处理不同网络的方式
3. 当直接连接失败时的备用方案
4. 生产环境中的 HTTPS

一旦接受了这些，WebRTC 就不再显得随机，而是变得可预测。

本地主机幻象

当你在同一台机器上打开两个标签页时：

• 相同的 IP
• 相同的 NAT 行为
• 相同的防火墙规则
• 相同的浏览器进程

这会创建一个所有 ICE 候选都能轻易到达的环境，浏览器会愉快地连接这两个对等方，而无需面对任何真实的网络挑战。

换句话说，这并不是 WebRTC 正常工作，而是你的机器在绕过网络问题。

那么，我们到底跳过了什么？

1. SDP 交换 – 不是魔法，只是信令

WebRTC 本身并未提供交换会话信息的方式；这需要你自己实现。

会话描述协议（SDP）包含：

• 支持的编解码器
• 媒体方向
• ICE 候选（IP 和端口）
• DTLS 密钥

在教程中，开发者常常硬编码或手动复制/粘贴 SDP，因为演示中没有信令服务器。

在真实应用中，你需要可靠的 信令服务器 来：

• 交换 offer 与 answer
• 在收到时传递 ICE 候选
• 处理重新协商
• 管理断开/回退

没有信令 = 没有连接。就这么简单。

2. ICE 候选 – 幕后网络

当对等方创建 offer 或 answer 时，WebRTC 会生成多个 ICE 候选：

在 localhost 上，仅有 Host 候选存在，且能完美工作。

但在真实网络中：

• 本地 IP 在网络外部永不可达
• 必须进行 NAT 穿透
• 防火墙阻止直接 UDP
• 没有 TURN 时连接会卡住

许多教程在第一次 SDP 交换后就停止，从未展示如何正确收集和交换 ICE 候选。

3. STUN / TURN – WebRTC 中的无形 MVP

STUN（NAT 会话遍历实用工具）

STUN 让对等方发现其 公网 IP 和端口（从互联网视角）。这在以下情况下至关重要：

• 对等方位于不同网络
• 位于 NAT 后面
• 跨互联网连接

没有 STUN，WebRTC 只能提供本地 IP——对远程对等方毫无用处。

TURN（基于中继的 NAT 穿透）

当直接点对点失败时（例如防火墙阻止 UDP、对称 NAT、企业网络），TURN 服务器 中继媒体。

• 媒体通过 TURN 传输。
• TURN 服务器既不是可选的，也不便宜：
  • 带宽费用
  • 必须自行托管或付费使用提供商
  • 大多数 localhost 演示从未提及 TURN

4. HTTPS – 不是建议

WebRTC 需要 安全上下文：

• https://
• localhost（例外）
• 浏览器允许的标志（仅开发）

摄像头、麦克风、屏幕捕获、WebRTC 数据通道——在真实使用中都需要 HTTPS。

如果你的应用通过 HTTP 运行：

• 无媒体
• 无设备权限
• 无 WebRTC 支持

浏览器对 localhost 免除限制——这也是演示在本地可用而在生产环境崩溃的另一个原因。

5. NAT 与防火墙 – 理论与现实的交汇

真实网络会带来真实问题：

• 家庭路由器 NAT
• 运营商级 NAT
• 企业防火墙
• 移动热点
• VPN

这些常常导致直接点对点连接失败。只有通过完整的 ICE 收集并使用可靠的 TURN 服务器，应用才能始终如一地成功。

为什么我构建了这个演示

这个项目并不是为了在本地主机上看起来很炫。它的目的是能够持久运行：

• 不同 …

(原始内容在此截断；其余列表可根据需要添加。)

测试设备

• 不同的网络
• 真实部署

因为 WebRTC 通常就在这些地方出现问题。

要点

如果你的 WebRTC 应用仅在 localhost 上可用，它还不能正常工作。

localhost 移除了：

• 网络边界
• NAT
• 防火墙
• 安全规则

真实环境会把它们重新加回。

而 WebRTC 让你必须处理所有这些——无论教程是否提及。

欢迎评论。赞同、反对，或分享你的战斗经历。