Thiết lập khuyến nghị — nên bật gì và nên để nguyên gì

Phần lớn các trường hợp bị chặn mà chúng tôi truy ra nguyên nhân nằm ở cấu hình đều là do giả mạo nhiều hơn, chứ không phải ít hơn. Trang này là bản tóm tắt những gì chúng tôi đã đo: các thiết lập đáng dùng, những thiết lập mà cái giá phải trả lớn hơn lợi ích mang lại, và một số ít vấn đề mà không thiết lập nào khắc phục được.

Bắt đầu từ đây

Nếu bạn không đọc gì khác trên trang này, thì đây là cấu hình để bắt đầu. Nó thay đổi những trục có thể thay đổi một cách an toàn, và giữ nguyên phần render, TLS và phiên bản trình duyệt.

import { launch } from "clearcote";

const browser = await launch({
  lightStealth: true,        // metadata identity only — rendering, TLS and version stay real
  fingerprint: "account-42", // picks this identity's metadata bundle; keep it stable per identity
  proxy: { server: "http://gateway:8080", username: "u", password: "p" },
  geoip: true,               // timezone + languages + the address WebRTC reports follow the proxy exit
  humanize: true,            // trusted native input; navigator.webdriver stays false
});

Python có cùng bộ API, viết theo snake_case: light_stealth, fingerprint, geoip, humanize. Hãy thêm các trục khác một cách có chủ đích, từng trục một, và chỉ khi bạn nói được thứ gì trên host sẽ xác nhận cho chúng. Một số dòng bên dưới — các control hẹp của r12, humanize bằng chuyển động được ghi lại, socks5Udp, các switch về cookie bên thứ ba và proxy — áp dụng cho bản build có giấy phép (Miễn phí với GitHub hoặc Pro). Bản build mở bỏ qua chúng: humanize quay về dùng đường di chuyển được sinh ra, và proxy SOCKS5 có mật khẩu sẽ từ chối kết nối.

Nguyên tắc: mỗi giá trị giả mạo là một lời khẳng định mà host phải chứng minh được

Cơ chế phát hiện không đi tìm các giá trị bất thường. Nó đi tìm mâu thuẫn — hai tín hiệu không thể cùng đúng trên một máy. Một giá trị bình thường mà không ai giả mạo thì không mâu thuẫn với điều gì. Một giá trị giả mạo mà không có gì đứng sau lại là một tín hiệu dương tính, và còn là tín hiệu mạnh hơn cả giá trị mà nó đang che giấu.

Vì vậy, câu hỏi hữu ích trước khi bật bất kỳ tùy chọn nào không phải là “giá trị này có hợp lý không?” mà là “trên máy này có gì có thể được hỏi để xác nhận nó, và câu trả lời có khớp không?” Kích thước màn hình được đối chiếu với bề mặt render. Chuỗi GPU được đối chiếu với các pixel mà GPU tạo ra. Hệ điều hành được khai báo được đối chiếu với các font mà nền tảng phân giải. Nếu host không chứng minh được lời khẳng định đó, thì giá trị thật là lựa chọn an toàn hơn. Xem Cơ chế phát hiện hoạt động thế nào để hiểu chi tiết.

Nên làm

Nên tránh

Mỗi mục dưới đây là điều chúng tôi đã đo được là gây lỗi, không phải một lời cảnh báo chung chung.

Proxy

Proxy thường quyết định kết quả nhiều hơn bất kỳ cờ trình duyệt nào, và lại là thứ hay bị để mặc định nhất.

• IP đầu ra cố định (sticky). Mỗi danh tính một IP đầu ra, giữ nguyên trong suốt phiên. Một phiên có IP thay đổi giữa chừng sẽ tự mâu thuẫn với chính nó, bất kể fingerprint tốt đến đâu.
• Khớp vị trí địa lý với persona, rồi để geoip: true suy ra múi giờ và ngôn ngữ thay vì tự đặt bằng tay.
• Proxy có thông tin đăng nhập được giao cho engine xử lý. Mật khẩu proxy HTTP(S) do chính trình duyệt trả lời (bản build có giấy phép 151 r19+, SDK Python & Node), nên page cache vẫn bật và request không bị đánh dấu bởi interception. SOCKS5 có mật khẩu hoạt động trực tiếp trên bản build có giấy phép — hãy truyền username và password thành các trường riêng. transparentProxy: true (152 r22+) ẩn proxy khỏi request header và timing của kết nối.
• Hiểu rõ sự đánh đổi của WebRTC. Chromium không bao giờ gửi media qua proxy HTTP hay SOCKS, nên nếu không xử lý thì lưu lượng peer sẽ đi qua kết nối thật của bạn, nơi một relay có thể đọc được địa chỉ thật của bạn. Vì vậy SDK chặn các gói WebRTC UDP không đi qua proxy. Trên bản build mở, geoip / webrtcIp gỡ bỏ việc chặn đó; bản build có giấy phép thì vẫn giữ. Hãy kết hợp với geoip: true (hoặc webrtcIp) để trang vẫn thấy các candidate mà một Chrome thật tạo ra, báo cáo địa chỉ của proxy; không có nó, WebRTC không thu thập được gì, và điều đó trông như đã bị chặn. Để có kết nối peer hoạt động qua proxy SOCKS5, hãy đặt socks5Udp: true (bản build có giấy phép; nhà cung cấp của bạn phải cho phép relay UDP), hoặc dùng một tunnel toàn phần (WireGuard/OpenVPN) không có proxy trình duyệt và tự truyền --webrtc-ip-handling-policy trong args. Ngoài những trường hợp đó, hãy giữ chính sách chặn mặc định.

Những gì thiết lập không khắc phục được

Một số bề mặt bị đọc nhiều nhất lại do chiếc máy bạn thuê quyết định, chứ không phải trình duyệt bạn chạy trên đó.

Kiểm tra thay vì phỏng đoán

Mọi khẳng định trên trang này đều đo được từ bên trong trình duyệt. Hãy trỏ phiên đã cấu hình của bạn tới trang audit và đọc những dòng mà nó báo là không khớp — đó cũng chính là bộ công cụ chúng tôi đã dùng để tìm ra các vấn đề mô tả ở trên, và nó sẽ cho bạn biết cấu hình hiện tại của bạn đang vi phạm khuyến nghị nào trong số này.