Giao diện

Công cụ phổ biến

Kiểm tra rò rỉ WebRTC

WebRTC có thể trao cho website những địa chỉ mà trình duyệt của bạn bình thường không gửi, kể cả địa chỉ nằm sau VPN. Bài kiểm tra này hỏi ba máy chủ STUN do Cloudflare và Google vận hành, hiển thị mọi địa chỉ trả về cùng bản chất của từng địa chỉ, rồi so sánh chúng với địa chỉ website vốn đã thấy. Khi không kiểm tra được điều gì, nó nói rõ thay vì hiện cho bạn một dấu tích xanh.

Chạy trong trình duyệt của bạn với STUN của Cloudflare và Google · không lưu gì · các loại ứng viên theo RFC 8445

Chạy một lần khi tắt VPN và một lần khi bật. Sự khác biệt chính là câu trả lời.

Trình duyệt của bạn hỏi ba máy chủ STUN do Cloudflare và Google vận hành xem chúng thấy địa chỉ nào. Không địa chỉ nào WebRTC tìm thấy được gửi cho chúng tôi.

Những gì website vốn đã thấyIPv4IPv6Đang tìm kết nối của bạn…
Mọi địa chỉ WebRTC đưa ra

  1. Mọi địa chỉ WebRTC đưa ra sẽ xuất hiện ở đây, mỗi địa chỉ một dòng, khi các máy chủ STUN trả lời.

Không địa chỉ nào WebRTC tìm thấy được gửi cho chúng tôi. Trình duyệt của bạn tự hỏi các máy chủ STUN, như mọi cuộc gọi video. Để cho thấy website thấy gì, trang hỏi ipify.org và máy chủ của chính chúng tôi về các địa chỉ của bạn và mạng của chúng, giống như Kiểm Tra Rò Rỉ DNS.

Rò rỉ WebRTC là gì?

WebRTC là tính năng của trình duyệt đứng sau các cuộc gọi video. Để kết nối trực tiếp hai người, nó thu thập mọi địa chỉ mà thiết bị của bạn có thể được kết nối tới và đưa chúng cho trang web, kể cả những địa chỉ mà trình duyệt không bao giờ gửi trong một yêu cầu thông thường.

Việc thu thập này gọi là thu thập ứng viên ICE (ICE candidate gathering), được quy định trong RFC 8445. Trình duyệt liệt kê các địa chỉ trên giao diện mạng của chính bạn, rồi hỏi một máy chủ STUN “bạn thấy tôi đến từ địa chỉ nào?” và thêm cả địa chỉ đó. Bất kỳ trang nào trên internet cũng có thể khởi động việc này bằng vài dòng JavaScript và đọc từng ứng viên khi nó đến, mà không có hộp thoại xin quyền nào: đó là thiết kế, vì cuộc gọi phải hoạt động được mà không cần xin quyền.

Nó trở thành rò rỉ khi một trong các địa chỉ đó là thứ bạn đang che giấu. VPN thay đổi đường đi của các yêu cầu từ trình duyệt, nhưng WebRTC có thể hỏi hệ điều hành về mọi giao diện mạng, nên trên một thiết bị mà kết nối vật lý vẫn đang hoạt động, địa chỉ thật có thể xuất hiện cạnh địa chỉ của VPN. Không có gì bị hỏng cả: tính năng này đang làm đúng việc nó được thiết kế để làm.

Điều mà bất kỳ trang nào cũng khởi động đượcmột lần thu thập, từng bước

THIẾT BỊ CỦA BẠNINTERNETRouter của bạn (NAT)Script của trangTrình duyệt của bạnMáy chủ STUNstun.cloudflare.comnew RTCPeerConnection()không xin quyềnliệt kê mọi giao diện mạng192.168.1.20 → 8b7f4e2a-….localbạn thấy tôi đến từ địa chỉ nào?192.168.1.20:54400203.0.113.7:54400203.0.113.7:54400địa chỉ nó đã thấymọi ứng viên, ngay khi đếnonicecandidateTHIẾT BỊ CỦA BẠNINTERNETScript của trangTrình duyệt của bạnMáy chủ STUNnew RTCPeerConnection()không xin quyềnliệt kê mọi giao diện mạng192.168.1.20 → 8b7f4e2a-….localbạn thấy tôi đến từ địa chỉ nào?192.168.1.20203.0.113.7203.0.113.7:54400địa chỉ nó đã thấymọi ứng viên, ngay khi đếnonicecandidateRouter của bạn (NAT)

Toàn bộ script

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());

Kết quả in ra

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0

Ý nghĩa từng dòng

  • hostTrên thiết bị này8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localĐã được trình duyệt che
  • srflxMáy chủ STUN thấy203.0.113.7Định tuyến được trên internet
Một lần thu thập trên kết nối gia đình, với các địa chỉ dành cho tài liệu. Địa chỉ riêng không bao giờ rời trình duyệt ở dạng nguyên bản; máy chủ STUN thấy phía công cộng của router chứ không phải thiết bị, và cả hai câu trả lời đều đến tay script nào đã hỏi.
Kết quả kiểm tra rò rỉ WebRTC: mọi ứng viên ICE kèm loại, bản chất của từng địa chỉ và kết luậnKết quả kiểm tra rò rỉ WebRTC: mọi ứng viên ICE kèm loại, bản chất của từng địa chỉ và kết luậnKết luậnRò rỉ, không rò rỉ, hoặc, một cách trung thực, không kiểm tra được, kèm lý do.Mọi địa chỉKèm loại ứng viên, vì ứng viên host có ý nghĩa khác với ứng viên server-reflexive.Địa chỉ đó là gìRiêng, NAT cấp nhà mạng, đường hầm hay định tuyến được. Chỉ địa chỉ định tuyến được mới có thể là rò rỉ.Các máy chủMỗi máy chủ STUN một dòng. Một máy chủ không nói gì là một bài kiểm tra đã không chạy.Những gì website thấyCác địa chỉ trình duyệt của bạn vốn vẫn gửi, cũng là thứ để so sánh với các địa chỉ WebRTC.
Một lần chạy thử: mỗi máy chủ STUN đã trả lời gì, mọi địa chỉ WebRTC làm lộ, đó là loại địa chỉ nào, và website có vốn đã thấy nó không. Chọn một số để xem từng phần thể hiện điều gì.

Làm sao kiểm tra rò rỉ WebRTC?

Hãy bắt đầu bài kiểm tra ở trên. Nó thu thập ứng viên từ ba máy chủ STUN, xác định từng địa chỉ là gì, và so sánh các địa chỉ định tuyến được với địa chỉ website vốn đã thấy.

Có thể có ba kết quả, không phải hai. Không rò rỉ nghĩa là mọi địa chỉ định tuyến được mà WebRTC đưa ra đều là địa chỉ website đã có. Rò rỉ nghĩa là có ít nhất một địa chỉ không như vậy, hoặc một địa chỉ trên chính thiết bị của bạn đã được đưa ra trực tiếp. Không kiểm tra được nghĩa là WebRTC bị tắt, bị chặn, hoặc không máy chủ STUN nào trả lời, và đó là kết quả mà hầu hết các công cụ lặng lẽ biến thành “đạt”.

Nếu dùng VPN, hãy chạy hai lần: một lần khi tắt để xem các địa chỉ thông thường của bạn, một lần khi bật. Lần chạy thứ hai mới là lần quan trọng, và sự khác biệt giữa hai lần chính là câu trả lời. Trang giữ kết quả đầu tiên để bạn so sánh mà không cần ghi lại gì.

Ba kết quả, không phải haiý nghĩa của từng kết quả

  1. Không rò rỉ

    Mọi địa chỉ định tuyến được mà WebRTC đưa ra đều là địa chỉ website đã có.

    WebRTC đưa ra

    • 198.51.100.23Máy chủ STUN thấyWebsite đã thấy
    • 8b7f4e2a-….localTrên thiết bị nàyĐã được trình duyệt che

    Website thấy

    198.51.100.23
  2. Rò rỉ

    Có ít nhất một địa chỉ không phải là địa chỉ website đã có, hoặc một địa chỉ trên chính thiết bị của bạn đã được đưa ra trực tiếp.

    WebRTC đưa ra

    • 198.51.100.23Máy chủ STUN thấyWebsite đã thấy
    • 2001:db8:4a1f:7c00::1cTrên thiết bị nàyWebsite không thấy

    Website thấy

    198.51.100.23
  3. Không kiểm tra được

    WebRTC bị tắt hoặc bị chặn, hoặc không máy chủ STUN nào trả lời. Không đo được gì.

    stun.cloudflare.comKhông trả lời

    stun.l.google.comKhông trả lời

    Điều hầu hết công cụ hiện ở đâyKhông rò rỉ

Chạy hai lần

Tắt VPN

WebRTC đưa ra203.0.113.7

Website thấy203.0.113.7

Không rò rỉ

Bật VPN

WebRTC đưa ra198.51.100.23203.0.113.7

Website thấy198.51.100.23

Vẫn còn khi bật VPN

Rò rỉ
Mỗi kết quả kèm một lần chạy cho ra kết quả đó. Khi tắt VPN, địa chỉ của WebRTC và của website là một; khi bật, cả hai lẽ ra đều phải đổi, và địa chỉ nào còn ở lại chính là câu trả lời.

VPN có ngăn được rò rỉ WebRTC không?

Tự nó thì không. VPN thay đổi nơi lưu lượng của bạn đi tới; WebRTC có thể hỏi hệ điều hành xem có những giao diện mạng nào, và giao diện vật lý thường vẫn còn đó.

Mô tả của chính IETF rất chính xác: “nếu máy khách cố che giấu vị trí thực của mình bằng mạng riêng ảo (VPN), và VPN cùng hệ điều hành cục bộ hỗ trợ định tuyến qua nhiều giao diện, WebRTC có thể phát hiện không chỉ địa chỉ công cộng của VPN mà cả địa chỉ công cộng của ISP mà VPN đang chạy trên đó”. Cả hai địa chỉ đều được đưa ra, và một trang đang dò tìm có thể đọc cả hai.

Một số ứng dụng VPN bịt lỗ hổng này bằng cách định tuyến mọi lưu lượng ở cấp hệ điều hành, hoặc bằng một tiện ích trình duyệt hạn chế WebRTC. Cả hai cách đều hiệu quả, và cả hai đều là thứ cần kiểm tra chứ không nên mặc định là ổn; đó chính là mục đích của trang này. Trang kiểm tra rò rỉ của chính một VPN nói rằng bạn được bảo vệ thì không phải bằng chứng độc lập.

VPN đang bật, Wi-Fi vẫn kết nốihai giao diện, hai câu trả lời

Laptop của bạnVPN10.64.0.2Wi-Fi192.168.1.20ĐƯỜNG HẦM VPNMáy chủ VPN198.51.100.23Websiteduyệt webMáy chủ STUNRouter (NAT)Nhà mạng203.0.113.7WebRTC hỏi qua cả haiLaptop của bạnVPN10.64.0.2Wi-Fi192.168.1.20ĐƯỜNG HẦM VPNMáy chủ VPN198.51.100.23Router (NAT)Nhà mạng203.0.113.7duyệt webWebsiteMáy chủ STUNWebRTC hỏi qua cả hai

Những gì trang nhận được

  • 198.51.100.23srflxMáy chủ STUN thấyqua VPNWebsite đã thấy
  • 203.0.113.7srflxMáy chủ STUN thấyqua Wi-Fi, ngoài đường hầmWebsite không thấy

RFC 8828

Cách bịt lỗ hổng

  • Định tuyến ở cấp hệ điều hànhKhông gì ra ngoài đường hầm, nên máy chủ STUN chỉ thấy được địa chỉ của VPN.
  • Tiện ích trình duyệt của VPNNó hạn chế WebRTC ngay trong trình duyệt, nên giao diện kia không bao giờ bị hỏi.
  • Rồi kiểm tra, đừng mặc địnhHãy chạy bài kiểm tra này khi bật VPN. Trang kiểm tra rò rỉ của chính một VPN không phải bằng chứng độc lập.
Trường hợp IETF mô tả trong RFC 8828: VPN và hệ điều hành định tuyến qua nhiều giao diện, nên WebRTC tìm thấy địa chỉ công cộng của VPN và cả địa chỉ của nhà mạng bên dưới nó.

Host, server-reflexive và relay: ứng viên nào là ứng viên nào?

Ứng viên host là một địa chỉ trên chính thiết bị của bạn. Ứng viên server-reflexive là địa chỉ mà máy chủ STUN thấy, tức phía công cộng của NAT. Ứng viên relay là địa chỉ của máy chủ TURN, không phải của bạn.

Sự phân biệt này quan trọng, và hầu hết các bài kiểm tra rò rỉ bỏ qua nó. Một ứng viên server-reflexive mang địa chỉ IPv4 công cộng của bạn thường không phải tin mới: đó là cùng địa chỉ mà website nhận được từ kết nối bạn đang dùng. Một ứng viên host mang địa chỉ định tuyến được là chuyện khác: đó là một địa chỉ trên chính thiết bị, được đưa thẳng cho trang. Nó nhận diện chính thiết bị này chứ không chỉ router của gia đình bạn, và nó thay đổi khi mạng thay đổi.

Trang hiển thị loại ứng viên bên cạnh mỗi địa chỉ, cùng giao thức truyền tải, cổng và địa chỉ liên quan mà một ứng viên reflexive nêu ra. Một ứng viên relay là địa chỉ của chính máy chủ TURN và không tiết lộ gì về bạn; bài kiểm tra này không dùng máy chủ TURN nào, nên nếu có một ứng viên relay xuất hiện, nghĩa là thứ khác trên trang đã cấu hình nó.

Một ứng viên, từng trường mộtđúng như trang nhận được

  1. candidate:1467250027Foundation
  2. 1Thành phần
  3. udpGiao thức
  4. 1686052607Độ ưu tiên
  5. 203.0.113.7Địa chỉ
  6. 54400Cổng
  7. typ srflxLoại
  8. raddr 0.0.0.0 rport 9Địa chỉ liên quan
  9. generation 0Phần mở rộng

Bị thay bằng 0.0.0.0, cổng 9, ở nơi địa chỉ cục bộ được che

Bốn loại

  • typ hostTrên thiết bị này

    Một địa chỉ trên một trong các giao diện mạng của chính bạn.

    Địa chỉ riêng thì được che. Địa chỉ định tuyến được chính là thiết bị: phát hiện nghiêm trọng nhất.

    Nghiêm trọng nhất khi định tuyến được

  • typ srflxMáy chủ STUN thấy

    Phía công cộng của router, như máy chủ STUN thấy.

    Thường là địa chỉ website vốn đã có từ kết nối của bạn.

    Thường không phải tin mới

  • typ prflxPhía bên kia thấy

    Phía công cộng của router, như đầu bên kia của cuộc gọi thấy.

    Chỉ tìm thấy khi đang kết nối với đầu bên kia, nên một bài kiểm tra không có cuộc gọi không bao giờ thấy loại này.

    Chỉ trong cuộc gọi

  • typ relayĐịa chỉ của chính máy chủ relay

    Địa chỉ của máy chủ TURN, chuyển tiếp lưu lượng cho bạn.

    Địa chỉ của máy chủ, không phải của bạn. Bài kiểm tra này không dùng máy chủ TURN nào, nên nếu có ở đây thì do thứ khác cấu hình.

    Không nói gì về bạn

Địa chỉ của ứng viên được so sánh với những gì website thấy; loại của nó cho biết khác biệt đó nghiêm trọng đến đâu. Định nghĩa theo RFC 8445, mục 4.

Địa chỉ mDNS .local là gì, và nó có bảo vệ tôi không?

Các trình duyệt hiện đại thay địa chỉ riêng của bạn bằng một tên ngẫu nhiên kết thúc bằng .local trước khi đưa cho trang. Cách này có hiệu quả, nhưng chỉ với địa chỉ riêng. Nó chưa bao giờ nhằm che một địa chỉ công cộng.

Chrome làm việc này mặc định từ phiên bản 76, còn Firefox đặt media.peerconnection.ice.obfuscate_host_addresses thành true: thay vì 192.168.1.20, trang nhận được thứ gì đó như 8b7f4e2a-….local, vô nghĩa với bất kỳ ai bên ngoài mạng của bạn. Safari còn đi xa hơn: cho đến khi một trang có quyền dùng camera hoặc micro, nó hoàn toàn không đưa ra ứng viên host nào. Bài kiểm tra ở trên nhận ra những tên .local này và báo đó là tính năng bảo vệ đang hoạt động, không phải một phát hiện.

Bản dự thảo IETF định nghĩa cơ chế này nói rõ những gì nó không làm: “một địa chỉ vốn đã lộ ra internet thì không cần được mDNS bảo vệ, vì máy chủ web có thể dễ dàng quan sát được nó”. Vì vậy ứng viên server-reflexive vẫn mang địa chỉ IPv4 công cộng của bạn, và, điều khiến nhiều người bất ngờ, một thiết bị có địa chỉ IPv6 định tuyến được vẫn có thể đưa địa chỉ đó ra dưới dạng ứng viên host. Còn một lỗ hổng nữa nên biết: Chrome tắt cơ chế bảo vệ này với mọi trang đã có quyền dùng camera hoặc micro, nên một trang gọi video bạn từng dùng sẽ thấy các địa chỉ cục bộ thật của bạn.

Tên .local thay thế cái gìvà để nguyên cái gì

Những gì trình duyệt có

candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0

Những gì trang nhận được

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0

Mỗi trình duyệt làm gì theo mặc định

  • ChromePhiên bản 76, tháng 8 năm 2019
  • Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
  • SafariKhông có ứng viên host cho đến khi trang có quyền dùng camera hoặc micro

Cơ chế này là một bản dự thảo của IETF, sửa lần cuối vào tháng 12 năm 2021 và chưa bao giờ được công bố thành RFC. draft-ietf-mmusic-mdns-ice-candidates-03

Một địa chỉ WebRTC có thể đưa raCó bị che?
192.168.1.20IPv4 riêng của bạn, dưới dạng ứng viên hostBị cheĐược thay bằng một tên ngẫu nhiên: trang không biết gì về mạng của bạn.
203.0.113.7IPv4 công cộng của bạn, dưới dạng ứng viên của máy chủ STUNHiện raVốn đã công khai nên được giữ nguyên. Chỉ địa chỉ liên quan bị xóa trắng.
2001:db8:4a1f:7c00::1cMột IPv6 định tuyến được, dưới dạng ứng viên hostHiện raCũng là địa chỉ công khai, nên cơ chế che chưa bao giờ nhằm vào nó.
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07Một địa chỉ IPv6 tạm thờiCó thể hiện raBản dự thảo cho phép trình duyệt để nguyên không che, tùy lựa chọn.
192.168.1.20Mọi địa chỉ cục bộ, trên trang có quyền dùng camera hoặc microTắt cheChrome tắt cơ chế che ở đó: trang thấy các địa chỉ cục bộ thật của bạn.
Cơ chế che giấu những gì chỉ mạng của bạn biết. Những gì website vốn có thể thấy, nó để nguyên: do thiết kế, không phải do sơ suất.

Vì sao IPv6 là kiểu rò rỉ còn sót lại

Một địa chỉ IPv6 toàn cầu thuộc về một thiết bị chứ không phải cả một gia đình phía sau NAT, và mDNS cố ý để nó yên. Đó là thứ dễ nhận diện bạn nhất mà WebRTC vẫn còn trao ra.

Với IPv4, NAT của router gia đình đặt mọi thứ sau một địa chỉ, nên ứng viên server-reflexive cho trang biết gần như những gì kết nối thông thường của bạn vốn đã cho biết. IPv6 không có NAT: mỗi thiết bị có địa chỉ định tuyến được riêng, và một ứng viên host mang địa chỉ đó chỉ đích danh thiết bị, chứ không phải đường truyền. Nếu VPN của bạn chỉ mang IPv4, như nhiều VPN, thì địa chỉ IPv6 đó còn nằm hoàn toàn ngoài đường hầm.

Phần mở rộng quyền riêng tư của IPv6 có ích, vì địa chỉ IPv6 tạm thời được thay luân phiên. Tuy vậy, chúng không che địa chỉ đó: bản dự thảo mDNS nói những địa chỉ như vậy có thể được để nguyên không che. Bài kiểm tra ở trên đánh dấu ứng viên host IPv6 định tuyến được là điều nghiêm trọng nhất nó có thể tìm thấy, và Kiểm tra IPv6 sẽ cho bạn biết kết nối của bạn có IPv6 hay không.

Một địa chỉ chỉ đích danh aicùng ba thiết bị, hai lần

RouterIPv4, sau NATIPv6, không có NAT
Laptop192.168.1.202001:db8:4a1f:7c00::1c
Điện thoại192.168.1.212001:db8:4a1f:7c00::2b
TV192.168.1.222001:db8:4a1f:7c00::3d
Router203.0.113.7Một địa chỉ cho cả đường truyềnMỗi thiết bị một địa chỉ

Một địa chỉ IPv6 toàn cầu, hai nửa

2001:db8:4a1f:7c00Tiền tố mạng: đường truyền của bạn /64:8d3:5e2f:a41c:9b07Interface ID: thiết bị này

  • Ổn định2001:db8:4a1f:7c00::1c
  • Tạm thời: thay luân phiên2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

Một VPN chỉ mang IPv4

  • IPv4198.51.100.23Trong đường hầm
  • IPv62001:db8:4a1f:7c00::1cNgoài đường hầm
Sau NAT của IPv4, một gia đình dùng chung một địa chỉ; với IPv6, mỗi thiết bị có địa chỉ riêng, và một ứng viên host đưa thẳng địa chỉ đó ra. Bài kiểm tra coi ứng viên host IPv6 định tuyến được là phát hiện nghiêm trọng nhất.

Cách ngăn rò rỉ WebRTC trên từng trình duyệt

Firefox có các tùy chọn hiệu quả. Edge có một chính sách doanh nghiệp. Safari vốn đã hạn chế ứng viên. Còn các tiện ích trình duyệt mà người ta vẫn khuyên dùng thì không còn tác dụng gì.

Trong Firefox, about:config → media.peerconnection.ice.default_address_only chỉ gửi một địa chỉ thay vì tất cả, còn media.peerconnection.ice.relay_only giới hạn việc thu thập chỉ còn ứng viên relay, làm hỏng cuộc gọi trực tiếp nhưng che mọi thứ khác. Cả hai đều tắt theo mặc định; cơ chế che địa chỉ riêng bằng mDNS (media.peerconnection.ice.obfuscate_host_addresses) thì đã bật sẵn. Trong Edge, chính sách WebRtcLocalIpsAllowedUrls quy định những trang nào được thấy địa chỉ cục bộ; tài liệu của chính Microsoft lưu ý rằng thêm một trang vào sẽ “làm yếu đi sự bảo vệ”. Chrome không có tùy chọn tương đương cho người dùng thông thường. Safari là trình duyệt nghiêm ngặt nhất mà không cần chỉnh gì: khi không có quyền dùng camera hoặc micro, WebKit chỉ đưa ra ứng viên server-reflexive và relay, hoàn toàn không có ứng viên host.

Hai lời khuyên vẫn được lặp lại rộng rãi đã hết tác dụng. Tùy chọn ngăn WebRTC làm lộ địa chỉ IP nội bộ của uBlock Origin đã bị gỡ bỏ ở phiên bản 1.38, kèm ghi chú rằng nó “không còn cần thiết trên các trình duyệt hiện đại, trừ Firefox cho Android”. Còn tiện ích WebRTC Network Limiter của Google, dù vẫn có trên cửa hàng, thì không chạy được: tiện ích Manifest V2 đã bị vô hiệu hóa với mọi người dùng Chrome từ Chrome 138 vào tháng 7 năm 2025. Nếu một trang bảo bạn cài một trong hai thứ đó, trang ấy đã nhiều năm không được cập nhật.

Mỗi trình duyệt cung cấp gìđã đối chiếu với tài liệu của từng hãng

  • FirefoxTùy chọn hiệu quả

    about:config

    • media.peerconnection.ice.obfuscate_host_addressesMặc định trueChe địa chỉ riêng. Đã bật sẵn.
    • media.peerconnection.ice.default_address_onlyMặc định falseĐặt thành trueChỉ gửi một địa chỉ thay vì tất cả.
    • media.peerconnection.ice.relay_onlyMặc định falseĐặt thành trueChỉ ứng viên relay. Che nhiều nhất, nhưng làm hỏng cuộc gọi trực tiếp.

  • EdgeChính sách doanh nghiệp

    WebRtcLocalIpsAllowedUrls

    Liệt kê những trang được thấy địa chỉ cục bộ.

    Chưa cấu hình: địa chỉ cục bộ vẫn được che.

    Ghi chú của chính Microsoft: thêm một trang sẽ làm yếu đi sự bảo vệ.

    Windows và macOS, phiên bản 80 trở lên

  • ChromeKhông có tùy chọn

    Không có tùy chọn cho người dùng thông thường.

    Che địa chỉ riêng theo mặc định từ phiên bản 76.

    Trừ trên trang có quyền dùng camera hoặc micro.

  • SafariNghiêm ngặt sẵn

    Khi không có quyền dùng camera hoặc micro, chỉ có ứng viên máy chủ STUN và relay.

    Hoàn toàn không có ứng viên host.

Lời khuyên không còn tác dụng

  • Prevent WebRTC from leaking local IP addresses

    uBlock Origin

    Đã gỡ ở phiên bản 1.38

    Theo uBlock Origin, không còn cần thiết trên các trình duyệt hiện đại, trừ Firefox cho Android.

  • WebRTC Network Limiter

    Google · Chrome Web Store

    Vẫn có trên cửa hàng, không chạy được

    Tiện ích Manifest V2 đã bị vô hiệu hóa với mọi người dùng Chrome từ Chrome 138, tháng 7 năm 2025.

Tài liệu của chính từng hãng, được đọc vào ngày trang này được kiểm tra. Trang nào vẫn bảo bạn cài một trong hai thứ cuối cùng thì đã nhiều năm không được cập nhật.

Rò rỉ WebRTC, rò rỉ DNS và rò rỉ IP khác nhau thế nào?

Đó là ba cách khác nhau để vượt qua VPN. Rò rỉ WebRTC để lộ một địa chỉ; rò rỉ DNS để lộ ai trả lời các lượt tra cứu của bạn; rò rỉ IP là trường hợp đơn giản khi lưu lượng của bạn không hề đi vào đường hầm.

Rò rỉ WebRTC là về những địa chỉ mà trình duyệt tự đưa ra qua một tính năng được thiết kế để tự đưa chúng ra. Rò rỉ DNS là về bộ phân giải nào trả lời các lượt tra cứu của bạn: lưu lượng có thể đi qua VPN trong khi các lượt tra cứu vẫn đến bộ phân giải của nhà mạng, và điều đó cho nhà mạng biết mọi trang bạn truy cập. Kiểm Tra Rò Rỉ DNS của chúng tôi kiểm tra điều này bằng nameserver của chính chúng tôi, nên thấy chính xác những bộ phân giải nào đã hỏi.

Rò rỉ IP theo nghĩa chung là địa chỉ mà website đơn giản là thấy được, điều bạn có thể kiểm tra trên IP Của Tôi Là Gì hoặc ISP Của Tôi Là Gì. Hãy chạy cả ba sau mỗi lần thay đổi VPN: chúng hỏng độc lập với nhau, và một kết quả sạch ở bài này không nói lên điều gì về các bài kia.

Ba cách vòng qua VPNmỗi cách hỏng độc lập

BạnĐƯỜNG HẦM VPNQua đường hầmRò rỉ IP · lưu lượng của bạnWebsite203.0.113.7Rò rỉ DNS · lượt tra cứu của bạnBộ phân giải của nhà mạng203.0.113.53Rò rỉ WebRTC · địa chỉ của bạnScript của trang203.0.113.7BạnĐƯỜNG HẦM VPNQua đường hầmRò rỉ IPlưu lượng của bạnWebsite203.0.113.7Rò rỉ DNSlượt tra cứu của bạnBộ phân giải của nhà mạng203.0.113.53Rò rỉ WebRTCđịa chỉ của bạnScript của trang203.0.113.7

  • Rò rỉ IP

    Thứ bị rò rỉĐịa chỉ mà mọi yêu cầu mang theo

    Ai biết đượcMọi trang bạn truy cập

    Kiểm tra bằngIP Của Tôi Là GìISP Của Tôi Là Gì

  • Rò rỉ DNS

    Thứ bị rò rỉBộ phân giải nào trả lời lượt tra cứu của bạn

    Ai biết đượcNhà mạng của bạn, với mọi trang bạn tra cứu

    Kiểm tra bằngKiểm Tra Rò Rỉ DNS

  • Rò rỉ WebRTC

    Thứ bị rò rỉCác địa chỉ trình duyệt đưa cho trang

    Ai biết đượcBất kỳ trang nào hỏi, không cần xin quyền

    Kiểm tra bằngKiểm Tra Rò Rỉ WebRTC

Chúng hỏng độc lập với nhau: kết quả sạch ở một loại không nói lên điều gì về hai loại kia. Hãy chạy cả ba sau mỗi lần thay đổi VPN.

Vì sao bài kiểm tra này hỏi nhiều hơn một máy chủ STUN

Vì “không có địa chỉ nào trả về” và “không có địa chỉ nào tồn tại” trông giống hệt nhau, và chỉ một trong hai là tin tốt.

Tường lửa công ty, VPN hạn chế hoặc mạng chặn UDP có thể khiến máy chủ STUN không trả lời. Một bài kiểm tra chỉ hỏi một nhà cung cấp và không thấy gì thì chẳng biết được gì, vậy mà cách xử lý thường thấy lại là hiện một dấu tích xanh. Bài kiểm tra này hỏi endpoint STUN có tài liệu của Cloudflare và endpoint của Google, báo cáo riêng từng cái, và báo là không kiểm tra được khi không máy chủ nào trả lời.

Việc chọn máy chủ là có chủ ý. Cloudflare công bố stun.cloudflare.com:3478 như một phần của một sản phẩm, nên có điều khoản để đọc. stun.l.google.com:19302 của Google chỉ được ghi trong tài liệu như giá trị mặc định của công cụ kiểm tra WebRTC của chính Google, không có điều khoản công bố, nên được dùng như ý kiến thứ hai chứ không phải nguồn duy nhất. Máy chủ của Twilio cần thông tin xác thực, còn Mozilla không công bố máy chủ STUN công cộng nào trong tài liệu, dù vẫn hay được nhắc tới.

Máy chủ STUN công cộngvà những máy chủ bài kiểm tra này hỏi

  • CloudflareCó hỏi

    stun.cloudflare.com:3478

    Một endpoint có tài liệu, là một phần của sản phẩm, có điều khoản để đọc.

  • GoogleCó hỏi, làm ý kiến thứ hai

    stun.l.google.com:19302

    Chỉ được ghi trong tài liệu như giá trị mặc định của công cụ kiểm tra WebRTC của chính Google. Không có điều khoản công bố.

  • TwilioKhông hỏi

    global.stun.twilio.com:3478

    Cần thông tin xác thực từ API của Twilio: không mở cho mọi trang.

  • MozillaKhông hỏi

    Không có máy chủ công cộng

    Không công bố máy chủ STUN công cộng nào trong tài liệu. Firefox hoàn toàn không đi kèm máy chủ ICE mặc định nào.

Khi một máy chủ không trả lời

CloudflareGoogle
Đã trả lờiĐã trả lờiKết quả vẫn có giá trị
Đã trả lờiIm lặngKết quả vẫn có giá trị; máy chủ im lặng được nêu tên
Im lặngĐã trả lờiKết quả vẫn có giá trị; máy chủ im lặng được nêu tên
Im lặngIm lặngKhông kiểm tra được
Hai nhà vận hành, được hỏi riêng. Một máy chủ im lặng sẽ được nêu tên và kết quả vẫn có giá trị; khi không máy chủ nào trả lời, không có gì được đo, và bài kiểm tra nói rõ thay vì hiện kết quả đạt.

Địa chỉ IP của tôi có phải là dữ liệu cá nhân không?

Ở EU, địa chỉ IP động là dữ liệu cá nhân đối với nhà vận hành website có thể nhận diện bạn bằng thông tin nhà cung cấp internet nắm giữ. Tòa án Công lý Liên minh châu Âu đã quyết định như vậy năm 2016.

Đó là vụ Breyer, C-582/14, được phán quyết ngày 19 tháng 10 năm 2016, và thông cáo báo chí của Tòa án tóm tắt: “địa chỉ giao thức internet động của người truy cập cấu thành dữ liệu cá nhân, đối với nhà vận hành website, nếu nhà vận hành đó có phương tiện pháp lý cho phép nhận diện người truy cập liên quan bằng thông tin bổ sung về người đó do nhà cung cấp truy cập internet nắm giữ”. Cũng thông cáo báo chí đó lưu ý rằng một trang có thể có lợi ích chính đáng trong việc lưu giữ một phần dữ liệu này để tự bảo vệ trước các cuộc tấn công.

Đó chính là lý do trang này làm mọi việc trong trình duyệt của bạn. Các ứng viên ICE được trình duyệt thu thập, được so sánh trong trình duyệt, và hiển thị cho bạn; không địa chỉ nào WebRTC tìm thấy được gửi cho chúng tôi, nên chúng tôi không có gì từ đó để lưu giữ, giao nộp hay làm mất. Bạn có thể theo dõi bảng network trong lúc bài kiểm tra chạy.

Phán quyết BreyerTòa án Công lý Liên minh châu Âu

C-582/14Breyer v Bundesrepublik Deutschland19 tháng 10, 2016

  1. Nhà vận hành websitemột địa chỉ và một thời điểm, từ nhật ký của họ203.0.113.7 · 14:02:37
  2. phương tiện pháp lý để có được thông tin đó
  3. Nhà cung cấp truy cập internetai đang dùng địa chỉ đó vào thời điểm đó203.0.113.7 · 14:02:37 →
  4. Là dữ liệu cá nhân, đối với nhà vận hành đó

Thông cáo báo chí của Tòa án: một trang có thể có lợi ích chính đáng trong việc lưu giữ một phần dữ liệu này để tự bảo vệ trước các cuộc tấn công.

Trên trang này

Trình duyệt của bạn

  1. Thu thập
  2. Phân loại
  3. So sánh
  4. Hiển thị
  • Thấy địa chỉ công cộng của bạn, như trong mọi cuộc gọi
  • dnsrobot.netKhông ứng viên nào được gửi đi
Vụ C-582/14, Breyer. Địa chỉ IP động là dữ liệu cá nhân đối với nhà vận hành website có phương tiện pháp lý để nhận diện bạn bằng hồ sơ của nhà cung cấp. Trang này giữ các ứng viên trong trình duyệt của bạn.

Kiểm tra rò rỉ WebRTC: câu hỏi thường gặp

Rò rỉ WebRTC là gì?

WebRTC là tính năng của trình duyệt đứng sau các cuộc gọi video. Để kết nối trực tiếp hai người, nó thu thập mọi địa chỉ mà thiết bị của bạn có thể được kết nối tới và đưa chúng cho trang web, không có hộp thoại xin quyền nào. Nó trở thành rò rỉ khi một trong các địa chỉ đó là địa chỉ bạn đang che giấu, thường là địa chỉ thật của bạn khi đang bật VPN, vì WebRTC có thể hỏi về mọi giao diện mạng chứ không chỉ giao diện mà việc duyệt web của bạn dùng.

Làm sao kiểm tra rò rỉ WebRTC?

Hãy bắt đầu bài kiểm tra trên trang này. Nó hỏi ba máy chủ STUN của hai nhà vận hành, liệt kê mọi địa chỉ WebRTC đưa ra kèm loại của từng địa chỉ, và so sánh các địa chỉ định tuyến được với địa chỉ website vốn đã thấy. Nếu dùng VPN, hãy chạy một lần khi tắt VPN và một lần khi bật: sự khác biệt giữa hai lần chạy chính là câu trả lời.

VPN có ngăn được rò rỉ WebRTC không?

Tự nó thì không. VPN thay đổi nơi lưu lượng của bạn đi tới, nhưng WebRTC có thể hỏi hệ điều hành xem có những giao diện mạng nào, và kết nối vật lý thường vẫn là một trong số đó. Chính văn bản của IETF nói rằng WebRTC có thể phát hiện “không chỉ địa chỉ công cộng của VPN mà cả địa chỉ công cộng của ISP mà VPN đang chạy trên đó”. Một số ứng dụng VPN bịt được lỗ hổng này; bài kiểm tra này cho bạn biết VPN của bạn có làm được không.

Địa chỉ .local trong kết quả có nghĩa là gì?

Đó là mDNS, và đó là tin tốt. Các trình duyệt hiện đại thay địa chỉ riêng của bạn bằng một tên ngẫu nhiên kết thúc bằng .local trước khi đưa cho trang, nên website không biết được gì về mạng gia đình của bạn từ các tên đó. Chrome làm vậy từ phiên bản 76 và Firefox cũng thế; Safari còn đi xa hơn và hoàn toàn không đưa ra ứng viên host nào cho đến khi một trang có quyền dùng camera hoặc micro. Bài kiểm tra đánh dấu chúng là tính năng bảo vệ đang hoạt động chứ không phải một phát hiện.

Nếu mDNS đã che IP cục bộ của tôi thì tôi có an toàn không?

Chỉ một phần. mDNS được thiết kế để che địa chỉ riêng và được nói rõ là không che địa chỉ vốn đã công khai; bản dự thảo IETF định nghĩa nó nói như vậy. Địa chỉ IPv4 công cộng của bạn vẫn xuất hiện dưới dạng ứng viên server-reflexive, và một thiết bị có địa chỉ IPv6 định tuyến được vẫn có thể đưa thẳng địa chỉ đó ra. Chrome cũng tắt cơ chế bảo vệ này với mọi trang đã có quyền dùng camera hoặc micro.

Vì sao đôi khi bài kiểm tra báo “không kiểm tra được”?

Vì đó là sự thật. Nếu WebRTC bị tắt, bị một tiện ích hoặc chính sách chặn, hoặc không máy chủ STUN nào trả lời (do tường lửa, VPN hạn chế hoặc mạng chặn UDP), thì không có gì được đo. Hầu hết các công cụ hiện dấu tích xanh trong tình huống đó, điều gây hiểu lầm nhất mà một bài kiểm tra rò rỉ có thể làm. Bài kiểm tra này nói rõ điều gì đã xảy ra và nêu tên các máy chủ đã im lặng.

Làm sao tắt WebRTC trong Firefox?

Các tùy chọn có tài liệu của Firefox hạn chế WebRTC chứ không tắt hẳn nó. Trong about:config, media.peerconnection.ice.default_address_only chỉ gửi một địa chỉ thay vì tất cả, còn media.peerconnection.ice.relay_only giới hạn việc thu thập chỉ còn ứng viên relay: tùy chọn này che nhiều nhất nhưng làm hỏng cuộc gọi trực tiếp. Cơ chế che địa chỉ riêng, media.peerconnection.ice.obfuscate_host_addresses, đã bật sẵn theo mặc định. Hãy chạy lại bài kiểm tra sau mỗi thay đổi để xem nó thực sự mang lại gì.

Làm sao ngăn rò rỉ WebRTC trong Chrome?

Chrome không cho người dùng thông thường tùy chọn nào cho việc này; cơ chế che địa chỉ riêng bằng mDNS được bật mặc định và đó là sự bảo vệ bạn có. Edge, dùng chung engine với Chrome, có chính sách doanh nghiệp WebRtcLocalIpsAllowedUrls. Các tiện ích vẫn được khuyên dùng rộng rãi không còn tác dụng: uBlock Origin đã gỡ tùy chọn WebRTC ở phiên bản 1.38, và WebRTC Network Limiter của Google không chạy được kể từ khi Manifest V2 bị vô hiệu hóa ở Chrome 138.

Ứng viên host và ứng viên server-reflexive khác nhau thế nào?

Ứng viên host là một địa chỉ trên chính thiết bị của bạn. Ứng viên server-reflexive là địa chỉ mà máy chủ STUN thấy, tức phía công cộng của NAT, thường là địa chỉ website vốn đã có từ kết nối của bạn. Ứng viên host định tuyến được là phát hiện nghiêm trọng hơn, vì đó là địa chỉ trên chính thiết bị, và với IPv6, nó nhận diện thiết bị chứ không phải gia đình.

Rò rỉ WebRTC có giống rò rỉ DNS không?

Không. Rò rỉ WebRTC làm lộ một địa chỉ; rò rỉ DNS làm lộ bộ phân giải nào trả lời các lượt tra cứu của bạn, điều cho nhà mạng biết mọi trang bạn truy cập ngay cả khi lưu lượng đi qua VPN. Chúng hỏng độc lập với nhau, nên một kết quả sạch ở bài này không nói lên điều gì về bài kia. Hãy chạy cả Kiểm Tra Rò Rỉ DNS của chúng tôi sau mỗi lần thay đổi VPN.

Bài kiểm tra này có gửi địa chỉ IP của tôi đi đâu không?

Chỉ ở mức mà bất kỳ website nào cũng thấy. Trình duyệt của bạn liên hệ với các máy chủ STUN, như mọi cuộc gọi video: đó chính là bài kiểm tra. Để biết website thấy gì, trang hỏi ipify.org và máy chủ của chính chúng tôi về các địa chỉ của bạn và mạng của chúng, giống như Kiểm Tra Rò Rỉ DNS. Các địa chỉ WebRTC tìm thấy vẫn nằm trong trình duyệt của bạn: không địa chỉ nào được gửi cho chúng tôi. Hãy mở bảng network và theo dõi trong lúc bài kiểm tra chạy.

Theo luật EU, địa chỉ IP của tôi có phải là dữ liệu cá nhân không?

Đối với một nhà vận hành website ở EU, địa chỉ IP động là dữ liệu cá nhân khi nhà vận hành đó có phương tiện hợp pháp để nhận diện bạn bằng thông tin mà nhà cung cấp internet nắm giữ. Đó là quyết định của Tòa án Công lý trong vụ Breyer, C-582/14, tháng 10 năm 2016. Đó là một lý do khiến trang này giữ phần WebRTC của bài kiểm tra trong trình duyệt của bạn thay vì trên máy chủ của chúng tôi.

Còn thiếu điều gì?Đề xuất tính năng hoặc công cụ mới

Công cụ liên quan