7 điểm rò rỉ phổ biến nhất khi chạy proxy — và cách BitBrowser xử lý chúng

Hầu hết người dùng proxy chỉ kiểm tra một thứ: IP ra có đúng quốc gia không. Nhưng các hệ thống phát hiện hiện đại không đọc một con số duy nhất. Chúng dựng một bức chân dung từ hàng chục tín hiệu, rồi tìm mâu thuẫn giữa các tín hiệu đó. Một proxy “sạch” về IP vẫn có thể bị nhận diện chỉ vì múi giờ lệch, DNS đi ra ngoài tunnel, hoặc WebRTC trả về một danh sách rỗng bất thường.

Dưới đây là 7 điểm rò rỉ (lộ dấu) thường gặp nhất, kèm logic phát hiện và cách các trình duyệt anti-detect như BitBrowser xử lý từng điểm.

1. WebRTC: rò rỉ thật, và cả “rò rỉ giả”

Có hai kiểu thất bại WebRTC, và kiểu thứ hai nguy hiểm hơn vì nó trông giống như thành công.

Kiểu thứ nhất là rò rỉ thật: trình duyệt để lộ địa chỉ LAN cục bộ (192.168.x.x) hoặc IP công cộng thật bên cạnh IP proxy thông qua ICE candidate. Kiểu thứ hai xảy ra khi proxy nuốt mất UDP. STUN hoạt động trên UDP; proxy dân cư SOCKS5 thường chỉ mang TCP và từ chối UDP, nên truy vấn STUN timeout, không có srflx candidate nào được sinh ra. Trình duyệt thật sau NAT tại nhà luôn tạo ra ít nhất một srflx candidate. Vì vậy, một danh sách candidate rỗng không đọc là “riêng tư”, mà đọc là “bị can thiệp”: detector chỉ cần đếm số candidate là đủ nghi ngờ.

Nguyên tắc chung: một tín hiệu bị triệt tiêu bản thân nó là một tín hiệu. “Không thấy rò rỉ” không đồng nghĩa với “có giá trị thật”.

BitBrowser xử lý điểm này ở tầng sâu hơn việc “tắt WebRTC”. Trong các bản cập nhật gần đây, BitBrowser bổ sung chế độ thay thế WebRTC an toàn hơn và tùy chọn UDP cho SOCKS5, cho phép lưu lượng WebRTC đi qua proxy mà vẫn giữ được cấu trúc candidate tự nhiên, thay vì tạo ra một bề mặt “chết” dễ bị chấm điểm.

2. DNS: resolver không đi cùng đường với exit IP

Proxy thay đổi IP của lưu lượng HTTP, nhưng không tự động thay đổi DNS resolver. Nếu truy vấn DNS vẫn đi qua ISP cục bộ, trang kiểm tra sẽ thấy resolver ở một quốc gia khác với exit IP. Đây là một trong những mâu thuẫn bị cross-check trực tiếp và mạnh nhất: exit ở Mỹ, DNS ở Việt Nam, hoặc ngược lại.

BitBrowser cho phép cấu hình DNS theo từng profile, tách biệt với proxy, và có công cụ kiểm tra IP nội bộ để xác nhận không có DNS leak trước khi đưa profile vào vận hành. Điểm mấu chốt không phải là “không có DNS nào xuất hiện”, mà là resolver và exit IP phải kể cùng một câu chuyện địa lý.

3. Múi giờ: lệch một giờ là đủ

Múi giờ là tín hiệu bị đối chiếu tự động và gần như không thể ngụy biện bằng cách “ẩn”. Nếu exit IP ở Đức nhưng Intl.DateTimeFormat().resolvedOptions().timeZone trả về Asia/Ho_Chi_Minh, detector ghi nhận ngay timezone/language mismatch: vùng IP, JS-timezone và locale đang kể ba câu chuyện khác nhau.

BitBrowser đặt múi giờ theo từng profile, và trong chế độ chuyên gia người dùng chỉ định trực tiếp múi giờ khớp với thị trường mục tiêu. Điều quan trọng là tất cả các bề mặt phải đồng ý: IP exit, system clock, JS timezone, và header Date đều phải nằm trong cùng một vùng.

4. Ngôn ngữ: không chỉ navigator.language

Kiểm tra ngôn ngữ không dừng ở một thuộc tính. Detector đọc navigator.language, navigator.languages, Accept-Language header, và locale trong Intl API. Nếu IP ở Nhật nhưng navigator.language là vi-VN và Accept-Language chỉ có vi,en, mâu thuẫn xuất hiện ngay cả khi IP “đúng”.

BitBrowser cho phép đặt ngôn ngữ theo profile, độc lập với ngôn ngữ hệ điều hành. Cách đúng là chọn ngôn ngữ khớp với vùng của exit IP, không phải ngôn ngữ mẹ đẻ của người vận hành.

5. Client Hints: lớp bị bỏ quên sau User-Agent

Từ khi Chrome áp dụng UA Reduction, chuỗi User-Agent không còn đủ chi tiết. Các Client Hints (Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version, Sec-CH-UA-Arch) trở thành lớp thông tin thứ hai, và chúng thường mâu thuẫn với UA string nếu cấu hình không đồng bộ: UA nói macOS nhưng Sec-CH-UA-Platform nói Windows. Detector không cần biết cái nào “đúng”; chỉ cần thấy hai lớp không khớp là đủ để nghi vấn.

BitBrowser quản lý User-Agent và các tham số fingerprint liên quan trong cùng một profile, giảm khả năng xảy ra trạng thái “UA một đằng, Client Hints một nẻo” khi cấu hình thủ công từng lớp riêng lẻ.

6. Canvas và Font: nhiễu quá tay cũng là dấu vết

Canvas fingerprint cần ổn định trong một profile và khác biệt giữa các profile. Hai lỗi thường gặp: (a) canvas giống hệt nhau trên mọi profile vì cùng render engine, cùng GPU, cùng font — xảy ra khi chỉ xoay proxy mà không đổi fingerprint; (b) nhiễu canvas bị phát hiện là “tampering/noise” vì thuật toán noise quá thô, tạo ra pattern không tự nhiên.

BitBrowser cung cấp Canvas fingerprint noise và ngẫu nhiên hóa danh sách font trên từng profile, với mục tiêu tạo ra sự khác biệt trông tự nhiên, không phải khác biệt giả tạo. Đây là điểm mà các công cụ “chỉ đổi proxy” không bao giờ chạm tới.

7. Độ phân giải, GPU và WebGL: phần cứng không khớp với hệ điều hành khai báo

Nếu profile khai báo macOS nhưng WebGL renderer trả về DirectX/ANGLE hoặc SwiftShader/llvmpipe, đó là mâu thuẫn phần cứng-hệ điều hành không thể che bằng proxy. Tương tự, độ phân giải màn hình phải hợp lý so với thiết bị được khai báo; một profile “MacBook” với độ phân giải 800×600 là bất thường.

BitBrowser quản lý các tham số fingerprint phần cứng theo từng profile, bao gồm thông tin GPU/WebGL và độ phân giải, trong cùng một giao diện cấu hình với múi giờ, ngôn ngữ và proxy.

Tổng kết: vấn đề không phải là “che”, mà là “nhất quán”

Điểm chung của cả 7 điểm rò rỉ là: detector không tìm một tín hiệu “xấu” duy nhất, nó tìm sự mâu thuẫn giữa các tín hiệu. Một profile có WebRTC rỗng, DNS lệch quốc gia, múi giờ sai, ngôn ngữ không khớp và Canvas bị noise thô là một profile bị chấm điểm thấp ngay cả khi IP proxy hoàn toàn sạch.

BitBrowser tiếp cận theo hướng ngược lại: thay vì vá từng lỗ rò rỉ riêng lẻ, nó quản lý toàn bộ bề mặt fingerprint trong một profile độc lập — proxy, DNS, múi giờ, ngôn ngữ, User-Agent, Client Hints, WebRTC, Canvas, font, GPU/WebGL — để các lớp thông tin kể cùng một câu chuyện. Với các bản cập nhật gần đây, BitBrowser bổ sung chế độ thay thế WebRTC an toàn và UDP cho SOCKS5, xử lý trực tiếp điểm yếu cấu trúc của WebRTC sau proxy.

Nếu chỉ có một nguyên tắc cần nhớ: đừng kiểm tra “đã ẩn được gì”, hãy kiểm tra “giá trị thật có xuất hiện đúng chỗ không”. Một bề mặt bị triệt tiêu là một bề mặt bị phát hiện, không phải một bề mặt an toàn.