Tất cả bài viết

Bên trong cờ Unblocker: `unblocker: true` thực sự hoạt động ra sao

Một cờ bật ba công tắc: các header trình duyệt thực, một chữ ký kết nối tương thích, và tự động giải nén cho gzip cùng brotli. Đây là cách nó hoạt động và lý do vì sao.

Hầu hết các scraper đều thất bại trước khi một header duy nhất được đọc.

Server sẽ xem xét chữ ký cấp độ kết nối mà client của bạn đặt trên đường truyền và quyết định xem bạn là một trình duyệt hay một thư viện client đang giả mạo làm trình duyệt. Python requests, net/http của Go, cURL thông thường: tất cả chúng đều đưa ra một dấu vân tay đặc trưng ngay khoảnh khắc chúng gửi lời chào. Các trang web có quan tâm (Datadome, Akamai, Imperva, khía cạnh được quản lý của Cloudflare) sẽ ngắt kết nối hoặc phục vụ bạn một trang thử thách trước khi chuỗi User-Agent của bạn kịp có ý nghĩa.

Đó là vấn đề mà unblocker: true giải quyết trên FourA. Trong tháng vừa qua, chúng tôi đã xác định được những thành phần giúp nó hoạt động ổn định.

Tính năng mới

unblocker: true là một cờ duy nhất trên bất kỳ lệnh gọi /api/single nào. Khi bạn bật nó lên, chúng tôi sẽ thực hiện ba việc: chèn bộ header của trình duyệt, gửi request qua một transport khớp với những gì một trình duyệt thực đưa lên đường truyền, và giải nén bất cứ thứ gì server trả về (gzip, brotli, deflate). Hai tính năng đầu tiên đã có từ bản beta. Tính năng thứ ba (tự động giải nén brotli) đã được phát hành vào ngày 25 tháng 3, và công việc cố định phiên bản đã được hoàn thành vào ngày hôm sau để giữ cho header và transport luôn đồng bộ.

Cách thức hoạt động

Đây là cấu trúc của một request:

curl -X POST "https://api.foura.ai/api/single" \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "url": "https://example.com/products",
    "method": "GET",
    "unblocker": true
  }'

Ba lớp hoạt động bên dưới.

Chèn Header. Chúng tôi thiết lập gói header trình duyệt hoàn chỉnh: User-Agent, Sec-Ch-Ua, Sec-Ch-Ua-Platform, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Accept, Accept-Language, và Accept-Encoding. Thứ tự rất quan trọng. Các trình duyệt thực phát ra các header này theo một trình tự cụ thể, và các thư viện phát hiện sẽ kiểm tra điều đó.

Chữ ký kết nối. Transport của chúng tôi khớp với hình dạng cấp độ byte của một phiên bản trình duyệt cập nhật: cùng thứ tự tiện ích mở rộng, cùng ưu tiên mã hóa, cùng các đặc thù handshake. Các cURL tiêu chuẩn, Python requests, và net/http của Go tạo ra các chữ ký bị máy đánh dấu trong vòng vài mili giây trên cơ sở hạ tầng được bảo vệ.

Tự động giải nén. Khi unblocker được bật, chúng tôi thiết lập Accept-Encoding thành gzip, deflate, br và transport sẽ mở gói phần body. Bạn nhận lại một chuỗi đã được giải mã (hoặc một Buffer nếu bạn truyền vào returnBuffer: true). Không cần xử lý brotli thủ công, không có sự không khớp giữa header và body khi một trang web chọn deflate thay vì gzip.

Tại sao việc cố định phiên bản lại quan trọng

Chữ ký kết nối bị khóa theo phiên bản. Các chi tiết cấp độ đường truyền của một trình duyệt trong tháng này không giống như tháng trước, và một trang web lấy dấu vân tay một cách cẩn thận sẽ nhận thấy sự sai lệch đó. Chúng tôi ghim các thành phần thay đổi lại với nhau để header, đối tượng navigator, và chữ ký kết nối đều báo cáo cùng một phiên bản trình duyệt.

Nếu điều đó nghe có vẻ rắc rối, thì đúng là như vậy. Chúng tôi đã bị ảnh hưởng bởi sự không khớp trong quá trình di chuyển monorepo vào tháng 3 khi một thành phần tự động cập nhật và các thành phần còn lại bị mất đồng bộ. Cách khắc phục là hai commit: ghim phần bị thay đổi, và không bao giờ tin tưởng package manager sẽ giữ mọi thứ thẳng hàng cho bạn.

Tác động

Trong các bài test nội bộ với các mục tiêu bị lấy dấu vân tay nghiêm ngặt (tài chính, du lịch, thương mại điện tử được bảo vệ), sự khác biệt giữa unblocker: falseunblocker: true là sự khác biệt giữa một trang thử thách và mã trạng thái 200. cURL thông thường khi truy cập Cloudflare được quản lý sẽ trả về 403 ngay lần đầu tiên. Cùng một URL đó với unblocker: true có thể vượt qua vì kết nối trông giống như một phiên bản trình duyệt ở cấp độ đường truyền.

Nhưng đối với các trang web không lấy dấu vân tay (hầu hết các API công khai, các mẫu CMS cũ hơn, bất cứ thứ gì chỉ bị chặn trên giới hạn tốc độ IP), việc tắt unblocker là ổn và giúp tiết kiệm vài mili giây cho quá trình đàm phán. Hãy sử dụng nó khi bạn cần.

Dành cho Power User

Một vài pattern đáng biết.

Kết hợp unblocker với một proxy dân cư khi mục tiêu cũng kiểm tra danh tiếng IP. IP Datacenter cộng với chữ ký kết nối hoàn hảo vẫn bị đánh dấu trên các ASN mà trang web đã cho vào danh sách đen. Endpoint proxy của chúng tôi (/api/proxy) xoay vòng theo domain mục tiêu, vì vậy việc thêm "proxy": "residential" vào request thường là đủ.

Bỏ qua unblocker khi gọi các JSON API không quan tâm đến trình duyệt. Các header bổ sung thực sự có thể trông đáng ngờ đối với một API mong đợi một client có thể lập trình được, ví dụ như một backend gọi microservice của riêng nó.

Nếu trang web chạy anti-bot bằng JavaScript (các thử thách tương tác Turnstile, PerimeterX ở mức nghiêm ngặt nhất, Akamai Bot Manager với bộ heuristic được tăng cường), thì chỉ riêng unblocker sẽ không đủ. Bạn cần endpoint browser, endpoint này thực thi thử thách trong một trình duyệt đầy đủ. Đó là một sản phẩm khác với mức giá credit khác, và chúng tôi đã viết về nó trong Browser Tasks: How to Scrape JavaScript-Heavy Sites.

Và bạn có thể kết hợp unblocker với khối validate để từ chối các response mà về mặt kỹ thuật trả về mã 200 nhưng chứa một trang thử thách:

{
  "url": "https://example.com/products",
  "method": "GET",
  "unblocker": true,
  "validate": {
    "data": { "fail": ["captcha", "Access Denied"] }
  }
}

Điều đó biến các lỗi âm thầm thành các lỗi đã được phân loại, điều này quan trọng đối với việc theo dõi tỷ lệ thành công của bạn trong dashboard.

Bước tiếp theo

Các trình duyệt phát hành bản stable mới cứ sau bốn tuần. Chúng tôi nâng cấp stack của mình để phù hợp. Bạn không cần phải chạm vào bất cứ thứ gì ở phía mình: unblocker: true tiếp tục trỏ vào bất kỳ phiên bản trình duyệt nào mà chúng tôi đã xác minh đầu cuối.

Công việc khó khăn hơn đang ở phía trước. Việc lấy dấu vân tay HTTP/3 đã xuất hiện trên các hệ thống anti-bot được quản lý, transport QUIC khó khớp hơn so với transport cũ hơn, và quá trình chuyển đổi khỏi các gói header tĩnh sang giả lập thực sự động đang bắt đầu. Các trang web được bảo vệ đã chuyển sang kiểm tra thứ tự frame HTTP/2, và khoảng cách giữa "thư viện trông giống như trình duyệt" và "một trình duyệt" sẽ bị thu hẹp từ cả hai phía. Chúng tôi sẽ viết về nó khi chúng tôi phát hành tính năng này.