Web scraping bị giới hạn? Cách xử lý fingerprinting, chặn IP, CAPTCHA và đăng nhập nhiều tài khoản

Khi một công việc scraping gặp 403, 429, CAPTCHA hoặc lỗi đăng nhập lặp đi lặp lại, phản ứng đúng không phải là xoay vòng IP, che giấu fingerprint hay cố "giả làm người thật". Những tín hiệu này thường có nghĩa là tần suất yêu cầu, phạm vi truy cập, cách xác thực hoặc hành vi tự động đã vượt qua một giới hạn mà trang web sẵn sàng chấp nhận. Tiếp tục ép buộc thường khiến hạn chế leo thang và có thể vi phạm điều khoản dịch vụ, hợp đồng, bản quyền hoặc quy định bảo vệ dữ liệu.

Con đường ổn định hơn là trước hết xác nhận ủy quyền và các giao diện khả dụng, sau đó giảm lưu lượng, áp dụng cache và backoff khi cần, và chỉ để tự động hóa trình duyệt dành cho những trang thực sự cần render JavaScript hoặc đăng nhập của người. Hãy coi CAPTCHA là tín hiệu dừng lại, không phải rào cản kỹ thuật cần phá.

Bắt đầu từ triệu chứng để thu hẹp nguyên nhân

Triệu chứng	Nguyên nhân phổ biến	Phản ứng hợp chuẩn
429 Too Many Requests	Yêu cầu quá nhanh, quá song song hoặc lặp lại	Giảm tốc độ, tôn trọng Retry-After, dùng backoff theo cấp số nhân
403 Forbidden	Đường dẫn chưa được cấp phép, chặn theo chính sách, thiếu phiên	Kiểm tra quyền, điều khoản, robots.txt và cách xác thực
CAPTCHA xuất hiện	Trang yêu cầu xác minh người hoặc chặn tự động hóa	Tạm dừng tác vụ, xử lý thủ công hoặc yêu cầu API
Đăng nhập liên tục thất bại	Cookie hết hạn, phiên bị ghi đè, xác thực thất bại	Dùng OAuth chính thức hoặc tài khoản dịch vụ, sắp xếp việc bàn giao phiên
Trang có nội dung nhưng script không đọc được	Render JavaScript, API tải bất đồng bộ	Dùng API chính thức; nếu được phép, render trong trình duyệt rồi đọc DOM
Selector đột nhiên không hoạt động	Thiết kế lại DOM, A/B test, đổi ngôn ngữ	Dùng locator ngữ nghĩa, kiểm thử cấu trúc và cảnh báo, tránh thứ bậc mã cứng
Trùng lặp hoặc thiếu dữ liệu	Phân trang, con trỏ, múi giờ, sai cửa sổ cập nhật	Tạo khóa duy nhất, watermark tăng dần và cơ chế chạy lại

Chỉ thay đổi một biến mỗi lần và giữ lại log. Nếu cùng lúc đổi IP, User-Agent, tài khoản và parser, bạn có thể thành công tình cờ nhưng không biết thay đổi nào thực sự hiệu quả.

Bước 1: xác nhận bạn có quyền thu thập dữ liệu này

Trước khi bắt đầu, trả lời bốn câu hỏi:

1. Dữ liệu là công khai, hay chỉ có sau khi đăng nhập, thanh toán hoặc cho một số vai trò nhất định?
2. Trang web có cung cấp API, xuất dữ liệu, feed, webhook hay giao diện dữ liệu cho đối tác không?
3. Điều khoản dịch vụ, robots.txt, hợp đồng và luật pháp địa phương có cho phép mục đích sử dụng dự kiến không?
4. Dữ liệu có chứa thông tin cá nhân, nội dung được bảo hộ bản quyền hoặc các trường nhạy cảm khác không?

robots.txt là cơ chế chuẩn mà trang web dùng để nói với các client tự động đường dẫn nào được phép và đường nào bị cấm. RFC 9309 định nghĩa cú pháp và quy tắc so khớp của Robots Exclusion Protocol, đồng thời nêu rõ robots.txt không phải là cấp phép truy cập. Nói cách khác, được robots.txt cho phép không đồng nghĩa với việc bạn có đầy đủ quyền sao chép, xử lý hoặc thương mại hóa dữ liệu; các đường dẫn bị cấm không nên vòng qua lối khác.

Các dự án doanh nghiệp cần lưu lại nguồn dữ liệu, cơ sở truy cập, mục đích, các trường, thời hạn lưu giữ và cơ chế xóa. Khi dữ liệu tổng hợp đã giải quyết được vấn đề, tránh thu thập thông tin giúp nhận diện cá nhân.

Bước 2: ưu tiên các điểm vào dữ liệu ổn định

Thứ tự ưu tiên thường gặp là:

1. API chính thức, webhook hoặc xuất dữ liệu;
2. feed công khai, sitemap hoặc tệp theo lô;
3. trang HTTP thông thường đã được cấp phép;
4. tự động hóa trình duyệt chỉ khi thật sự cần render JavaScript;
5. các trang yêu cầu tài khoản người và tương tác, xử lý cuối cùng.

API thường kèm theo định nghĩa trường, phân trang, giới hạn tốc độ và mã lỗi, nên rẻ hơn để bảo trì so với phân tích UI. Trang web là bề mặt cho mắt người; nó có thể thay đổi bất kỳ lúc nào và không nên được coi là cơ sở dữ liệu ổn định.

Nếu trang không có giao diện phù hợp, hãy liên hệ chủ sở hữu dữ liệu trước và giải thích mục đích, tần suất, trường và quy mô thương mại. Một giấy phép dữ liệu rõ ràng thường rẻ hơn một cuộc chiến dài với các hạn chế.

Bước 3: xử lý 429 và chặn IP bằng cách giảm tải, không phải che giấu nguồn

Đặt trần tốc độ và mức song song

Bắt đầu với một worker và khoảng nghỉ dài, quan sát thời gian phản hồi và tỉ lệ lỗi. Khi máy chủ trả về Retry-After, hãy chờ đúng bằng thời gian đó. Nếu không, dùng backoff theo cấp số nhân kèm jitter ngẫu nhiên để nhiều tác vụ không thử lại cùng lúc.

Một chính sách đơn giản:

chờ = min(trần, cơ_sở × 2^thử_lại) + jitter

Khi đạt số lần thử tối đa, hãy dừng lại và phát cảnh báo. Đừng lặp vô hạn.

Cache và cập nhật tăng dần

Cache cùng một URL và, nếu được hỗ trợ, gửi yêu cầu có điều kiện với ETag hoặc Last-Modified. Ghi lại thời điểm cập nhật gần nhất hoặc một con trỏ để chỉ lấy nội dung mới hoặc thay đổi. Tách tác vụ toàn diện khỏi tác vụ tăng dần hằng ngày giúp giảm đáng kể lưu lượng yêu cầu.

Nhận diện client một cách trung thực

Một crawler hợp chuẩn dùng User-Agent ổn định và thật, nêu rõ mục đích và cung cấp trang liên hệ hoặc email. Giả làm trình duyệt thông thường và thay đổi danh tính liên tục khiến trang khó phân biệt traffic tốt với traffic xấu, từ đó tăng khả năng bị chặn.

Nếu một IP cụ thể bị hạn chế, hãy tạm dừng tác vụ và xem xét nguyên nhân. Tiếp tục xoay vòng proxy để duy trì truy cập có thể bị coi là vòng quanh kiểm soát truy cập, không phải là cách xử lý đúng.

Bước 4: đối phó với fingerprinting và phân tích hành vi

Fingerprint trình duyệt kết hợp các tín hiệu như User-Agent, hệ điều hành, ngôn ngữ, múi giờ, độ phân giải, Canvas và WebGL. Trang có thể còn phân tích nhịp yêu cầu, đường điều hướng và hành vi phiên. OWASP liệt kê Fingerprinting, Scraping, CAPTCHA Defeat, Credential Stuffing… là các hạng mục mối đe dọa tự động hóa riêng biệt, giải thích vì sao trang thường kết hợp nhiều tín hiệu để đánh giá rủi ro tự động hóa.

Với công việc đã được ủy quyền, mục tiêu không phải tạo ra nhiều danh tính "giống người" mà là giữ cho môi trường ổn định và giải thích được:

• dùng môi trường cố định và xác thực bình thường cho cùng một tài khoản nghiệp vụ;
• giữ tham số trình duyệt nhất quán với khu vực và thiết bị thực tế;
• không ngẫu nhiên thay đổi fingerprint để tránh chặn;
• ghi log tần suất thu thập, ID tác vụ và người chịu trách nhiệm;
• thỏa thuận với trang về số tài khoản, mức song song và phạm vi dữ liệu được phép.

Nếu trang vẫn phân loại sai tác vụ đã ủy quyền, hãy cung cấp cho họ mốc thời gian, User-Agent, IP egress và mẫu yêu cầu, rồi yêu cầu đưa vào whitelist hoặc cấp giao diện riêng.

Bước 5: dừng tự động hóa khi CAPTCHA xuất hiện

CAPTCHA tồn tại để xác nhận người hoặc chặn tự động hóa đáng ngờ. Không dùng OCR, dịch vụ giải CAPTCHA, plugin bẻ CAPTCHA hay bất kỳ phương pháp tự động vượt nào khác.

Quy trình đúng:

1. lập tức tạm dừng tài khoản hiện tại và hàng đợi tác vụ;
2. lưu lại tần suất yêu cầu, đường dẫn và log lỗi ngay trước khi CAPTCHA kích hoạt;
3. người có thẩm quyền hoàn tất xác minh cần thiết trên trang chính thức;
4. kiểm tra xem yêu cầu có quá nhanh, phiên đã hết hạn hay đã truy cập đường dẫn không được phép không;
5. với tự động hóa dài hạn, yêu cầu trang cấp API, tài khoản dịch vụ hoặc whitelist.

Dù người có giải CAPTCHA một lần, điều đó không cho phép gửi yêu cầu tự động không giới hạn về sau. Hãy sửa nguyên nhân trước.

Bước 6: quản lý đăng nhập và nhiều tài khoản bằng quyền chính thức

Dữ liệu sau đăng nhập nhạy cảm hơn trang công khai. Ưu tiên OAuth, tài khoản dịch vụ, token API hoặc quyền do đội ngũ chính thức của nền tảng cấp. Không để script lưu mật khẩu chính của ai đó.

Khi thật sự cần phiên trình duyệt:

• một tài khoản nghiệp vụ hợp lệ tương ứng với một môi trường ổn định;
• lưu cookie đã mã hóa, có thời hạn và có cách thu hồi;
• bật MFA, tự động hóa không được vượt qua bước xác minh hai yếu tố;
• cấm nhiều người cùng lúc đặt lại mật khẩu hoặc sao chép cookie;
• ghi lại ai đã khởi chạy tác vụ nào và khi nào;
• thu hồi quyền truy cập ngay khi nhân sự rời đi, dự án kết thúc hoặc vai trò thay đổi.

Nhiều tài khoản chỉ áp dụng cho những tài khoản bạn thực sự sở hữu hoặc được phép sử dụng. Khi trang giới hạn một chủ thể chỉ được một tài khoản, việc cô lập môi trường không được dùng để phá vỡ giới hạn đó.

Bước 7: làm cho việc phân tích trang động chịu được thiết kế lại tốt hơn

Dùng thuộc tính ngữ nghĩa và ổn định

Ưu tiên tiêu đề, đầu mục, thuộc tính trợ năng và các định danh kiểm thử công khai của trang. Tránh thứ bậc giòn như div:nth-child(7). Sau khi trang được làm mới, hãy đọc lại DOM, đừng giả định nút cũ vẫn còn.

Tách trích xuất khỏi logic nghiệp vụ

Tầng thu thập chỉ chuyển trang thành các trường có cấu trúc. Tầng kiểm tra xác nhận kiểu, phạm vi, khóa duy nhất và trường bắt buộc. Khi tách như vậy, thiết kế lại chỉ chạm vào parser mà không phá vỡ phân tích phía sau.

Tạo mẫu và cảnh báo

Lưu một số nhỏ ảnh chụp HTML hoặc cấu trúc phù hợp làm mẫu kiểm thử. Không lưu trang tài khoản đầy đủ hoặc dữ liệu nhạy cảm. Giám sát tỉ lệ trường thiếu, số bản ghi, tỉ lệ trùng và tiêu đề trang; khi lệch hãy dừng ghi vào dữ liệu production.

Vai trò hợp lý của PurpleMark trong scraping được ủy quyền

Khi một đội cần đồng thời duy trì nhiều tài khoản được ủy quyền, các môi trường khách hàng khác nhau hoặc nhiều khu vực, có thể dùng PurpleMark web app để tạo một môi trường trình duyệt độc lập cho mỗi tài khoản nghiệp vụ và lưu cùng nhau cookie tương ứng, trang mặc định mở sau khi đăng nhập và cấu hình mạng thông thường. Mở lại môi trường đó sau này, trình duyệt sẽ quay về phiên và trang làm việc gần nhất, nên nhiều người không phải dùng chung một bộ cookie và không phải đăng nhập lại từ đầu.

Khi cần tách tài khoản theo khách hàng, nền tảng hoặc khu vực, các nhóm môi trường cho phép xếp tài khoản nghiệp vụ vào các thư mục khác nhau, còn quyền thành viên, chia sẻ và chuyển giao quyết định ai có thể mở môi trường nào. Nhật ký thao tác ghi lại thời điểm và người đã mở hoặc thay đổi từng môi trường. Khi có thắc mắc về scraping đã ủy quyền, có thể truy ngược nhanh đến một tài khoản cụ thể và người chịu trách nhiệm đã xác định.

PurpleMark giúp đội duy trì lâu dài "tài khoản, môi trường, phiên và trách nhiệm" trong một không gian làm việc, nhưng nó không nhằm để vượt qua chặn IP, CAPTCHA, giới hạn số tài khoản hay phòng thủ chống tự động hóa của một trang. Hãy xin phép trước, rồi mới nói đến tự động hóa.

Một kiến trúc scraping dễ bảo trì

Phân chia hữu ích thành năm tầng:

1. Lập lịch: kiểm soát tần suất, song song, ưu tiên tác vụ và tạm dừng;
2. Truy cập: API, HTTP hoặc phiên trình duyệt được ủy quyền;
3. Phân tích: chuyển phản hồi thành các trường có cấu trúc;
4. Chất lượng: chống trùng lặp, kiểm tra kiểu, cảnh báo trường thiếu, nhật ký phiên bản;
5. Quản trị: quyền, nguồn, mục đích, thời hạn lưu giữ, xóa.

Mỗi bản ghi giữ URL nguồn, thời điểm thu thập và phiên bản parser. Khi có lỗi, có thể truy vết và chạy lại đúng bản ghi bị ảnh hưởng thay vì crawl lại toàn bộ trang.

Câu hỏi thường gặp

Xoay vòng proxy có giải quyết chặn IP không?

Có thể tạm đổi địa chỉ egress, nhưng không giải quyết vấn đề tần suất, quyền hay hành vi. Xoay vòng proxy để tiếp tục truy cập có thể bị coi là vòng quanh kiểm soát. Hãy tạm dừng tác vụ, giảm yêu cầu và liên hệ trang trước.

Có thể tự động giải CAPTCHA không?

Không nên. CAPTCHA là tín hiệu dừng lại hoặc cần người xác nhận. Với tự động hóa liên tục, hãy yêu cầu API, tài khoản dịch vụ hoặc whitelist.

robots.txt cho phép thì luôn được scraping chứ?

Chưa chắc. robots.txt không phải cấp phép truy cập; còn phải cân nhắc điều khoản, bản quyền, quyền riêng tư, hợp đồng và mục đích sử dụng dữ liệu.

Trình duyệt chống phát hiện có làm scraping "không bị phát hiện" không?

Không thể bảo đảm, và cũng không nên là mục tiêu. Nó phù hợp hơn với việc tách phiên tài khoản hợp pháp và quyền của đội, giảm nhầm lẫn cookie và sai sót vận hành.

Kết

Giới hạn web scraping không chỉ là "bài toán kỹ thuật chống bot". 403, 429, fingerprinting, CAPTCHA và giới hạn nhiều tài khoản đều quy về quyền, tải và quản lý danh tính.

Cách tiếp cận ổn định luôn quay về: API là ưu tiên, ủy quyền rõ ràng, yêu cầu có tiết chế, cache tăng dần, phân tích có kiểm thử và tài khoản có thể kiểm toán. Khi gặp CAPTCHA hoặc bị chặn, hãy dừng lại và sửa quy trình thay vì tiếp tục che giấu nguồn của tự động hóa.