UDP qua SOCKS5: sáu bài kiểm tra, một hồ sơ, một địa chỉ IP
Sophia Grote
Support specialist, Octo Browser
Octo Browser hỗ trợ UDP qua SOCKS5, có nghĩa là WebRTC, QUIC, HTTP/3 và WebTransport đều đi qua proxy thay vì bỏ qua nó. Chúng tôi muốn xem liệu thực tế có đúng như vậy hay không.
Điều quan trọng là phải hiểu chính xác những gì đang được kiểm tra. Tuyên bố “UDP hoạt động” là quá chung chung: câu hỏi thực sự là liệu lưu lượng UDP có đến từ cùng một địa chỉ với lưu lượng TCP hay không. Có hai trường hợp điều này có thể thất bại, và cả hai đều dẫn đến việc bị lộ danh tính:
Lưu lượng UDP bỏ qua proxy và được định tuyến trực tiếp từ thiết bị của người dùng. Khi đó, trang web sẽ thấy cả địa chỉ proxy (qua TCP) và địa chỉ thực của người dùng (qua STUN hoặc QUIC). Đây là tình huống tồi tệ nhất: người dùng nghĩ rằng họ được bảo vệ, nhưng trên thực tế họ lại bị lộ nhiều hơn so với việc hoàn toàn không sử dụng proxy.
Lưu lượng UDP bị chặn hoàn toàn. Không có rò rỉ nào, nhưng bản thân một trình duyệt không có WebRTC và QUIC đã là bất thường, và các hệ thống chống gian lận có thể phát hiện ra điều đó.
Octo không bị cả hai trường hợp trên. Cả sáu thử nghiệm dưới đây đều cho thấy cùng một địa chỉ đầu ra cho cả TCP và UDP.
Nội dung
Duy trì danh tính ẩn trực tuyến của bạn với Octo Browser. Dấu vân tay số thật của bạn sẽ không thể bị truy vết.
Bạn muốn thử Octo Browser với giá ưu đãi không?
Sử dụng mã khuyến mãi OCTOBLOG để được giảm giá 30% cho bất kỳ gói đăng ký nào. Ưu đãi này chỉ dành cho người dùng mới.
Thiết lập thử nghiệm
Trình duyệt: Octo Browser 3.1.3 (Chromium 152).
Hồ sơ: Quick honorable-bar · ID 8dd7332…
Proxy (Elusive): SOCKS5 · 91.132.161.222:35225.
Địa chỉ cổng ra: 68.59.118.110 · Hoa Kỳ · Comcast · Dân cư.
Ngày và giờ: Ngày 10 tháng 9 năm 2026, 12:04–12:11.
Cách đọc ảnh chụp màn hình
Cả sáu ảnh chụp màn hình đều thuộc về một phiên liên tục, không phải sáu lần chạy riêng biệt. Bạn có thể thấy điều này qua ba điểm sau, và chúng rất đáng chú ý trước khi xem xét chi tiết các bài kiểm tra:
Thông tin hồ sơ giống nhau xuất hiện ở đầu mỗi ảnh chụp màn hình: Quick honorable-bar, ID 8dd7332…, proxy 91.132.161.222:35225 và huy hiệu UDP hiển thị 68.59.118.110. Octo hiển thị địa chỉ cổng ra UDP riêng biệt—đó là địa chỉ sẽ xuất hiện trong tất cả các bài kiểm tra bên dưới.
Các tab không hề bị đóng. Có một tab trong ảnh chụp màn hình đầu tiên và sáu tab trong ảnh cuối cùng, với các thử nghiệm trước đó vẫn hiển thị trên thanh tab.
Đồng hồ trên khay hệ thống tăng liên tục: 12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11.
Không có bất kỳ sự cấu hình lại hồ sơ nào giữa các bài kiểm tra.
Bước 1. Cuộc gọi qua proxy. Kiểm tra mạng Twilio
Ngày 10 tháng 9, 12:04. Một tab—phiên làm việc vừa mới bắt đầu.
Công cụ chẩn đoán chính thức từ Twilio, một nhà cung cấp lớn về dịch vụ liên lạc thoại và video. Các nhà phát triển sử dụng công cụ này để kiểm tra xem mạng của máy khách có thể xử lý các cuộc gọi trên nền tảng trình duyệt hay không. Nó không tìm kiếm sự rò rỉ và không biết gì về trình duyệt chống phát hiện—nó chỉ đơn giản là thực hiện một cuộc gọi thực tế.
Tất cả các bước kiểm tra đều đạt, bao gồm cả Kết nối TURN UDP, điều này nghĩa là các gói UDP từ trình duyệt đã đến được máy chủ của Twilio và quay trở lại. Sau đó, bài kiểm tra đã thực hiện hai cuộc gọi thực tế bằng các codec khác nhau là PCMU và Opus: mã định danh của chúng, tỷ lệ mất gói bằng không và xếp hạng chất lượng cuối cùng—Tuyệt vời và Tốt—đều hiển thị trong nhật ký ở bên phải.
Các ghi chú cho quá trình kiểm tra TCP và TLS cũng rất đáng đọc. Twilio tuyên bố tại đó rằng Twilio Voice hoàn toàn không hoạt động qua TCP. Nói cách khác, cả hai cuộc gọi thành công đều được thực hiện qua UDP—không có lựa chọn nào khác.
Kết luận: hai cuộc gọi thoại trực tiếp đã đi qua proxy SOCKS5 với tỷ lệ mất gói bằng không.
Bước 2: QUIC hoạt động và địa chỉ thuộc về proxy. BrowserLeaks
Ngày 10 tháng 9, 12:04. Hiện có hai tab—Twilio vẫn mở ở bên trái.
Một thử nghiệm QUIC công khai từ BrowserLeaks. Nó trả lời hai câu hỏi khác nhau cùng một lúc và chúng ta cần cả hai: liệu trình duyệt có hỗ trợ QUIC—tức là UDP có hoạt động hay không—và máy chủ nhìn thấy địa chỉ nào của chúng ta qua QUIC—tức là lưu lượng UDP đang đi về đâu.
Bước 1 đã cho thấy UDP hoạt động, nhưng đó là một loại UDP khác. Twilio đã thử nghiệm WebRTC—UDP cho các cuộc gọi. QUIC là UDP dành cho lưu lượng truy cập web thông thường. HTTP/3 chạy trên nó, và Google cùng YouTube sử dụng nó để giao tiếp với các trình duyệt. Các công nghệ này khác nhau và việc hỗ trợ công nghệ này không đồng nghĩa với việc hỗ trợ công nghệ kia.
Có hai kết quả trong ảnh chụp màn hình: QUIC Connection: True, có nghĩa là kết nối qua UDP đã được thiết lập, và IP Address: 68.59.118.110, chính là địa chỉ mà Octo hiển thị trên thanh hồ sơ dưới dạng địa chỉ cổng ra UDP.
Kết luận: kết nối QUIC đã được thiết lập và máy chủ nhận thấy kết nối đó đến từ địa chỉ proxy.
Bước 3: Bốn kênh, một địa chỉ. Kiểm tra phát hiện WebRTC
Ngày 10 tháng 9, 12:05. Tab thứ ba, với hai bài kiểm tra trước đó vẫn mở ở bên trái.
Hai bước đầu tiên cho thấy UDP được thông suốt và địa chỉ là chính xác qua QUIC. Bài kiểm tra này so sánh các địa chỉ trên tất cả các kênh cùng một lúc và kiểm tra riêng xem trình duyệt có đang giả lập WebRTC thay vì thực sự chạy nó hay không.
Có bốn dòng trong phần Nguồn IP, đại diện cho bốn cách khác nhau để tìm ra địa chỉ của chúng tôi: thông qua yêu cầu HTTP thông thường (TCP), thông qua máy chủ STUN (UDP), thông qua chuyển tiếp TURN qua UDP và thông qua cùng một chuyển tiếp TURN qua TCP. Cả bốn dòng đều hiển thị 68.59.118.110, địa chỉ proxy của chúng tôi. Nói cách khác, địa chỉ UDP khớp với địa chỉ TCP.
Bên dưới đó là phần Cờ phát hiện (Detection Flags), với bảy bước kiểm tra riêng biệt để tìm kiếm hành vi giả mạo trình duyệt. Cả bảy bước đều trả về NO (KHÔNG):
WebRTC Blocked: WebRTC không bị vô hiệu hóa; nó vẫn hoạt động.
UDP/TCP Mismatch: không có sự không khớp giữa các địa chỉ UDP và TCP.
Candidates Spoofed: các ICE candidate mà trình duyệt gửi đến đối tác không bị giả mạo.
TURN UDP Blocked và TURN TCP Blocked: lưu lượng chuyển tiếp hoạt động theo cả hai hướng.
Relay Spoofed: chuyển tiếp là xác thực.
Sự kết hợp mới là điều quan trọng. Cờ đầu tiên cho thấy WebRTC đang hoạt động; sáu cờ còn lại cho thấy không có gì bị giả mạo trong quá trình này. Bạn không thể che giấu vấn đề bằng cách đơn giản là vô hiệu hóa WebRTC ở đây: điều đó sẽ ngay lập tức hiển thị ở dòng đầu tiên.
Kết luận: bốn kênh độc lập—HTTP, STUN, TURN UDP và TURN TCP—trả về cùng một địa chỉ. Không có cảnh báo nào trong số bảy bước kiểm tra chặn hoặc giả mạo được kích hoạt.
Bước 4: 3.000 yêu cầu qua HTTP/3. Hộp cát NGINX QUIC
Ngày 10 tháng 9, 12:07. Tab thứ tư.
Một môi trường thử nghiệm từ chính các nhà phát triển nginx. Nó gửi một loạt các yêu cầu và chia kết quả thành ba bộ đếm: bao nhiêu yêu cầu đã đi qua QUIC, bao nhiêu yêu cầu đi qua HTTP thông thường và bao nhiêu yêu cầu hoàn toàn không thành công.
Bước 2 cho thấy một kết nối QUIC. Tại đây có ba nghìn yêu cầu liên tiếp—đây không còn là bài kiểm tra xem QUIC có được hỗ trợ hay không, mà là bài kiểm tra xem kênh có thể xử lý tải liên tục hay không.
Kết quả: Tổng số yêu cầu 3000, Thành công với QUIC 3000, Thành công với HTTP 0, Yêu cầu thất bại 0. Tiến trình đạt 3000/3000 và phần biểu diễn trực quan bên dưới hoàn toàn có màu xanh lá cây. Màu xanh lá cây đại diện cho QUIC và không có ô nào mang màu sắc khác.
Bộ đếm Thành công với HTTP cũng rất đáng chú ý. Nó dành riêng cho các yêu cầu không thể đi qua QUIC và phải quay về dùng HTTP thông thường. Nó hiển thị số 0.
Kết luận: 3.000 trong số 3.000 yêu cầu đã đi qua QUIC. Không có trường hợp nào phải quay về dùng HTTP thông thường và không có yêu cầu nào bị thất bại.
Bước 5: WebTransport hiển thị cùng một địa chỉ. wtcheck.top
Ngày 10 tháng 9, 12:10. Tab thứ năm.
WebTransport là một phương thức khác dựa trên trình duyệt để trao đổi dữ liệu qua QUIC, tức là qua UDP. Trang web thực hiện hai yêu cầu và hiển thị kết quả cạnh nhau: địa chỉ của yêu cầu TCP thông thường và địa chỉ của kết nối WebTransport.
Đây là cách thứ ba khác nhau để kiểm tra lưu lượng UDP: Bước 1 sử dụng WebRTC; Bước 2 và 4 sử dụng QUIC và HTTP/3; ở đây chúng tôi xem xét WebTransport. Mỗi bài kiểm tra bổ sung sẽ thu hẹp phạm vi của thắc mắc “được rồi, giao thức cụ thể này hoạt động, nhưng còn các giao thức khác thì sao?”
Cả hai trường đều hiển thị 68.59.118.110. Không cần phải so sánh bất cứ điều gì giữa các ảnh chụp màn hình, vì hai giá trị được hiển thị trên cùng một trang.
Kết luận: kết nối WebTransport đến từ cùng một địa chỉ với yêu cầu TCP thông thường từ cùng một trang.
Bước 6: DNS phân giải ở phía proxy. BrowserLeaks
Ngày 10 tháng 9, 12:11. Tab thứ sáu, với tất cả các bài kiểm tra trước đó vẫn mở ở bên trái.
DNS là một kênh tách biệt với tất cả lưu lượng được thảo luận ở trên. Một proxy có thể được cấu hình hoàn hảo, trong khi trình duyệt vẫn có thể hỏi bộ phân giải của nhà cung cấp địa phương: “Địa chỉ của trang X là gì?” Điều này dẫn đến hai hệ quả: nhà cung cấp có thể thấy lịch sử duyệt web và trang web có thể so sánh vị trí địa lý của bộ phân giải với vị trí địa lý của địa chỉ IP để phát hiện ra sự khác biệt.
Thử nghiệm này kiểm tra xem các máy chủ DNS nào đã tham gia vào quá trình phân giải. Trong ảnh chụp màn hình, bạn có thể thấy như sau: địa chỉ 68.59.118.110, nhà cung cấp Comcast và kết quả Tìm thấy 77 Máy chủ, 1 ISP. Trong phần danh sách hiển thị, các bộ phân giải nằm trong dải 69.241.83.x và mỗi bộ phân giải đều liệt kê cùng một Comcast là ISP của mình.
Con số then chốt là 1 ISP. Từng bộ phân giải đều thuộc về cùng một nhà cung cấp như địa chỉ cổng ra của proxy. Không có yêu cầu nào đi đến bộ phân giải thuộc về nhà cung cấp khác.
Kết luận: tất cả 77 máy chủ DNS đều thuộc về nhà cung cấp của nút cổng ra. Quá trình phân giải DNS diễn ra ở phía proxy; bộ phân giải cục bộ không tham gia vào.
Cách tự tái hiện bài kiểm tra
Tạo một hồ sơ Octo và kết nối proxy SOCKS5 có hỗ trợ UDP của bạn với hồ sơ đó. Khởi chạy hồ sơ và mở sáu liên kết bên dưới. Nhìn vào địa chỉ thu được. Trong mọi bài kiểm tra, nó phải khớp với địa chỉ mà Octo hiển thị bên cạnh huy hiệu UDP.
networktest.twilio.com: một cuộc gọi WebRTC. UDP có đến được máy chủ của nhà cung cấp thoại không?
browserleaks.com/quic: QUIC có hoạt động không và nó đến từ địa chỉ nào?
ipbinding.notsosmart.dev so sánh các địa chỉ qua HTTP, STUN, TURN UDP và TURN TCP và hiển thị các cờ giả mạo.
quic.nginx.org/quic.html: kênh có thể xử lý tải liên tục: 3.000 yêu cầu HTTP/3 không?
wtcheck.top: địa chỉ WebTransport có khớp với địa chỉ TCP không?
browserleaks.com/dns: ai sở hữu các bộ phân giải tham gia vào việc xác định địa chỉ?
Duy trì danh tính ẩn trực tuyến của bạn với Octo Browser. Dấu vân tay số thật của bạn sẽ không thể bị truy vết.
Bạn muốn thử Octo Browser với giá ưu đãi không?
Sử dụng mã khuyến mãi OCTOBLOG để được giảm giá 30% cho bất kỳ gói đăng ký nào. Ưu đãi này chỉ dành cho người dùng mới.
Thiết lập thử nghiệm
Trình duyệt: Octo Browser 3.1.3 (Chromium 152).
Hồ sơ: Quick honorable-bar · ID 8dd7332…
Proxy (Elusive): SOCKS5 · 91.132.161.222:35225.
Địa chỉ cổng ra: 68.59.118.110 · Hoa Kỳ · Comcast · Dân cư.
Ngày và giờ: Ngày 10 tháng 9 năm 2026, 12:04–12:11.
Cách đọc ảnh chụp màn hình
Cả sáu ảnh chụp màn hình đều thuộc về một phiên liên tục, không phải sáu lần chạy riêng biệt. Bạn có thể thấy điều này qua ba điểm sau, và chúng rất đáng chú ý trước khi xem xét chi tiết các bài kiểm tra:
Thông tin hồ sơ giống nhau xuất hiện ở đầu mỗi ảnh chụp màn hình: Quick honorable-bar, ID 8dd7332…, proxy 91.132.161.222:35225 và huy hiệu UDP hiển thị 68.59.118.110. Octo hiển thị địa chỉ cổng ra UDP riêng biệt—đó là địa chỉ sẽ xuất hiện trong tất cả các bài kiểm tra bên dưới.
Các tab không hề bị đóng. Có một tab trong ảnh chụp màn hình đầu tiên và sáu tab trong ảnh cuối cùng, với các thử nghiệm trước đó vẫn hiển thị trên thanh tab.
Đồng hồ trên khay hệ thống tăng liên tục: 12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11.
Không có bất kỳ sự cấu hình lại hồ sơ nào giữa các bài kiểm tra.
Bước 1. Cuộc gọi qua proxy. Kiểm tra mạng Twilio
Ngày 10 tháng 9, 12:04. Một tab—phiên làm việc vừa mới bắt đầu.
Công cụ chẩn đoán chính thức từ Twilio, một nhà cung cấp lớn về dịch vụ liên lạc thoại và video. Các nhà phát triển sử dụng công cụ này để kiểm tra xem mạng của máy khách có thể xử lý các cuộc gọi trên nền tảng trình duyệt hay không. Nó không tìm kiếm sự rò rỉ và không biết gì về trình duyệt chống phát hiện—nó chỉ đơn giản là thực hiện một cuộc gọi thực tế.
Tất cả các bước kiểm tra đều đạt, bao gồm cả Kết nối TURN UDP, điều này nghĩa là các gói UDP từ trình duyệt đã đến được máy chủ của Twilio và quay trở lại. Sau đó, bài kiểm tra đã thực hiện hai cuộc gọi thực tế bằng các codec khác nhau là PCMU và Opus: mã định danh của chúng, tỷ lệ mất gói bằng không và xếp hạng chất lượng cuối cùng—Tuyệt vời và Tốt—đều hiển thị trong nhật ký ở bên phải.
Các ghi chú cho quá trình kiểm tra TCP và TLS cũng rất đáng đọc. Twilio tuyên bố tại đó rằng Twilio Voice hoàn toàn không hoạt động qua TCP. Nói cách khác, cả hai cuộc gọi thành công đều được thực hiện qua UDP—không có lựa chọn nào khác.
Kết luận: hai cuộc gọi thoại trực tiếp đã đi qua proxy SOCKS5 với tỷ lệ mất gói bằng không.
Bước 2: QUIC hoạt động và địa chỉ thuộc về proxy. BrowserLeaks
Ngày 10 tháng 9, 12:04. Hiện có hai tab—Twilio vẫn mở ở bên trái.
Một thử nghiệm QUIC công khai từ BrowserLeaks. Nó trả lời hai câu hỏi khác nhau cùng một lúc và chúng ta cần cả hai: liệu trình duyệt có hỗ trợ QUIC—tức là UDP có hoạt động hay không—và máy chủ nhìn thấy địa chỉ nào của chúng ta qua QUIC—tức là lưu lượng UDP đang đi về đâu.
Bước 1 đã cho thấy UDP hoạt động, nhưng đó là một loại UDP khác. Twilio đã thử nghiệm WebRTC—UDP cho các cuộc gọi. QUIC là UDP dành cho lưu lượng truy cập web thông thường. HTTP/3 chạy trên nó, và Google cùng YouTube sử dụng nó để giao tiếp với các trình duyệt. Các công nghệ này khác nhau và việc hỗ trợ công nghệ này không đồng nghĩa với việc hỗ trợ công nghệ kia.
Có hai kết quả trong ảnh chụp màn hình: QUIC Connection: True, có nghĩa là kết nối qua UDP đã được thiết lập, và IP Address: 68.59.118.110, chính là địa chỉ mà Octo hiển thị trên thanh hồ sơ dưới dạng địa chỉ cổng ra UDP.
Kết luận: kết nối QUIC đã được thiết lập và máy chủ nhận thấy kết nối đó đến từ địa chỉ proxy.
Bước 3: Bốn kênh, một địa chỉ. Kiểm tra phát hiện WebRTC
Ngày 10 tháng 9, 12:05. Tab thứ ba, với hai bài kiểm tra trước đó vẫn mở ở bên trái.
Hai bước đầu tiên cho thấy UDP được thông suốt và địa chỉ là chính xác qua QUIC. Bài kiểm tra này so sánh các địa chỉ trên tất cả các kênh cùng một lúc và kiểm tra riêng xem trình duyệt có đang giả lập WebRTC thay vì thực sự chạy nó hay không.
Có bốn dòng trong phần Nguồn IP, đại diện cho bốn cách khác nhau để tìm ra địa chỉ của chúng tôi: thông qua yêu cầu HTTP thông thường (TCP), thông qua máy chủ STUN (UDP), thông qua chuyển tiếp TURN qua UDP và thông qua cùng một chuyển tiếp TURN qua TCP. Cả bốn dòng đều hiển thị 68.59.118.110, địa chỉ proxy của chúng tôi. Nói cách khác, địa chỉ UDP khớp với địa chỉ TCP.
Bên dưới đó là phần Cờ phát hiện (Detection Flags), với bảy bước kiểm tra riêng biệt để tìm kiếm hành vi giả mạo trình duyệt. Cả bảy bước đều trả về NO (KHÔNG):
WebRTC Blocked: WebRTC không bị vô hiệu hóa; nó vẫn hoạt động.
UDP/TCP Mismatch: không có sự không khớp giữa các địa chỉ UDP và TCP.
Candidates Spoofed: các ICE candidate mà trình duyệt gửi đến đối tác không bị giả mạo.
TURN UDP Blocked và TURN TCP Blocked: lưu lượng chuyển tiếp hoạt động theo cả hai hướng.
Relay Spoofed: chuyển tiếp là xác thực.
Sự kết hợp mới là điều quan trọng. Cờ đầu tiên cho thấy WebRTC đang hoạt động; sáu cờ còn lại cho thấy không có gì bị giả mạo trong quá trình này. Bạn không thể che giấu vấn đề bằng cách đơn giản là vô hiệu hóa WebRTC ở đây: điều đó sẽ ngay lập tức hiển thị ở dòng đầu tiên.
Kết luận: bốn kênh độc lập—HTTP, STUN, TURN UDP và TURN TCP—trả về cùng một địa chỉ. Không có cảnh báo nào trong số bảy bước kiểm tra chặn hoặc giả mạo được kích hoạt.
Bước 4: 3.000 yêu cầu qua HTTP/3. Hộp cát NGINX QUIC
Ngày 10 tháng 9, 12:07. Tab thứ tư.
Một môi trường thử nghiệm từ chính các nhà phát triển nginx. Nó gửi một loạt các yêu cầu và chia kết quả thành ba bộ đếm: bao nhiêu yêu cầu đã đi qua QUIC, bao nhiêu yêu cầu đi qua HTTP thông thường và bao nhiêu yêu cầu hoàn toàn không thành công.
Bước 2 cho thấy một kết nối QUIC. Tại đây có ba nghìn yêu cầu liên tiếp—đây không còn là bài kiểm tra xem QUIC có được hỗ trợ hay không, mà là bài kiểm tra xem kênh có thể xử lý tải liên tục hay không.
Kết quả: Tổng số yêu cầu 3000, Thành công với QUIC 3000, Thành công với HTTP 0, Yêu cầu thất bại 0. Tiến trình đạt 3000/3000 và phần biểu diễn trực quan bên dưới hoàn toàn có màu xanh lá cây. Màu xanh lá cây đại diện cho QUIC và không có ô nào mang màu sắc khác.
Bộ đếm Thành công với HTTP cũng rất đáng chú ý. Nó dành riêng cho các yêu cầu không thể đi qua QUIC và phải quay về dùng HTTP thông thường. Nó hiển thị số 0.
Kết luận: 3.000 trong số 3.000 yêu cầu đã đi qua QUIC. Không có trường hợp nào phải quay về dùng HTTP thông thường và không có yêu cầu nào bị thất bại.
Bước 5: WebTransport hiển thị cùng một địa chỉ. wtcheck.top
Ngày 10 tháng 9, 12:10. Tab thứ năm.
WebTransport là một phương thức khác dựa trên trình duyệt để trao đổi dữ liệu qua QUIC, tức là qua UDP. Trang web thực hiện hai yêu cầu và hiển thị kết quả cạnh nhau: địa chỉ của yêu cầu TCP thông thường và địa chỉ của kết nối WebTransport.
Đây là cách thứ ba khác nhau để kiểm tra lưu lượng UDP: Bước 1 sử dụng WebRTC; Bước 2 và 4 sử dụng QUIC và HTTP/3; ở đây chúng tôi xem xét WebTransport. Mỗi bài kiểm tra bổ sung sẽ thu hẹp phạm vi của thắc mắc “được rồi, giao thức cụ thể này hoạt động, nhưng còn các giao thức khác thì sao?”
Cả hai trường đều hiển thị 68.59.118.110. Không cần phải so sánh bất cứ điều gì giữa các ảnh chụp màn hình, vì hai giá trị được hiển thị trên cùng một trang.
Kết luận: kết nối WebTransport đến từ cùng một địa chỉ với yêu cầu TCP thông thường từ cùng một trang.
Bước 6: DNS phân giải ở phía proxy. BrowserLeaks
Ngày 10 tháng 9, 12:11. Tab thứ sáu, với tất cả các bài kiểm tra trước đó vẫn mở ở bên trái.
DNS là một kênh tách biệt với tất cả lưu lượng được thảo luận ở trên. Một proxy có thể được cấu hình hoàn hảo, trong khi trình duyệt vẫn có thể hỏi bộ phân giải của nhà cung cấp địa phương: “Địa chỉ của trang X là gì?” Điều này dẫn đến hai hệ quả: nhà cung cấp có thể thấy lịch sử duyệt web và trang web có thể so sánh vị trí địa lý của bộ phân giải với vị trí địa lý của địa chỉ IP để phát hiện ra sự khác biệt.
Thử nghiệm này kiểm tra xem các máy chủ DNS nào đã tham gia vào quá trình phân giải. Trong ảnh chụp màn hình, bạn có thể thấy như sau: địa chỉ 68.59.118.110, nhà cung cấp Comcast và kết quả Tìm thấy 77 Máy chủ, 1 ISP. Trong phần danh sách hiển thị, các bộ phân giải nằm trong dải 69.241.83.x và mỗi bộ phân giải đều liệt kê cùng một Comcast là ISP của mình.
Con số then chốt là 1 ISP. Từng bộ phân giải đều thuộc về cùng một nhà cung cấp như địa chỉ cổng ra của proxy. Không có yêu cầu nào đi đến bộ phân giải thuộc về nhà cung cấp khác.
Kết luận: tất cả 77 máy chủ DNS đều thuộc về nhà cung cấp của nút cổng ra. Quá trình phân giải DNS diễn ra ở phía proxy; bộ phân giải cục bộ không tham gia vào.
Cách tự tái hiện bài kiểm tra
Tạo một hồ sơ Octo và kết nối proxy SOCKS5 có hỗ trợ UDP của bạn với hồ sơ đó. Khởi chạy hồ sơ và mở sáu liên kết bên dưới. Nhìn vào địa chỉ thu được. Trong mọi bài kiểm tra, nó phải khớp với địa chỉ mà Octo hiển thị bên cạnh huy hiệu UDP.
networktest.twilio.com: một cuộc gọi WebRTC. UDP có đến được máy chủ của nhà cung cấp thoại không?
browserleaks.com/quic: QUIC có hoạt động không và nó đến từ địa chỉ nào?
ipbinding.notsosmart.dev so sánh các địa chỉ qua HTTP, STUN, TURN UDP và TURN TCP và hiển thị các cờ giả mạo.
quic.nginx.org/quic.html: kênh có thể xử lý tải liên tục: 3.000 yêu cầu HTTP/3 không?
wtcheck.top: địa chỉ WebTransport có khớp với địa chỉ TCP không?
browserleaks.com/dns: ai sở hữu các bộ phân giải tham gia vào việc xác định địa chỉ?
Cập nhật với các tin tức Octo Browser mới nhất
Khi nhấp vào nút này, bạn sẽ đồng ý với Chính sách Quyền riêng tư của chúng tôi.
Cập nhật với các tin tức Octo Browser mới nhất
Khi nhấp vào nút này, bạn sẽ đồng ý với Chính sách Quyền riêng tư của chúng tôi.
Cập nhật với các tin tức Octo Browser mới nhất
Khi nhấp vào nút này, bạn sẽ đồng ý với Chính sách Quyền riêng tư của chúng tôi.
Tham gia Octo Browser ngay
Hoặc liên hệ với Dịch vụ khách hàng bất kì lúc nào nếu bạn có bất cứ thắc mắc nào.
Tham gia Octo Browser ngay
Hoặc liên hệ với Dịch vụ khách hàng bất kì lúc nào nếu bạn có bất cứ thắc mắc nào.
Tham gia Octo Browser ngay
Hoặc liên hệ với Dịch vụ khách hàng bất kì lúc nào nếu bạn có bất cứ thắc mắc nào.