Chuyển đến nội dung

Hướng dẫn về phạm vi tuyến

Proxy so với VPN so với WARP: những đường mạng nào của trình duyệt thực sự được bao phủ?

Các sản phẩm định tuyến hoạt động ở những lớp khác nhau. Proxy của trình duyệt có thể thay đổi các yêu cầu HTTP tới trang web trong khi WebRTC, DNS hoặc một họ địa chỉ khác vẫn đi theo tuyến của hệ điều hành.

Phiên bản bài kiểm tra 2026.10.01Đã xem xét Người xem xét kỹ thuật: John Hale

Trả lời nhanh

Kết quả này có thể kết luận điều gì

Proxy HTTP thường chỉ chuyển dữ liệu của ứng dụng được cấu hình rõ ràng để dùng nó. SOCKS5 có thể chuyển nhiều giao thức hơn và có thể hỗ trợ phân giải tên từ xa, nhưng hành vi của client quyết định những gì được đưa qua proxy. VPN toàn thiết bị hoặc chế độ truyền dữ liệu của WARP hoạt động ở lớp tuyến của thiết bị, nhưng split tunnel, các ngoại lệ, chế độ DNS và chính sách trình duyệt vẫn có thể tạo ra những đường quan sát được khác nhau. Hãy kiểm tra từng tín hiệu trước và sau khi thay đổi một tuyến.

Ranh giới của bằng chứng

Các tín hiệu được kiểm tra — và những điều chúng không chứng minh

Một kết luận rò rỉ đáng tin cậy tách bằng chứng quan sát được từ trình duyệt khỏi các giả định về danh tính, quyền sở hữu hay ý định của tuyến.

Các tín hiệu được hướng dẫn chẩn đoán này kiểm tra
Tín hiệuBằng chứng có sẵnĐiều nó không chứng minh
Yêu cầu HTTP/HTTPS của trình duyệtTuyến công khai mà các yêu cầu trang thông thường và các endpoint phát hiện theo từng họ địa chỉ nhìn thấy.Điểm thoát của trang web đã đổi không chứng minh UDP, DNS, WebRTC hay các ứng dụng khác dùng cùng tuyến.
Đường WebRTC/ICECác candidate công khai do ngăn xếp kết nối ngang hàng của trình duyệt để lộ.Cài đặt proxy của trình duyệt không tự động mô tả cách các socket ICE được định tuyến.
Đường DNSCác recursive resolver quan sát được qua callback có thẩm quyền gắn token.Chỉ riêng vị trí địa lý của resolver không cho biết thành phần cục bộ nào đã chọn nó.
Hành vi tách tuyếnNhững tín hiệu nào vẫn nằm trên mốc đối chiếu trực tiếp đã lưu sau khi bật proxy, hồ sơ WARP hoặc VPN.Công cụ không thể đọc các quy tắc tuyến độc quyền, các ngoại lệ hay cài đặt của sản phẩm đã mua.

Phương pháp

Quy trình bắt đầu từ mốc đối chiếu

  1. 1

    Bắt đầu khi chưa dùng tuyến cần đánh giá

    Ghi lại bằng chứng trực tiếp về IPv4, IPv6, WebRTC và resolver trong cùng một hồ sơ trình duyệt. Lưu nó làm mốc đối chiếu do người dùng tự xác nhận.

  2. 2

    Chỉ bật một lớp định tuyến

    Kiểm tra riêng proxy HTTP, client SOCKS5, hồ sơ WARP hoặc VPN toàn thiết bị. Chồng nhiều tuyến lên nhau sẽ khó xác định lớp nào đã để lộ một tín hiệu.

  3. 3

    So sánh mọi kênh

    Kiểm tra các yêu cầu trang thông thường, cả hai họ IP, bằng chứng WebRTC đã hoàn tất và các quan sát DNS có thẩm quyền. Bằng chứng bị thiếu vẫn là “Không khả dụng”.

  4. 4

    Xem lại cấu hình trước khi sửa

    Dùng tài liệu của client và nhà cung cấp để xác nhận DNS từ xa, hỗ trợ IPv6, chế độ truyền dữ liệu, các ngoại lệ split tunnel và chính sách WebRTC của trình duyệt.

Diễn giải

Cách bằng chứng tương ứng với một trạng thái có điều kiện

“Không có dấu hiệu” hẹp hơn “an toàn”, “Cần xem xét” không phải kết luận rò rỉ, và “Không khả dụng” không bao giờ bị chuyển thành kết quả đạt.

Không có dấu hiệu

Mọi kênh công khai đã đo đều dùng tuyến dự định hoặc không để lộ địa chỉ nào thuộc mốc đối chiếu một cách bất ngờ.

Các kênh đã đo nhất quán trong lần chạy này; các ứng dụng chưa được kiểm tra và những thay đổi tuyến trong tương lai vẫn nằm ngoài phạm vi.

Cần xem xét

Tuyến HTTP thay đổi nhưng DNS/chủ sở hữu mạng chưa rõ ràng, hoặc không thể liên hệ chắc chắn một kênh với tuyến dự định.

Hãy xác minh chế độ của client và hành vi của nhà cung cấp thay vì coi sự lệch địa lý là bằng chứng.

Rò rỉ

WebRTC, IPv4 hoặc IPv6 để lộ địa chỉ khớp chính xác với mốc đối chiếu trực tiếp trong khi tuyến trình duyệt đang hiển thị dùng proxy hoặc đường hầm.

Ít nhất một kênh đã đo đã bỏ qua tuyến dự định.

Không khả dụng

Một họ địa chỉ, callback DNS hoặc quá trình thu thập ICE không tạo ra được bằng chứng dùng được.

Không thể xác nhận tuyến đạt hay không đạt trên kênh đó. Hãy thử lại và xem xét chính sách hoặc khả năng truy cập dịch vụ.

Xử lý sự cố

Chẩn đoán đường đi trước khi thay đổi cài đặt

IP thoát của proxy trong trình duyệt đúng, nhưng WebRTC khớp với mốc đối chiếu trực tiếp.

Nguyên nhân có thể
Proxy chỉ áp dụng ở phạm vi ứng dụng trong khi ICE dùng một đường socket khác của trình duyệt hoặc hệ điều hành.
Bước kiểm tra tiếp theo
Hạn chế WebRTC, dùng tuyến toàn thiết bị hoặc tắt WebRTC khi phù hợp; sau đó so sánh lại với cùng mốc đối chiếu.

WARP hoặc VPN thay đổi hầu hết các tín hiệu, nhưng một tuyến vẫn đi trực tiếp.

Nguyên nhân có thể
Một ngoại lệ split tunnel, cơ chế dự phòng cho tên miền cục bộ, chế độ truyền dữ liệu, khoảng trống về họ địa chỉ hoặc quy tắc tương thích của client.
Bước kiểm tra tiếp theo
Xem cấu hình tuyến và DNS chính thức. Tài liệu của Cloudflare nêu rằng dữ liệu bị loại trừ sẽ bỏ qua client của họ và DNS có các điều khiển riêng.

SOCKS5 hoạt động với một hostname nhưng DNS có vẻ đi trực tiếp.

Nguyên nhân có thể
Ứng dụng có thể phân giải cục bộ trước khi mở kết nối SOCKS thay vì dùng phân giải tên từ xa.
Bước kiểm tra tiếp theo
Chọn chế độ DNS từ xa của client nếu được hỗ trợ và xác minh bằng các bài kiểm tra DNS gắn token lặp lại.

Giới hạn

Những điều hướng dẫn và bài kiểm tra này không thể bảo đảm

  • Bảng này mô tả các phạm vi định tuyến thường gặp, không phải bảo đảm cho mọi sản phẩm, hệ điều hành, trình duyệt, tiện ích mở rộng hay chính sách doanh nghiệp.
  • WARP là tên sản phẩm của Cloudflare; các chế độ và hành vi split tunnel phải được xác minh đối chiếu với client đang cài đặt và tài liệu chính thức.
  • Một trang web thông thường không thể xem toàn bộ bảng tuyến của hệ điều hành hay cấu hình client độc quyền.
  • Các proxy chồng lớp, đường hầm, container, máy ảo và trình duyệt từ xa có thể tạo ra nhiều hơn hai đường công khai hợp lệ.