← Quay lại blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Tại sao trình phân tích bị phát hiện qua dấu vân tay TLS ngay cả khi sử dụng IP dân cư sạch: cách kiểm tra và khắc phục

IP cư trú không bảo vệ khỏi việc bị chặn nếu dấu vân tay TLS của trình phân tích khác với dấu vân tay của trình duyệt thông thường. Phân tích cách kiểm tra và cấu hình đúng.

📅28 tháng 9, 2026

Bạn đã mua một IP cư trú đắt tiền, thiết lập quay vòng, thay thế User-Agent thực tế — nhưng trình phân tích vẫn bị chặn vào captcha hoặc nhận được phản hồi trống. Vấn đề hầu như luôn không phải ở IP, mà là ở dấu vân tay TLS: thư viện mà bạn gửi yêu cầu HTTPS, “phát ra” không giống như một trình duyệt thực sự. Các hệ thống chống bot của Wildberries, Ozon, Cloudflare và Akamai nhìn thấy điều này trước khi kiểm tra địa chỉ IP của bạn.

Dấu vân tay TLS là gì và tại sao nó quan trọng hơn IP

Khi khách hàng thiết lập kết nối HTTPS, họ gửi đến máy chủ một gói ClientHello — một phần của quá trình bắt tay TLS. Trong đó mã hóa danh sách các phiên bản TLS được hỗ trợ, bộ mã hóa (cipher suites), thứ tự các mở rộng (extensions), các đường cong elip và các thuật toán nén. Tập hợp các tham số này là duy nhất cho mỗi cặp “thư viện + hệ điều hành + phiên bản ngăn xếp TLS”.

Chrome, Firefox và Safari tạo ra ClientHello theo cách riêng của họ, và tập hợp này gần như không thay đổi từ yêu cầu này sang yêu cầu khác — trái ngược với IP hoặc User-Agent, dễ dàng giả mạo bằng văn bản. Còn các thư viện HTTP tiêu chuẩn — requests, urllib3, HttpClient tiêu chuẩn trong Java, ngăn xếp TLS tích hợp của Node.js — tạo ra một ClientHello hoàn toàn khác, vì chúng sử dụng OpenSSL hoặc thư viện khác theo cách khác với trình duyệt.

Chính vì vậy bạn có thể kết nối một IP cư trú “sạch” hoàn hảo, thay thế User-Agent mới nhất của Chrome thực — và vẫn bị chặn. Máy chủ thấy IP của người dùng từ một ngôi nhà cư trú, thấy tiêu đề “Chrome 124”, nhưng quá trình bắt tay TLS nói: “đây là một script Python”. Sự không khớp này là tín hiệu rõ ràng cho hệ thống chống bot.

Các hệ thống chống bot xác định trình phân tích qua JA3/JA4 như thế nào

Để chuyển đổi các tham số ClientHello thành một định danh ngắn gọn, thuật toán JA3 (và phiên bản mới hơn của nó JA4) được sử dụng. Nó lấy phiên bản TLS, danh sách các bộ mã hóa, mở rộng và đường cong, ghép chúng thành một chuỗi và băm qua MD5. Kết quả là một băm ngắn dạng 769,47-53-5-10...,0-23-65281...,29-23-24,0, xác định rõ ràng “dấu vân tay” của khách hàng.

Các nhà cung cấp chống bot (Cloudflare, Akamai, PerimeterX, DataDome — và các tương tự mà Wildberries và Ozon sử dụng) giữ cơ sở dữ liệu các băm JA3/JA4 đã biết của các thư viện HTTP phổ biến: requests, aiohttp, Scrapy, Node fetch, Java HttpClient, Go net/http. Nếu băm khớp với chữ ký đã biết của “script”, chứ không phải chữ ký của Chrome/Firefox/Safari — yêu cầu sẽ được đánh dấu là nghi ngờ ngay cả trước khi phân tích hành vi.

Tiếp theo, hệ thống xem xét sự khớp của dấu vân tay TLS với User-Agent được khai báo. Nếu trong tiêu đề ghi “Chrome 124 trên Windows”, nhưng dấu vân tay TLS tương ứng với OpenSSL 1.1.1 từ thư viện tiêu chuẩn của Python — điều này được gọi là TLS/HTTP mismatch, một trong những tín hiệu đáng tin cậy nhất để phát hiện tự động hóa. Chính vì vậy các trình phân tích bị phát hiện ngay cả khi có IP cư trú hoàn hảo và tiêu đề đúng.

Cách kiểm tra dấu vân tay TLS của bạn: công cụ

Trước khi sửa chữa vấn đề, bạn cần thấy những gì máy chủ thấy. Có một số dịch vụ công khai cho thấy băm JA3/JA4 của bạn và toàn bộ tập hợp các tham số ClientHello:

  • tls.peet.ws — hiển thị JA3, JA4, danh sách các bộ mã hóa và mở rộng ở định dạng JSON, thuận tiện cho việc kiểm tra tự động bằng script.
  • ja3er.com — cơ sở dữ liệu các băm JA3 đã biết liên kết với các thư viện và trình duyệt cụ thể.
  • browserleaks.com/tls — so sánh trực quan dấu vân tay của bạn với các dấu vân tay trình duyệt điển hình.
  • Wireshark cục bộ — nếu bạn muốn thấy gói ClientHello thô khi gửi yêu cầu từ script của bạn.

Bài kiểm tra thực tế rất đơn giản: mở tls.peet.ws trong Chrome thông thường và ghi lại băm JA4. Sau đó, gửi yêu cầu GET đến cùng một địa chỉ từ trình phân tích của bạn (qua requests, curl_cffi hoặc bất kỳ thư viện nào khác) qua cùng một proxy và so sánh các băm. Nếu chúng khác nhau — máy chủ thấy sự khác biệt giữa “trình duyệt” và “script” trong mỗi yêu cầu, bất kể IP có sạch đến đâu.

Kiểm tra trên Python: requests, httpx, curl_cffi

Chúng ta sẽ phân tích thực tế tại sao các thư viện tiêu chuẩn của Python phát hiện trình phân tích. Một yêu cầu thông thường qua requests: 

import requests

resp = requests.get("https://tls.peet.ws/api/all", proxies={
    "https": "http://user:pass@proxy_host:port"
})
print(resp.json()["tls"]["ja4"])
# Kết quả sẽ khác với JA4 của Chrome thực,
# vì requests sử dụng mô-đun ssl tiêu chuẩn của Python

Vấn đề là requests và httpx sử dụng OpenSSL hệ thống qua mô-đun ssl, và thứ tự cũng như tập hợp các mở rộng TLS của nó được cố định và không khớp với Chrome/Firefox. Giải pháp là thư viện curl_cffi, sử dụng curl đã được vá với các hồ sơ TLS thực tế của trình duyệt: 

from curl_cffi import requests as cffi_requests

resp = cffi_requests.get(
    "https://tls.peet.ws/api/all",
    impersonate="chrome124",
    proxies={"https": "http://user:pass@proxy_host:port"}
)
print(resp.json()["tls"]["ja4"])
# Băm sẽ giống hệt với Chrome 124 thực trên máy tính để bàn

Tham số impersonate khiến curl_cffi tái tạo không chỉ ClientHello mà còn cả thứ tự các tiêu đề HTTP/2 (frame order), cũng là một phần của dấu vân tay. Cách tiếp cận tương tự được sử dụng bởi các thư viện tls-client cho Go và undetected-chromedriver cho những ai phân tích qua trình duyệt thực, không phải qua HTTP-client.

Nếu việc phân tích được thực hiện qua trình duyệt headless (Playwright, Puppeteer, Selenium), dấu vân tay TLS được hình thành bởi động cơ Chromium/Firefox và mặc định khớp với trình duyệt thực. Nhưng ở đây xuất hiện một vấn đề khác — chữ ký tự động hóa ở cấp độ JS (webdriver-flags, canvas fingerprint), vì vậy cho các kịch bản headless cần thêm các bản vá như playwright-stealth.

TLS + HTTP/2 + tiêu đề: tại sao sự kết hợp lại quan trọng

Dấu vân tay TLS chỉ là một lớp phát hiện. Các hệ thống chống bot kiểm tra nhiều cấp độ cùng một lúc:

  • TLS ClientHello (JA3/JA4) — tập hợp các bộ mã hóa và mở rộng.
  • Dấu vân tay HTTP/2 — thứ tự các tiêu đề giả (:method, :path, :authority), cài đặt SETTINGS-frame, kích thước cửa sổ.
  • Tiêu đề HTTP — thứ tự và tập hợp các tiêu đề thông thường (Accept-Language, Sec-Ch-Ua, Sec-Fetch-*).
  • User-Agent — phải khớp với phiên bản của hồ sơ TLS: nếu UA nói “Chrome 124”, nhưng TLS khớp với Chrome 110, điều này cũng đáng nghi ngờ.

Một lỗi thường gặp là cập nhật User-Agent lên phiên bản mới nhất của Chrome mà quên cập nhật hồ sơ TLS trong curl_cffi hoặc thư viện khác. Sự không khớp giữa các phiên bản này được hệ thống chống bot nhìn thấy rõ ràng như việc hoàn toàn không có sự ngụy trang. Hãy kiểm tra rằng phiên bản impersonate và phiên bản trong User-Agent khớp nhau, và cập nhật cả hai tham số đồng bộ khi có phiên bản mới của trình duyệt.

Một điểm nữa — thứ tự của các tiêu đề. Trình duyệt gửi các tiêu đề theo một thứ tự nhất định, trong khi nhiều thư viện HTTP sắp xếp chúng theo thứ tự bảng chữ cái hoặc theo thứ tự thêm vào mã. Ngay cả khi tập hợp các tiêu đề giống như trình duyệt, thứ tự không đúng — là một tín hiệu bổ sung cho các hệ thống chống bot tiên tiến như DataDome.

Vai trò của proxy: tại sao IP sạch không cứu được

IP cư trú giải quyết một nhiệm vụ cụ thể — giảm độ nghi ngờ về địa lý, ASN và danh tiếng của địa chỉ. IP từ trung tâm dữ liệu thường nằm trong danh sách đen, vì từ đó có lưu lượng tự động hóa lớn, trong khi IP cư trú thuộc về các nhà cung cấp thực và người dùng thông thường. Đối với việc phân tích Wildberries, Ozon hoặc Avito, điều này là rất quan trọng: nếu không có IP sạch, yêu cầu sẽ bị chặn chỉ dựa trên tiêu chí này, ngay cả khi không kiểm tra TLS.

Nhưng IP và dấu vân tay TLS là hai lớp bảo vệ độc lập, và chúng giải quyết các vấn đề khác nhau. IP cho máy chủ biết “từ đâu” yêu cầu đến, trong khi dấu vân tay TLS cho biết “bằng gì” nó đã được gửi. Do đó, sự kết hợp giữa IP sạch và hồ sơ TLS đúng là tập hợp tối thiểu cho việc phân tích ổn định. Đối với các nhiệm vụ có tần suất yêu cầu cao và chống bot mạnh mẽ, tốt hơn hết là sử dụng proxy cư trú, chúng có tỷ lệ bị chặn thấp hơn về danh tiếng IP, nhưng nhất thiết phải kết hợp chúng với thư viện có khả năng tái tạo chính xác hồ sơ TLS của trình duyệt thực.

Đối với việc theo dõi giá trên các thị trường, nơi tốc độ và khối lượng yêu cầu là quan trọng, thường sử dụng proxy từ trung tâm dữ liệu kết hợp với việc ngụy trang TLS qua curl_cffi — điều này rẻ hơn so với cư trú và đủ hiệu quả nếu hệ thống chống bot của trang web không quá mạnh mẽ. Còn đối với các nhiệm vụ mà trang web kiểm tra tích cực các mạng di động (ví dụ, phân tích các phiên bản di động của ứng dụng qua API), sử dụng proxy di động — chúng cung cấp thêm một cấp độ tin cậy nhờ vào danh tiếng của các mạng viễn thông.

Danh sách kiểm tra cấu hình trình phân tích không bị phát hiện

Tập hợp việc kiểm tra thành một quy trình duy nhất trước khi khởi động trình phân tích trong sản xuất:

  1. Đo băm JA4 của script của bạn qua tls.peet.ws và so sánh với trình duyệt thực của cùng phiên bản.
  2. Sử dụng thư viện hỗ trợ ngụy trang TLS: curl_cffi (Python), tls-client (Go), CycleTLS (Node.js).
  3. Đồng bộ hóa phiên bản hồ sơ TLS (impersonate) với phiên bản trong User-Agent.
  4. Kiểm tra thứ tự các tiêu đề HTTP — nó phải khớp với trình duyệt thực, không phải theo thứ tự bảng chữ cái.
  5. Kết nối IP cư trú hoặc di động sạch theo địa lý của nhiệm vụ của bạn.
  6. Thiết lập quay vòng IP riêng biệt với hồ sơ TLS — không gắn chặt một cái với cái khác.
  7. Thường xuyên cập nhật hồ sơ TLS khi có phiên bản mới của Chrome — các chữ ký cũ vào cơ sở dữ liệu của các hệ thống chống bot nhanh hơn bạn nghĩ.
  8. Đối với các kịch bản có kiểm tra JS (Cloudflare Challenge), sử dụng trình duyệt headless với các bản vá stealth thay vì HTTP-client sạch.

So sánh các thư viện và công cụ

Công cụ Dấu vân tay TLS của trình duyệt Tốc độ Khi nào sử dụng
requests / httpx Không, phát ra script Cao Các trang web không có phát hiện TLS, API nội bộ
curl_cffi Có, bản sao chính xác Cao Thị trường, chống bot Cloudflare/Akamai
tls-client (Go) Có Rất cao Tải cao, phân tích hàng loạt
Playwright / Puppeteer Có, động cơ thực Thấp JS-render, Cloudflare Challenge, SPA phức tạp
Scrapy (tiêu chuẩn) Không Cao Các trang web không có bảo vệ chống bot nghiêm ngặt

Kết luận

Dấu vân tay TLS là một lớp bảo vệ mà nhiều trình phân tích hoàn toàn bỏ qua, tiêu tốn tài nguyên vào việc tìm kiếm IP và User-Agent hoàn hảo, nhưng quên rằng chính cấu trúc của quá trình bắt tay TLS phát hiện tự động hóa trước khi máy chủ nhìn vào các tiêu đề. Giải pháp là sử dụng các thư viện hỗ trợ ngụy trang TLS (curl_cffi, tls-client), đồng bộ hóa phiên bản hồ sơ với User-Agent và kiểm tra băm JA4 cuối cùng trước khi khởi động ở quy mô lớn.

IP vẫn là một yếu tố quan trọng — mà không có địa chỉ sạch, ngay cả dấu vân tay TLS hoàn hảo cũng không giúp bạn vượt qua việc bị chặn do danh tiếng của mạng. Đối với việc phân tích các thị trường và theo dõi giá, hợp lý là kết hợp cấu hình TLS đúng với proxy cư trú — sự kết hợp này đóng kín cả hai lớp phát hiện và giảm đáng kể tỷ lệ bị chặn trong các phiên phân tích dài.