Chỉ một năm trước, sơ đồ rất rõ ràng: bạn lấy một khách hàng biết cách giả mạo bắt tay TLS, chọn một hồ sơ cho Chrome mới nhất, nhận được JA4 trùng khớp — và anti-bot sẽ cho phép qua. Vào năm 2026, công thức này bắt đầu gặp trục trặc vì một lý do không liên quan gì đến "vòng qua bảo vệ". Các trình duyệt đã chuyển sang trao đổi khóa hậu lượng tử hàng loạt, trong khi hầu hết các stack scraping thì không. Và giờ đây, việc thiếu chia sẻ khóa hậu lượng tử tự nó trở thành dấu hiệu của tự động hóa.
Chúng ta hãy phân tích theo các tiêu chí: điều gì đã thay đổi trong bắt tay, những stack nào đã chuyển đổi, những stack nào chưa, và tại sao băm JA4 trùng khớp không còn là điều kiện đủ.
Điều gì đã xảy ra: trao đổi hậu lượng tử đã trở thành tiêu chuẩn, không còn là điều kỳ lạ
Trao đổi khóa hậu lượng tử hỗn hợp — là sự kết hợp giữa đường cong elliptic cổ điển X25519 và cơ chế lưới ML-KEM (tiêu chuẩn NIST FIPS 203). Phiên làm việc vẫn được bảo vệ nếu ít nhất một trong hai thành phần là bền vững. Ý nghĩa là bảo vệ khỏi kịch bản "bắt băng qua, giải mã sau", khi lưu lượng được ghi vào kho lưu trữ với hy vọng vào máy tính lượng tử trong tương lai.
Thời gian triển khai trên các khách hàng:
- Chrome 124 (tháng 4 năm 2024) — trao đổi hậu lượng tử hỗn hợp được bật theo mặc định; trong các bản vá curl-impersonate, điều này được ghi nhận là "các đường cong X25519Kyber768/X25519MLKEM, được giới thiệu trong Chrome 124 và 130".
- Firefox 132 (tháng 11 năm 2024) — hỗ trợ đã được kích hoạt.
- Safari trên iOS và macOS — trao đổi hậu lượng tử đã đến vào tháng 10 năm 2025.
- OpenSSL 3.5.0 (tháng 4 năm 2025) — các nhóm hỗn hợp X25519MLKEM768, SecP256r1MLKEM768 và SecP384r1MLKEM1024 đã được đưa vào danh sách nhóm TLS mặc định.
- Go 1.24 (tháng 2 năm 2025) — X25519MLKEM768 được đưa vào crypto/tls theo mặc định, nếu Config.CurvePreferences không được chỉ định rõ ràng.
Về phía hạ tầng, bức tranh còn rõ ràng hơn. Cloudflare Radar vào tháng 4 năm 2026 cho thấy khoảng 67% lưu lượng HTTPS của con người với mã hóa hậu lượng tử — so với 32% vào tháng 1 năm 2025. Akamai đã làm cho trao đổi khóa hậu lượng tử trở thành mặc định cho tất cả các kết nối khách hàng vào 31 tháng 1 năm 2026, hoàn thành việc triển khai trên toàn mạng vào tháng 3. Theo các đo lường trong ngành, khoảng 57,4% tất cả các giao dịch trình duyệt đã sẵn sàng cho hậu lượng tử, trong đó tỷ lệ của Chrome có khả năng PQ là khoảng 93%.
Lưu ý sự không đối xứng: hỗ trợ từ phía máy chủ gốc tăng trưởng chậm hơn nhiều (tại Cloudflare — khoảng 9%). Điều này có nghĩa là hậu lượng tử ngày nay chủ yếu là một đặc điểm của khách hàng. Chính xác là điều mà anti-bot quan tâm.
Tiêu chí 1: kích thước chia sẻ khóa và cấu trúc ClientHello
Chia sẻ khóa hậu lượng tử — không phải là "một cờ khác trong phần mở rộng". Nó lớn về mặt vật lý: khoảng 1124 byte so với 36 byte của X25519 cổ điển. Các hậu quả có thể thấy rõ bằng mắt thường ở cấp độ gói tin.
ClientHello với chia sẻ khóa hậu lượng tử vượt quá 1400 byte và không còn vừa trong một đoạn TCP. Nó bị chia thành hai gói trở lên. Và sau đó, điều thú vị nhất cho việc phát hiện bắt đầu: mẫu phân mảnh ở các triển khai khác nhau là khác nhau. Cách mà stack cắt ClientHello lớn, thứ tự gửi các đoạn, với thời gian như thế nào — đó là hành vi quan sát được, không thể suy ra từ băm JA4 và hầu như không ai trong số các tác giả công cụ scraping tái tạo một cách có ý thức.
Kết luận thực tiễn: anti-bot đã có một lớp hoạt động thấp hơn dấu vân tay quen thuộc. Bạn có thể hoàn hảo thu thập danh sách các thuật toán mã hóa và phần mở rộng, nhưng bạn sẽ bị phát hiện bởi cách mà stack của bạn đặt byte vào socket.
Tiêu chí 2: sự nhất quán với phiên bản trình duyệt đã tuyên bố
Cái bẫy chính của năm 2026 — sự không đồng bộ giữa việc bạn tự giới thiệu và những gì thực sự làm với stack TLS của bạn.
Các nền tảng anti-bot giữ cơ sở dữ liệu của ClientHello tiêu chuẩn. Yêu cầu mà trong User-Agent và trong JA4 tuyên bố là Chrome 131, nhưng đến mà không có chia sẻ khóa hậu lượng tử, không trùng khớp với bất kỳ Chrome 131 hợp lệ nào đã biết. Đây không phải là "đáng nghi" — đây là một sự kết hợp logic không thể. Một Chrome thực sự của phiên bản đó về mặt vật lý không thể gửi chia sẻ khóa cổ điển với các cài đặt mặc định.
Độ chính xác của việc phân tách này bằng học máy cũng đã được tính toán. Bộ phân loại CatBoost dựa trên các đặc điểm JA4 trong các nghiên cứu cho thấy AUC 0,998 và độ chính xác 0,9863; riêng lưu lượng hậu lượng tử khác biệt với cổ điển với độ chính xác khoảng 98%. Đây không phải là "heuristic với các cảnh báo giả", mà là một đặc điểm gần như xác định.
Tiêu chí 3: sự sẵn sàng của các stack cụ thể
Đây là nơi mà ranh giới thực sự được thiết lập. Chúng ta hãy phân loại theo nhóm.
Gửi PQ chia sẻ khóa theo mặc định
- Chrome 124+, Firefox 132+, Safari (iOS/macOS từ tháng 10 năm 2025) — tiêu chuẩn mà bạn được so sánh.
- Go 1.24+ — crypto/tls tự động bao gồm X25519MLKEM768 nếu bạn không ghi đè CurvePreferences. Một điểm quan trọng: có hậu lượng tử, nhưng JA4 của khách hàng Go trống vẫn không phải là trình duyệt. Bạn nhận được "dấu vân tay tương thích PQ, nhưng không giống Chrome".
- Node.js 24 — mang theo OpenSSL 3.5 của riêng mình, vì vậy danh sách nhóm mặc định đã bao gồm hỗn hợp. Thêm vào đó, trong node:crypto đã xuất hiện ML-KEM thông qua crypto.encapsulate()/decapsulate() và ML-DSA trong sign()/verify().
Phụ thuộc vào những gì được liên kết
- Python: requests, aiohttp, httpx — sử dụng mô-đun ssl, và nó lấy OpenSSL hệ thống. Trên Ubuntu 24.04, hệ thống đang chạy OpenSSL 3.0.x, nơi không có nhóm hậu lượng tử nào. Để có được PQ, bạn cần biên dịch OpenSSL 3.5 từ mã nguồn, đặt nó qua LD_LIBRARY_PATH và, có thể, phải biên dịch lại Python. Trong thực tế, điều này có nghĩa là: một scraper Python điển hình vào năm 2026 gửi chia sẻ khóa cổ điển và trên Akamai trông như một hiện tượng bất thường.
Có khả năng, nhưng chỉ nếu chọn đúng hồ sơ
- curl_cffi / curl-impersonate — hỗ trợ các đường cong hậu lượng tử trong fork có và được tuyên bố rõ ràng. Nhưng danh sách mục tiêu kéo dài từ chrome99 đến chrome146 (trong fork — đến chrome150), và các hồ sơ cũ tái tạo bắt tay của thời đại của chúng, tức là không có PQ. Sao chép
impersonate="chrome116"từ hướng dẫn hai năm trước — là con đường thẳng đến việc bị phát hiện. - uTLS — cùng một nguyên tắc: các hồ sơ HelloChrome dưới 131 không chứa chia sẻ khóa PQ. Thêm vào đó, trong thư viện năm 2026 đã đóng hai lỗ hổng dấu vân tay: CVE-2026-26995 (các phiên bản 1.6.0–1.8.1) và CVE-2026-27017 (1.6.0–1.8.0, sự không đồng bộ trong việc chọn thuật toán mã hóa cho GREASE ECH — Chrome chọn nó một cách xác định, trong khi parrot trong uTLS đã tung đồng xu giữa AES và ChaCha20, điều này là không thể với Chrome thực sự). Cần phải cập nhật ít nhất lên 1.8.2.
Điểm chung: các công cụ chủ yếu đã theo kịp. Vấn đề không nằm ở chúng, mà ở việc các cấu hình lạc hậu nhanh hơn so với các trình duyệt. Hồ sơ mà đã hoàn hảo vào năm 2024, hôm nay hoạt động như một dấu hiệu.
Cách kiểm tra stack của bạn trong năm phút
- Gửi yêu cầu từ khách hàng chiến đấu của bạn đến
https://tls.peet.ws/api/allhoặcja4db.com— chúng trả về JA3/JA4 sống và phân tích ClientHello trong JSON. - Tìm trong phân tích danh sách supported_groups và key_share. Tìm X25519MLKEM768 (hoặc X25519Kyber768 trong các hồ sơ cũ). Nếu chỉ có x25519/secp256r1 — không có trao đổi hậu lượng tử.
- So sánh điều này với phiên bản trình duyệt mà bạn tự giới thiệu. Tuyên bố Chrome 131+ và không thấy các nhóm PQ — sự kết hợp không hợp lệ, hãy sửa hồ sơ.
- Xem kích thước ClientHello. Nhỏ hơn ~1400 byte khi tuyên bố Chrome mới — đó là dấu hiệu tương tự, chỉ ở phía bên kia.
- Chạy kiểm tra từ mỗi nút đầu ra, không chỉ từ máy làm việc: kiểm tra SSL trên cổng doanh nghiệp hoặc nhà cung cấp có thể ghi lại bắt tay thay cho bạn.
Proxy đang làm gì ở đây
Quan trọng là không trộn lẫn hai lớp độc lập. Chia sẻ khóa hậu lượng tử — là về bắt tay, danh tiếng của địa chỉ — là về mạng. Anti-bot xem xét chúng riêng biệt và cộng dồn lại.
Từ đó, có hai hệ quả thực tiễn. Đầu tiên: một IP cư trú lý tưởng sẽ không cứu được yêu cầu mà ở cấp độ TLS tự giới thiệu là Chrome 131 mà không có nhóm PQ — bạn sẽ thua ngay cả trước khi máy chủ nhìn vào địa chỉ. Thứ hai, ngược lại: một bắt tay hậu lượng tử được cấu hình đúng sẽ không giúp ích gì nếu hàng trăm phiên của bạn đến từ một subnet trung tâm dữ liệu với danh tiếng bị hỏng. Cần phải sửa cả hai lớp, và chúng được sửa bằng các công cụ khác nhau.
Phân tích thực tiễn theo các nhiệm vụ: cho các mục tiêu phía sau Akamai và Cloudflare, nơi tính toán cả bắt tay và mạng, hợp lý để lấy proxy cư trú và đồng thời nâng cấp mục tiêu impersonate lên Chrome mới nhất. Đối với các ứng dụng di động và các nền tảng mà trọng số danh tiếng IP cao hơn yêu cầu về TLS, thường thì proxy di động sẽ thắng lợi hơn. Còn đối với API riêng, các xuất dữ liệu đối tác và giám sát nội bộ, nơi không có anti-bot, việc trả thêm tiền cho cư trú không có ý nghĩa — chỉ cần proxy trung tâm dữ liệu là đủ.
Nếu bạn đang tìm hiểu về dấu vân tay từ đầu, hãy bắt đầu từ cơ sở: cách JA4 hoạt động và những gì nó bao gồm. Và khi nói đến không phải là HTTP-client mà là một trình duyệt hoàn chỉnh, sự so sánh giữa các bản dựng stealth và các điểm yếu của chúng đã được tập hợp riêng — nodriver, Camoufox và Patchright trong các phép đo năm 2026.
Kết luận
Trao đổi khóa hậu lượng tử không được thiết kế như một cơ chế chống bot. Nó đã trở thành điều đó một cách gián tiếp: các trình duyệt đã chuyển sang nó nhanh chóng và hàng loạt, hạ tầng (Akamai — từ 31 tháng 1 năm 2026) đã làm cho nó trở thành mặc định, và các stack scraping đã phân chia thành ba nhóm — đã chuyển đổi, phụ thuộc vào OpenSSL hệ thống và chỉ có khả năng khi có hồ sơ mới.
Việc kiểm tra chỉ gói gọn trong một câu hỏi: liệu khách hàng của bạn có gửi X25519MLKEM768 và có tương thích với phiên bản trình duyệt mà bạn tự giới thiệu không. Nếu không — JA4 trùng khớp sẽ không cứu bạn, vì bây giờ người ta so sánh không chỉ băm mà toàn bộ hình thức bắt tay: kích thước chia sẻ khóa, số lượng đoạn TCP và thứ tự gửi chúng. Tin tốt là điều này có thể được sửa trong hầu hết các trường hợp bằng cách cập nhật hồ sơ và phiên bản thư viện, chứ không phải viết lại scraper.