> 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-tw/concepts/what-is-webrtc.md).

# 什麼是 WebRTC？

瀏覽器內呼叫背後的技術、為什麼它必須偵測你的網路位址，以及即使開著 VPN 也可能如何暴露你的 IP。

視訊通話以前需要下載應用程式。現在，只要瀏覽器中的一個連結就夠了。發生了什麼變化——而且為什麼隱私工具會在意這件事？

## 內建於瀏覽器的即時媒體

**WebRTC** 代表 Web 即時通訊（Web Real-Time Communication）。它是內建於每一款主流瀏覽器的一組功能，讓網頁能夠傳送和接收即時音訊、視訊與資料。

視訊會議、以瀏覽器為基礎的語音聊天、螢幕分享、頁面內的客戶支援通話、一些線上遊戲以及一些檔案傳輸工具都會使用它。無需外掛，無需安裝。

這個重要的設計決策是這樣：對於即時媒體，WebRTC 會嘗試傳送資料 **直接在兩位參與者之間** ，只要做得到，就不會把所有流量都經過公司的伺服器。

這個選擇很合理。直接路徑更短，所以通話延遲更低。它對服務的成本也低得多，因為不需要為每一通通話的每一秒都付費承載。

但直接連線需要一般網頁瀏覽不需要的東西：雙方都必須知道對方可以如何被連到。

## 為什麼它必須去尋找位址

問題在這裡。幾乎沒有人是直接連上網際網路的。正如在 [公共、私有與 CGNAT 位址](/knowledge-base/zh-tw/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` ——除非該頁面已經獲得相機或麥克風存取權。
* **事前蒐集的位址更少。** 現代瀏覽器會先收集較少的一組候選項，直到真正要建立通話時才會擴展。
* **有政策設定可用。** 某些瀏覽器與擴充功能允許你只將 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-tw/connection-tools/webrtc-test.md).
{% endhint %}

## 相關概念

* [公共、私有與 CGNAT 位址](/knowledge-base/zh-tw/concepts/public-private-cgnat.md) ——WebRTC 在處理的 NAT 層
* [IPv4 與 IPv6](/knowledge-base/zh-tw/concepts/ipv4-vs-ipv6.md) ——為什麼 IPv6 是最常見的洩漏路徑
* [延遲、抖動與封包遺失](/knowledge-base/zh-tw/concepts/latency-jitter-packet-loss.md) ——決定通話音質的指標
* [我是否洩漏了我的真實 IP？](/knowledge-base/zh-tw/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-tw/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.