TLS handshake là ngưỡng tối thiểu để phát hiện bot
98.6%.
Đó là độ chính xác phân loại mà một mô hình CatBoost đạt được khi chỉ sử dụng các đặc trưng JA4. Không header. Không IP. Không hành vi. Chỉ dựa vào cấu trúc của TLS handshake. Bài báo nghiên cứu trên arXiv xuất hiện vào tháng 2 năm 2026, và kết quả này không phải là một ngoại lệ. Cloudflare, AWS, VirusTotal, và Akamai đều đang chạy JA4 (hoặc phiên bản tiền nhiệm của nó là JA3) trên môi trường production. Nếu bạn đang thực hiện scraping vào năm 2026 bằng một HTTP client thông thường, phán quyết đã được đưa ra trước khi request của bạn tiếp cận tầng ứng dụng (application layer).
Đây là phần mà các bài hướng dẫn phát hiện bot thường bỏ qua. Hầu hết các bài viết về việc vượt qua anti-bot vẫn xoay quanh việc xoay vòng User-Agent, cookie, và CAPTCHA. Đó là những tầng dễ dàng. Nhưng tầng TLS là nơi bạn không thể đánh lừa bằng một header.
JA4 thực sự nhìn thấy gì
JA4 là một fingerprint của TLS ClientHello. Nó mã hóa giao thức (TCP hoặc QUIC), phiên bản TLS, sự hiện diện của SNI, các cipher suite được sắp xếp theo thứ tự, các extension, thuật toán chữ ký, và ALPN. Đầu ra là một chuỗi rút gọn như t13d1516h2_8daaf6152771_e5627906d626. Hai client tự nhận là cùng một trình duyệt sẽ tạo ra cùng một hash JA4. Một script Python requests tự nhận là Chrome sẽ tạo ra một JA4 không tồn tại ở bất kỳ đâu trên thế giới ngoại trừ trong các scraper.
Họ JA4 (được phát triển bởi FoxIO, cùng nhóm đứng sau JA3) đã giải quyết điểm yếu lớn nhất của JA3: hoán vị extension, điều mà Chromium đã giới thiệu vào năm 2023 để phá vỡ các phương pháp fingerprinting thô sơ. JA4 sắp xếp các extension và đếm chúng, vì vậy việc ngẫu nhiên hóa không mang lại tác dụng. Không có lối thoát dễ dàng nào cả.
Akamai đã tiết lộ độ chính xác phân loại bot từ 92-98% thông qua phân tích đa tầng (cross-layer). Phần phân tích đa tầng này rất quan trọng. Chỉ riêng TLS đã là tín hiệu vượt trội, nhưng việc kết hợp nó với thứ tự frame HTTP/2, thứ tự header, và thời gian request sẽ đẩy tỷ lệ dương tính giả (false-positive) xuống mức thấp hơn nhiều so với những gì hầu hết các scraper có thể chịu đựng.
Bước ngoặt post-quantum
Đây là điều không ai lường trước được. Vào ngày 31 tháng 1 năm 2026, Akamai đã đặt trao đổi khóa post-quantum làm mặc định cho tất cả các kết nối. Đến đầu năm 2026, 57.4% các kết nối thực tế do trình duyệt khởi tạo đã bao gồm key share X25519MLKEM768. Tỷ lệ hỗ trợ PQ của Chrome nằm ở mức khoảng 93%. Firefox 132 đạt 85%. Safari đang được triển khai.
Key share PQ rất lớn. 1,124 byte so với 36 byte của X25519 cổ điển. ClientHello đã tăng từ 300-500 byte lên hơn 1,400 byte. Sự tăng trưởng đó thể hiện rõ trong JA4, trong việc bắt gói tin (packet capture), và trong việc giám sát thụ động tại WAF.
Nếu client scraping của bạn không bao gồm key share PQ, bạn đang đưa ra một khẳng định mà không có trình duyệt Chrome hoặc Firefox hiện tại nào thực hiện. Hai CVE từ quý đầu tiên của năm 2026 đã cảnh báo chính xác sự không khớp này: CVE-2026-26995 (padding extension) mang lại xác suất phát hiện 25-50% trên mỗi request, và CVE-2026-27017 (sự không khớp giữa ECH và GREASE) rơi vào khoảng 50%. Khi kết hợp lại trong suốt một session, khả năng bị phát hiện sẽ tăng lên gần như chắc chắn.
Đây là một vấn đề vốn cần 12 tháng nay đã chuyển thành vấn đề 3 tháng. Hầu hết các stack scraping mã nguồn mở vẫn chưa hỗ trợ TLS tương thích với PQ. Những stack đã hỗ trợ thì vẫn đi sau Chromium thực tế vài tuần.
Tại sao proxy không giải quyết được vấn đề này
Có một câu chuyện an ủi đang được lan truyền rằng các pool proxy lớn hơn sẽ giải quyết được vấn đề phát hiện bot hiện đại. Thực tế không phải vậy. Sự cố scalping vào tháng 1 năm 2026 được đưa tin bởi Security Boulevard đã sử dụng 16 triệu request trên 3.9 triệu IP duy nhất. Việc chặn theo từng IP đã trở nên vô dụng. Biện pháp phòng thủ hiệu quả phần lớn là TLS và fingerprinting hành vi.
Tính kinh tế của residential proxy cũng đã bị phá vỡ trong quý này. Help Net Security đã báo cáo vào tháng 4 năm 2026 rằng sự gián đoạn của mạng lưới IPIDEA vào tháng 1 đã làm giảm khoảng 40% dung lượng residential proxy của toàn ngành chỉ sau một đêm. Cuộc chiến bằng sáng chế giữa Bright Data và Oxylabs (Tòa án Tối cao đã bác bỏ đơn kiến nghị của Bright Data vào ngày 23 tháng 2 năm 2026, với phiên tòa được ấn định vào ngày 18 tháng 5) chỉ là một câu chuyện bên lề so với tổn thất dung lượng đó. Những người mua đang săn lùng residential IP như một biện pháp phòng thủ chống lại fingerprinting đang phải trả nhiều tiền hơn cho một giải pháp mà WAF thậm chí không bận tâm.
Proxy vẫn quan trọng, chỉ là không phải vì lý do mà hầu hết mọi người nghĩ. Phân bổ địa lý và loại ISP định hình các quyết định định tuyến (routing) và hồ sơ rate limit. Chúng không giúp bạn vượt qua được quá trình handshake.
Điều này có ý nghĩa gì đối với các đội ngũ dữ liệu
Ba điều sẽ thay đổi nếu bạn đang xây dựng hoặc mua cơ sở hạ tầng scraping vào năm 2026.
Đầu tiên, TLS stack hiện là một yêu cầu bắt buộc. Bất kỳ client nào không giả lập TLS handshake của trình duyệt thực tế (PQ key share, thứ tự extension, ALPN, thuật toán chữ ký) đều tạo ra một fingerprint bị phân loại là bot với độ tin cậy cao. Việc bọc Python requests trong các header tốt hơn không giải quyết được gì. Giao thức truyền tải chính là dấu hiệu nhận biết.
Thứ hai, việc phát hiện trình duyệt headless ngày càng trở nên khó khăn hơn chứ không hề dễ dàng đi. Báo cáo State of Web Scraping 2026 của Browserless chỉ ra rằng khoảng cách giữa Chromium headless và Chromium thông thường đang ngày càng nới rộng. Các nhà cung cấp giải pháp anti-bot đã lập danh mục các điểm khác biệt về fingerprint và chia sẻ thông tin tình báo về mối đe dọa (threat intel) giữa các trang web của khách hàng trong thời gian gần như thực tế. Một instance headless hoạt động bình thường vào tháng 12 có thể bị phân loại là bot vào tháng 5. Các tín hiệu hành vi được xếp chồng lên trên TLS, và cả hai đều là những mục tiêu liên tục thay đổi.
Thứ ba, bài toán tự xây dựng so với mua ngoài (build-vs-buy) đã thay đổi. Việc duy trì một TLS fingerprint khớp với một mục tiêu liên tục thay đổi (Chromium phát hành các bản cập nhật PQ vài tuần một lần, thứ tự extension thay đổi giữa các phiên bản phụ, mức độ ưu tiên của cipher suite thay đổi) giờ đây là một công việc toàn thời gian. Các đội ngũ từng dành 20% thời gian của một kỹ sư để bảo trì scraper vào năm 2024 hiện đang phải dành hơn một nửa nhân sự vào năm 2026. Chúng tôi đã từng viết về lý do tại sao các scraper liên tục bị hỏng. Vào năm 2026, câu trả lời thường là "TLS" thay vì "DOM".
Scraper tiết kiệm chi phí nhất là scraper không bị phân loại
Dự đoán thú vị không phải là liệu các nhà cung cấp giải pháp anti-bot có tiếp tục nâng cao tiêu chuẩn hay không. Họ chắc chắn sẽ làm vậy. Dự đoán thú vị là công cụ scraping nào sẽ tồn tại trong một thị trường nơi độ chính xác 98% là ngưỡng phát hiện tối thiểu bắt buộc.
Hầu hết sẽ không thể. Nhưng những công cụ tồn tại được sẽ coi TLS handshake là một phần của request, chứ không phải là một chi tiết truyền tải thông thường. Và người mua sẽ bắt đầu hỏi các nhà cung cấp một câu hỏi vốn không có trong danh sách đánh giá của mười hai tháng trước: bạn cung cấp TLS fingerprint nào, và bạn cập nhật nó nhanh đến mức nào?
Quá trình handshake đã quyết định kết quả trước khi request có cơ hội thể hiện tính hợp lệ của mình.