Các nhà phát triển sử dụng Playwright để cào dữ liệu web đang thấy yêu cầu đầu tiên của họ bị từ chối mặc dù script đã khởi chạy một phiên bản Chromium đầy đủ, thiết lập User-Agent thật và chèn các khoảng trễ giống con người. Máy chủ chặn yêu cầu ngay trong quá trình bắt tay TLS (TLS handshake), một kỹ thuật được gọi là TLS fingerprinting (dấu vân tay TLS).

Giải thích về TLS fingerprinting

Khi một trình duyệt mở một kết nối HTTPS, nó gửi một thông điệp ClientHello. Gói tin này liệt kê phiên bản TLS, các bộ mã hóa (cipher suites) được hỗ trợ, một tập hợp các phần mở rộng (đường cong elliptic, thuật toán chữ ký) và một vài trường khác. Sự kết hợp chính xác này sẽ định danh duy nhất ngăn xếp mạng (networking stack).

Các nhà nghiên cứu băm các trường thô đó thành một mã định danh gọn nhẹ gọi là JA3 (hoặc phiên bản mới hơn là JA4). Một trình duyệt Chrome thật sẽ tạo ra một mã băm; một thư viện HTTP của Python sẽ tạo ra một mã khác. Nếu mã băm của máy chủ không khớp với User-Agent được khai báo, nó sẽ đánh dấu yêu cầu đó là do script thực hiện.

Tại sao trình duyệt Playwright mặc định vẫn có thể bị đánh dấu

Bản build Chromium mặc định của Playwright thường phát ra dấu vân tay Chrome chính xác, nhưng nhiều trình cào dữ liệu (scrapers) lại thêm các bước làm mất tính nhất quán:

  1. Chiến lược yêu cầu hỗn hợp – Các nhà phát triển thường để Playwright render các trang nặng trong khi một HTTP client nhẹ nhàng đi lấy các tài nguyên bổ trợ (JSON, hình ảnh, v.v.). Những lệnh gọi nhanh đó mang dấu vân tay của thư viện chứ không phải của Chrome, và máy chủ sẽ phát hiện ra sự không khớp ngay lập tức.
  2. Proxy kết thúc TLS (TLS-terminating proxies) – Một số dịch vụ proxy giải mã luồng TLS, kiểm tra hoặc sửa đổi lưu lượng, sau đó mã hóa lại. Cuối cùng, máy chủ sẽ thấy dấu vân tay của proxy và có thể chặn nó vì coi đó là một client không phải trình duyệt.
  3. Các lớp giao thức khác – Các hệ thống chống cào dữ liệu cũng so sánh các thiết lập HTTP/2, thứ tự header và uy tín IP (IP reputation). Bất kỳ sự sai lệch nào ở bất kỳ lớp nào cũng có thể kích hoạt việc chặn.

Từ JA3 đến JA4: cuộc chạy đua vũ trang

JA3 là dấu vân tay TLS đầu tiên được áp dụng rộng rãi. Chrome hiện đang ngẫu nhiên hóa thứ tự các phần mở rộng của nó trong mỗi lần khởi chạy, khiến mã băm JA3 trở nên không ổn định đối với một trình duyệt thực. JA4 giải quyết vấn đề này bằng cách sắp xếp danh sách phần mở rộng trước khi băm, tạo ra một mã định danh ổn định ngay cả khi Chrome xáo trộn thứ tự. Các công cụ phát hiện áp dụng JA4 có thể phân biệt một cách đáng tin cậy giữa các phiên bản Chrome thực và các client chạy bằng script vốn chỉ sao chép một mã băm JA3 tĩnh.

Những gì nhà phát triển có thể làm ngay hôm nay

Không có "chuỗi ma thuật" nào có thể đánh lừa máy chủ mãi mãi. Cách tiếp cận đáng tin cậy là làm cho mọi lớp của yêu cầu đều kể cùng một câu chuyện:

  • Đồng bộ hóa User-Agent, TLS handshake, thiết lập HTTP/2 và thứ tự header với cùng một phiên bản trình duyệt và hệ điều hành.
  • Ngừng việc kết hợp một công cụ tự động hóa trình duyệt đầy đủ với một HTTP client riêng biệt. Nếu tốc độ là quan trọng, hãy để Playwright xử lý tất cả các lệnh gọi mạng, ngay cả những lệnh gọi đơn giản nhất.
  • Chọn các proxy có khả năng chuyển tiếp TLS (pass TLS through) mà không kết thúc kết nối, hoặc cấu hình chúng để chuyển tiếp TLS handshake gốc mà không thay đổi.
  • Theo dõi các dịch vụ uy tín IP; một nhóm IP sạch sẽ làm giảm khả năng bị chặn dựa trên lịch sử lạm dụng.

Cái giá của việc bỏ qua tính nhất quán của dấu vân tay

Khi một trình cào dữ liệu bị chặn ở giai đoạn bắt tay, nó không bao giờ chạm tới logic của trang, vì vậy không có dữ liệu nào được thu thập và không có thời gian nào bị lãng phí để thực thi JavaScript. Các doanh nghiệp dựa vào việc thu thập dữ liệu quy mô lớn sẽ thấy chi phí tính toán đám mây tăng lên khi các vòng lặp thử lại (retry loops) bắt đầu chạy. Việc bị chặn liên tục cũng có thể dẫn đến việc bị cấm IP (IP bans), gây ảnh hưởng đến các lưu lượng hợp lệ khác từ cùng một mạng.

Quan điểm ngược lại: tại sao các trang web sử dụng TLS fingerprinting

Chủ sở hữu trang web coi TLS fingerprinting là một biện pháp phòng thủ hợp pháp. Việc cào dữ liệu tự động có thể làm quá tải máy chủ, vượt qua tường phí (paywalls) hoặc thu thập dữ liệu cá nhân ở quy mô lớn. Bằng cách kiểm tra xem dấu vân tay TLS có khớp với trình duyệt được khai báo hay không, một trang web có thể lọc bỏ một nhóm lớn các bot kém tinh vi mà không làm ảnh hưởng đến người dùng thật. Kỹ thuật này ít xâm phạm hơn so với CAPTCHA, giúp bảo tồn trải nghiệm người dùng.

Những gì cần theo dõi tiếp theo

  • Sự áp dụng JA4 – Dự kiến sẽ có nhiều nhà cung cấp bảo mật và nhà cung cấp CDN triển khai phát hiện dựa trên JA4 trong những tháng tới.
  • Sự ngẫu nhiên hóa ở cấp độ trình duyệt – Chrome và các trình duyệt khác có thể tiếp tục thay đổi các tham số TLS, đẩy các công cụ fingerprinting hướng tới các tín hiệu phức tạp hơn như thời gian lưu lượng hoặc các mẫu thực thi JavaScript.
  • Phản ứng của thị trường proxy – Các dịch vụ hứa hẹn định tuyến "TLS-transparent" (trong suốt TLS) có khả năng sẽ xuất hiện, đáp ứng nhu cầu của cộng đồng cào dữ liệu về việc giữ nguyên TLS handshake.

Bài học rút ra

Nếu trình thu thập dữ liệu Playwright của bạn bị từ chối trước khi bất kỳ trang nào kịp tải, nguyên nhân gần như chắc chắn là do sự không khớp trong TLS fingerprint. Cách khắc phục không phải là một bản vá nhanh chóng; nó đòi hỏi sự đồng bộ hóa một cách bài bản giữa mọi lớp giao thức với hồ sơ trình duyệt đã khai báo. Sự nhất quán giữa User-Agent, TLS handshake, các thiết lập HTTP/2, thứ tự header và hành vi proxy là cách đáng tin cậy duy nhất để tránh sự chú ý của các hệ thống phòng chống thu thập dữ liệu hiện đại.