> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/zh/concepts/what-is-webrtc.md).

# 什么是 WebRTC？

视频通话过去需要下载应用程序。现在只需浏览器里的一个链接就够了。发生了什么变化——以及为什么隐私工具会在意这件事？

## 浏览器内置的实时媒体

**WebRTC** 是 Web 实时通信（Web Real-Time Communication）的缩写。它是一组内置于每个主流浏览器中的功能，使网页能够发送和接收实时音频、视频和数据。

视频会议、基于浏览器的语音聊天、屏幕共享、页面内客户支持通话、一些在线游戏以及一些文件传输工具都在使用它。无需插件，无需安装。

这个重要的设计决定是：对于实时媒体，WebRTC 会尽量发送数据 **直接在两个参与者之间** ，而不是把所有内容都经由公司的服务器转发。

这个选择是合理的。直接路径更短，因此通话延迟更低。它也让服务的成本低得多，因为无需为每一通电话的每一秒都承担传输费用。

但直接连接需要普通网页浏览从不需要的东西：双方都必须知道如何联系到对方。

## 为什么它必须去寻找地址

问题就在这里。几乎没人是直接连接到互联网的。正如在 [公网、私网与 CGNAT 地址](/knowledge-base/zh/concepts/public-private-cgnat.md), `192.168.1.14`，你的设备位于路由器后面，拥有一个类似于

，浏览器实际上并不知道自己真正的公网地址，也当然不知道对方可以通过哪一组地址和端口联系到它。

WebRTC 通过收集选项来解决这个问题。

* 它会列出自己在本地能看到的地址——你网络中的私有地址，以及任何 IPv6 地址。
* 它会向互联网上一个称为 **STUN 服务器**的辅助服务器提出一个简单问题："你看到这条消息是从哪个地址发来的？" 回复会告诉它流量穿过 NAT 后呈现出来的公网地址和端口。
* 如果直接连接被证明不可行，它就会退回到一个 **中继服务器** （TURN），它会转发媒体。这在任何地方都有效，但成本更高，也会增加延迟。

它收集到的每个选项都称为一个 **候选项**。双方交换各自的候选列表，然后系统地尝试各种组合，直到有一种可行。整个这种反复试错的过程称为 **ICE** ——交互式连接建立。它是一种正式的说法：收集所有可能的可达方式，交换列表，并使用最先成功的配对。

```mermaid
flowchart LR
    Y["你的浏览器"] -->|"你看到的<br/>地址是什么？"| S["STUN 服务器"]
    S -->|"203.0.113.42:54321"| Y
    Y -->|"候选列表"| P["另一方参与者"]
    P -->|"候选列表"| Y
    Y -.->|"如有可能则直接传输媒体"| P
```

## 为什么这会在 VPN 后暴露你的 IP

现在隐私上的后果就很清楚了。

VPN 的工作方式是截获你的流量，并通过加密隧道传送。网站看到的是 VPN 的地址，而不是你的地址。对于普通浏览来说，这种方式很有效，因为所有流量都遵循操作系统被告知要使用的同一路径。

WebRTC 并不会简单地遵循那条路径。它会刻意枚举所有可能使用的地址和路径，因为它的全部目的就是找到一条通路。根据你的系统和 VPN 的配置，这种枚举可能会发现：

* 你的真实公网地址，如果有些流量逃出了隧道——一种 **分流隧道** 配置，或者只覆盖浏览器页面请求的浏览器扩展型 VPN
* 你的 **IPv6** 地址，如果 VPN 只承载 IPv4 而不处理 IPv6；这是一个非常常见的原因
* 你的 **本地网络地址**，它不会在全球范围内标识你，但会泄露有关你网络的细节

网页可以用少量 JavaScript 读取这些候选项。它不需要权限，也不需要打开你的摄像头或麦克风。人们所说的“WebRTC 泄漏”就是这个意思：不是 WebRTC 的缺陷，而是 WebRTC 设计要做的事情与 VPN 用户以为正在发生的事情之间不匹配。

## 读取测试显示给你的地址

WebRTC 测试通常会一次列出多个候选项。它们并不都同样有意义。

| 你看到的内容                                     | 其含义                             |
| ------------------------------------------ | ------------------------------- |
| 以 `.local`                                 | 浏览器为你的本地地址提供的隐私占位符。正常且符合预期。     |
| `192.168.x.x`, `10.x.x.x`, `172.16–31.x.x` | 一个真实的本地网络地址。暴露的是你的网络拓扑，而不是你的身份。 |
| 一个与你的 VPN 相匹配的公网地址                         | 正确。隧道正在覆盖 WebRTC。               |
| 一个公共地址， *不会* 你的 VPN 的                      | 泄漏。这才是重要的那个。                    |
| 一个 IPv6 地址，而你的 VPN 显示的是 IPv4               | 这是最常见的泄漏——你的 VPN 没有传输 IPv6。     |

有用的比较始终是 WebRTC 找到的地址与普通网页请求显示的地址之间的对比。如果它们不一致，就有东西在逃出隧道。

## 浏览器对此的处理方式

多年来，浏览器在这方面已经收紧了控制。

* **本地地址默认是隐藏的。** 浏览器现在不会暴露你真实的私有地址，而是提供一个随机化的占位符——一个以 `.local` 结尾的 mDNS 名称——除非该页面已经获得摄像头或麦克风访问权限。
* **一开始收集的地址更少。** 现代浏览器在真正开始建立通话之前，只会收集更少的一组候选项。
* **有相应的策略设置。** 某些浏览器和扩展允许你将 WebRTC 仅限制在默认路由上，或完全禁用它。

这些有帮助，但并不能彻底解决问题。通过 STUN 发现的公网地址仍然是公网地址，而 IPv6 的缺口是你这边的配置问题，不是浏览器能替你修复的。

完全关闭 WebRTC 也是一种选择，但代价显而易见：浏览器里的视频通话将无法工作。对大多数人来说，更好的做法是修复底层泄漏——使用能处理 IPv6 的 VPN，或者使用在系统层面运行而不仅仅局限于浏览器内部的 VPN。

## 常见误解

**“WebRTC 是间谍软件。”** 它是实时媒体的标准功能，被你所依赖的工具使用。地址发现是连接能够发生的必要条件。

**“WebRTC 泄漏意味着我的 VPN 坏了。”** 更常见的情况是你的 VPN 不完整——通常是缺少 IPv6，或者只覆盖浏览器页面加载。

**“如果测试显示一个 `.local` 地址，那我就在泄漏。”** 不是。那是浏览器隐私占位符正常工作。重要的是是否出现了一个不属于你的 VPN 的真实公网地址。

**“无痕模式会阻止它。”** 不会。无痕模式影响的是存储和历史记录，不影响网络行为。

{% hint style="info" %}
**在 MyIP 上亲自看看**

这个 **WebRTC 泄漏测试** 仪表板上的这项功能会执行这一发现过程，并显示 WebRTC 找到的每个地址。如果你的 VPN 已开启，而其中一个地址不是你的 VPN 的，那么你的代理设置并未覆盖这些连接。它还会估算你的 NAT 类型——这对游戏和通话很有用，不过该检测只是最佳猜测，而不是确定结果。

完整教程： [WebRTC 测试](/knowledge-base/zh/connection-tools/webrtc-test.md).
{% endhint %}

## 相关概念

* [公网、私网与 CGNAT 地址](/knowledge-base/zh/concepts/public-private-cgnat.md) ——WebRTC 绕过的 NAT 层
* [IPv4 与 IPv6](/knowledge-base/zh/concepts/ipv4-vs-ipv6.md) ——为什么 IPv6 通常是泄漏路径
* [延迟、抖动与丢包](/knowledge-base/zh/concepts/latency-jitter-packet-loss.md) ——决定通话音质好坏的指标
* [我是否泄露了真实 IP？](/knowledge-base/zh/diagnose/am-i-leaking-my-real-ip.md) ——完整的泄漏检查清单


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/zh/concepts/what-is-webrtc.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.