Obchod TLS/JA4-fingerprinta: curl_cffi hướng dẫn 2026

Bạn đã mua proxy cư trú, cài đặt User-Agent Chrome mới, nhưng trang web vẫn trả về 403 ngay trong yêu cầu đầu tiên. Nghe quen không? Vấn đề không phải ở IP và cũng không phải ở tiêu đề. Bạn đã bị phát hiện ngay cả trước khi máy chủ đọc bất kỳ tiêu đề HTTP nào — qua bắt tay TLS. Vào năm 2026, đây là vectơ phát hiện số 1, và requests thông thường tự động thất bại. Chúng ta sẽ phân tích cách thức hoạt động và cách sửa chữa chỉ với vài dòng mã qua curl_cffi.

Điều gì đang xảy ra: bạn bị phát hiện qua bắt tay TLS

Khi khách hàng thiết lập kết nối HTTPS, trước tiên họ gửi gói ClientHello — ngay cả trước khi có bất kỳ HTTP nào. Trong đó liệt kê: phiên bản TLS, danh sách các bộ mã hóa được hỗ trợ (cipher suites), các mở rộng TLS (SNI, ALPN, supported_groups), các đường cong elip và định dạng điểm. Thứ tự và thành phần của các trường này ở các khách hàng khác nhau khác nhau — và từ đó khách hàng có thể được nhận diện trước khi họ nói bất kỳ từ nào.

Từ những trường này, người ta tính toán dấu vân tay. JA3 (tiêu chuẩn năm 2017) lấy chuỗi dạng TLSVersion,Ciphers,Extensions,EllipticCurves,ECPointFormats và băm nó bằng MD5, thu được chữ ký 32 ký tự. Vấn đề của JA3 là từ tháng 1 năm 2023, Chrome đã ngẫu nhiên hóa thứ tự các mở rộng — 16 mở rộng tạo ra 16! (hơn 20 triệu triệu) biến thể, và cùng một trình duyệt sẽ đưa ra các JA3 khác nhau.

Do đó, ngành công nghiệp đã chuyển sang JA4 (FoxIO, triển khai đại trà 2024–2025). JA4 sắp xếp mã mở rộng theo giá trị hex trước khi băm — việc ngẫu nhiên hóa của Chrome không còn làm hỏng nó nữa. Băm — SHA-256 rút gọn, định dạng dễ đọc và ba phần (a_b_c), bao gồm ALPN và hỗ trợ QUIC/HTTP3. Ví dụ: Chrome 124 cho ra t13d1516h2 (15 bộ mã hóa, 16 mở rộng, ALPN h2), trong khi Python requests trần trụi cho ra t13d1715h2. Đối với anti-bot, chữ ký thứ hai — là dấu hiệu rõ ràng "đây là script".

Tại sao vào năm 2026 không thể thiếu điều này

Phát hiện JA4 được tích hợp trong tất cả các nhà cung cấp lớn: Cloudflare so sánh dấu vân tay với các danh sách cho phép, Akamai thêm một băm riêng cho các khung HTTP/2 SETTINGS, DataDome so sánh với cơ sở dữ liệu các bot đã biết. Logic rất đơn giản và tàn nhẫn: nếu bạn gửi User-Agent: Chrome 131, nhưng dấu vân tay TLS kêu lên "urllib3/OpenSSL" — đó là sự không đồng bộ, và bạn sẽ bị chặn ngay lập tức. Không có proxy nào cứu vãn: IP cư trú hoàn hảo với dấu vân tay Python requests vẫn sẽ thua.

Chính vì lý do đó, sự kết hợp "proxy + giả mạo dấu vân tay" đã trở thành tiêu chuẩn cơ bản trong việc thu thập dữ liệu vào năm 2026, chứ không phải là tùy chọn cho những người tiên tiến.

Giải pháp: curl_cffi trong 5 phút

curl_cffi là một lớp bọc Python cho curl-impersonate (curl đã được sửa đổi, được biên dịch với BoringSSL từ Chrome hoặc NSS từ Firefox thay vì OpenSSL). Nó tái tạo bắt tay của trình duyệt thực sự và đồng thời có API gần như giống hệt với requests thông thường.

Bước 1. Cài đặt. Các tệp nhị phân curl-impersonate cho Windows/macOS/Linux được tải xuống tự động:

pip install curl-cffi

Bước 2. Yêu cầu cơ bản. Bạn thay đổi việc nhập khẩu và thêm một tham số:

from curl_cffi import requests

resp = requests.get("https://target.com/", impersonate="chrome")
print(resp.status_code)
print(resp.http_version)  # HTTP/2 — như trình duyệt thực sự

Một dòng impersonate="chrome" giả mạo ngay lập tức bốn lớp: dấu vân tay TLS (JA3/JA4), phiên bản HTTP (HTTP/2 thay vì HTTP/1.1), thứ tự tiêu đề và các cuộc đàm phán ALPN.

Bước 3. Luôn sử dụng alias chung, không phải phiên bản cố định. Viết impersonate="chrome" (hoặc "safari", "safari_ios") — alias sẽ tự động được giải quyết thành hồ sơ mới nhất. impersonate="chrome124" sẽ trở nên lỗi thời: Chrome được cập nhật mỗi ~4 tuần, và hồ sơ cũ sẽ trở thành một dị thường. Các mục tiêu đáng tin cậy — Chrome, Edge và Safari/iOS (các hồ sơ từ chrome99 đến chrome131, safari15–18).

Bước 4. Proxy và phiên làm việc. Để thu thập dữ liệu thực sự, hãy giữ trạng thái trong phiên và gắn proxy. IP cư trú hoặc di động là bắt buộc ở đây — trung tâm dữ liệu bị phát hiện riêng biệt theo ASN so với TLS:

from curl_cffi import requests

session = requests.Session(impersonate="chrome")

headers = {
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
    "Referer": "https://www.google.com/",
}
proxies = {
    "http": "http://user:pass@proxy-host:port",
    "https": "http://user:pass@proxy-host:port",
}

resp = session.get("https://target.com", headers=headers, proxies=proxies)

Bước 5. Asynchronous cho khối lượng. Khác với requests, curl_cffi có async và HTTP/2 ngay từ đầu:

import asyncio
from curl_cffi.requests import AsyncSession

async def fetch(session, url):
    r = await session.get(url, impersonate="chrome")
    return r.status_code

async def main(urls):
    async with AsyncSession() as session:
        return await asyncio.gather(*[fetch(session, u) for u in urls])

asyncio.run(main(["https://target.com"] * 20))

Kiểm tra dấu vân tay của bạn — đừng đoán mò

Trước khi gửi lưu lượng chiến đấu, hãy đảm bảo rằng việc giả mạo thực sự hoạt động. Gửi yêu cầu đến các công cụ xác minh công khai và so sánh JA4 với dấu vân tay trình duyệt chuẩn:

tls.peet.ws — trả về JA3, JA4, dấu vân tay Akamai và các khung HTTP/2 trong JSON. Yêu cầu nó qua curl_cffi và qua Chrome thực sự, so sánh các băm.
ja4db.com — cơ sở dữ liệu các JA4 đã biết, giúp hiểu bạn giống ai.
browserleaks.com/tls và công cụ JA3/JA4 từ Scrapfly — phân tích chi tiết các trường.

Trong giai đoạn thử nghiệm, tiện lợi khi đặt mitmproxy giữa scraper và mục tiêu và theo dõi băm JA4 thực tế của từng yêu cầu.

Chẩn đoán: vẫn bị 403/429

Nếu dấu vân tay chính xác, nhưng vẫn bị chặn — hãy đi theo danh sách kiểm tra từ phổ biến đến hiếm:

IP trung tâm dữ liệu. Nguyên nhân số 1. Chuyển sang proxy cư trú hoặc di động — tại sao chỉ một dấu vân tay là không đủ, đã được phân tích chi tiết trong tài liệu về phát hiện proxy cư trú qua IP Intelligence.
Hồ sơ lỗi thời. pip install -U curl-cffi và alias chung "chrome".
Tốc độ quá cao. Thêm các khoảng dừng ngẫu nhiên từ 1–3 giây giữa các yêu cầu.
Tiêu đề trần trụi. Nhất định gửi Accept-Language, Accept-Encoding, Referer — việc thiếu chúng cũng là một dị thường.
Không đồng bộ giữa phiên và IP. Quy tắc: một phiên — một IP trong suốt thời gian sống của nó.
Trạng thái 200 ≠ thành công. Kiểm tra nội dung phản hồi: dưới mã 200 có thể là trang có CAPTCHA.

Nơi curl_cffi gặp khó khăn

curl_cffi đóng lại lớp mạng — và chỉ vậy thôi. Nó không thực thi JavaScript. Vì vậy, đối với các thử thách JS, nó bất lực: Cloudflare Turnstile, trang "Đang kiểm tra trình duyệt của bạn..." (IUAM), cookie cf_clearance mà script đặt sau khi kiểm tra — tất cả đều yêu cầu môi trường trình duyệt thực sự. Tại sao vào năm 2026, các solver CAPTCHA gần như không còn hoạt động chống lại các hệ thống phòng ngừa như vậy, chúng tôi đã phân tích trong một bài viết riêng về vượt qua CAPTCHA.

Phải làm gì khi bạn gặp phải bức tường JS:

Hỗn hợp. Playwright hoặc Nodriver chạy thử thách và nhận cf_clearance, sau đó cookie được chuyển đến curl_cffi nhanh chóng cho phần lớn yêu cầu — như vậy bạn chỉ phải trả tiền cho trình duyệt nặng một lần.
Dịch vụ Solver (CapSolver, 2Captcha) để tự động phát hành token.
API thu thập dữ liệu được quản lý, nếu bạn không muốn duy trì cơ sở hạ tầng.

Và hãy nhớ về tính an toàn trong luồng: mỗi luồng — một phiên riêng. Ghi lại phiên bản curl-cffi trong requirements.txt và xem xét các hồ sơ mỗi 6–12 tuần, khi các trình duyệt được cập nhật.

Các lựa chọn thay thế cho curl_cffi

tls-client — lớp bọc cho thư viện Go dựa trên uTLS, với các hồ sơ (chrome_124, safari_ios_17) và cờ random_tls_extension_order=True. Tinh chỉnh dấu vân tay linh hoạt.
primp — khách hàng trên Rust, cho phép đặt impersonate_os độc lập và cung cấp băng thông cao hơn; nhược điểm — API không hoàn toàn trùng khớp với requests và thư viện còn trẻ.

Proxy nào cần và tại sao

Giả mạo dấu vân tay và proxy giải quyết hai nửa của một nhiệm vụ: curl_cffi giải quyết câu hỏi "kết nối trông như thế nào", proxy — "nó đến từ đâu". Anti-bot kiểm tra cả hai tín hiệu một cách độc lập, vì vậy JA4 hoàn hảo với ASN trung tâm dữ liệu đen sẽ vô dụng. Đối với các mục tiêu bảo mật (thị trường, mạng xã hội, tổng hợp du lịch), hãy chọn proxy cư trú hoặc proxy di động: chúng có nguồn gốc rõ ràng từ nhà điều hành, và proxy di động còn ẩn mình sau hiệu ứng CGNAT "đám đông". Trung tâm dữ liệu hãy để lại cho các mục tiêu không nhạy cảm và khối lượng lớn.

Kết luận

Vào năm 2026, việc thu thập dữ liệu là một trò chơi về danh tính, chứ không chỉ là IP. requests trần trụi được coi là một script ở mức bắt tay TLS và thua ngay cả trước khi có tiêu đề đầu tiên. Việc thay thế nhập khẩu bằng curl_cffi với impersonate="chrome" loại bỏ thất bại này chỉ trong năm phút, nhưng chỉ hoạt động khi kết hợp với IP cư trú hoặc di động sạch và hiểu rõ ranh giới: lớp mạng — có, thử thách JavaScript — không. Hãy xây dựng ngăn xếp một cách trung thực: dấu vân tay chính xác, proxy chính xác, hỗn hợp với trình duyệt ở những nơi có bức tường JS — và 403 trong yêu cầu đầu tiên sẽ trở thành quá khứ.