Cách phát hiện bẫy nhận diện bot và tránh chúng

Thu thập dữ liệu tự động đã trở thành một phần không thể thiếu của nhiều dự án: giám sát giá cả, thu thập dữ liệu và phân tích mạng xã hội. Tuy nhiên, chủ sở hữu trang web cố gắng bảo vệ dữ liệu của họ và giảm tải cho máy chủ, vì vậy họ không khuyến khích việc thu thập dữ liệu. Mặc dù họ không thể đơn giản cấm việc thu thập dữ liệu từ trang web hoặc dịch vụ của họ, họ có thể đặt các bẫy đặc biệt giúp xác định liệu một khách truy cập có phải là con người hay một kịch bản không. Trong bài viết này, chúng tôi sẽ xem xét các kỹ thuật phổ biến nhất mà các trang web sử dụng để phát hiện bot, cũng như các phương pháp để xác định và vượt qua các bẫy này.

Bẫy honeypot vô hình: liên kết và các trường ẩn

Một trong những thủ thuật phổ biến nhất được sử dụng để bắt bot là các trường honeypot gọi là — các yếu tố trên trang được chuẩn bị đặc biệt và ẩn đi. Một người thực sẽ không bao giờ thấy hoặc nhấn vào chúng, nhưng một bot đơn giản có thể làm thế.

Một ví dụ đơn giản là một liên kết vô hình (được tạo bằng cách sử dụng các kiểu CSS như display: none hoặc định vị ngoài màn hình) dẫn đến một URL bẫy đặc biệt. Một người dùng bình thường sẽ không nhấn vào liên kết như vậy vì họ thậm chí không biết nó tồn tại, nhưng một trình quét dữ liệu mà truy cập qua từng liên kết sẽ làm vậy và tự lộ diện. Ngay khi kịch bản tải trang đó, máy chủ có thể thêm địa chỉ IP của nó vào danh sách đen và chặn quyền truy cập tiếp theo.

Ý tưởng tương tự áp dụng cho các biểu mẫu web. Một trường ẩn được thêm vào một biểu mẫu (ví dụ như biểu mẫu đăng ký hoặc liên hệ). Một người sẽ không thấy nó, nhưng một bot có thể tìm và điền vào. Các trường honeypot như vậy báo hiệu hoạt động của bot. Nếu một biểu mẫu được gửi có chứa văn bản trong một trường ẩn, đó là một dấu hiệu đỏ. Yêu cầu bị từ chối hoặc phiên làm việc bị gắn cờ là lưu lượng của bot. Trong cả hai trường hợp, công việc tiếp theo trở nên không thể.

Cách tránh: đầu tiên, khi thu thập thông tin trang, hãy phân tích thuộc tính của yếu tố trước khi nhấp hoặc điều hướng. Kiểm tra kiểu liên kết: nếu một liên kết hoặc nút được đánh dấu là vô hình (display:none, opacity: 0, kích thước 1×1 pixel, v.v.), hãy bỏ qua nó. Tương tự, trước khi gửi biểu mẫu, hãy đảm bảo bạn chưa điền vào bất kỳ trường ẩn nào (chúng có thể được xác định bằng các tên hoặc thuộc tính bất thường như aria-hidden, tabindex="-1", kiểu ẩn, v.v.). Người mới vào nghề có thể coi những chi tiết như thế là không quan trọng, nhưng đây là một trong những cách dễ nhất để bị phát hiện. Một cú nhấp chuột không cần thiết vào liên kết bẫy là đủ để lộ bot của bạn.

Tự nhiên, các chủ sở hữu trang web và dịch vụ biết về các biện pháp đối phó, và các bot hiện đại đã có thể phát hiện các yếu tố honeypot bằng các đặc tính CSS đáng ngờ, vì vậy phương pháp này thường được kết hợp với các kỹ thuật bảo vệ khác. Tuy nhiên, lọc các liên kết và trường vô hình là một yêu cầu bắt buộc cho bất kỳ trình phân tích chuyên nghiệp nào.

CAPTCHAs và thử thách JavaScript

Một cách rõ ràng hơn để ngăn chặn truy cập tự động là CAPTCHA, những cửa sổ bật lên gây phiền toái với lựa chọn hình ảnh, hộp kiểm “Tôi không phải là robot” và các biến thể tương tự. Đây là một cách trực tiếp và hiệu quả để phân biệt con người với các kịch bản hoặc bot. Không giống như các honeypot ẩn, CAPTCHAs yêu cầu hoàn thành một nhiệm vụ mà một bot có thể không giải quyết được. Trong thực tế, các CAPTCHAs đơn giản có thể bị vượt qua khá dễ dàng vì nhiều giải pháp mã nguồn mở miễn phí tồn tại, trong khi các giải pháp phức tạp hơn yêu cầu dịch vụ giải quyết của bên thứ ba.

Nếu một bot gặp CAPTCHA, có ít lựa chọn: hoặc giải quyết nó tự động thông qua dịch vụ của bên thứ ba hoặc thay đổi luồng và chuyển sang một hồ sơ khác. Việc giải quyết CAPTCHA có phí làm chậm quét dữ liệu và tăng chi phí. Một chiến lược khác là tránh kích hoạt CAPTCHA hoàn toàn — ví dụ: bằng cách giảm cường độ yêu cầu để tránh kích hoạt các biện pháp bảo vệ hoặc bằng cách sử dụng bộ nhớ đệm của công cụ tìm kiếm (chẳng hạn như Google Cache) để lấy dữ liệu.

Một loại khác biệt khác là thử thách JavaScript. Nhiều trang web (đặc biệt là những trang sau các giải pháp bảo vệ CDN như Cloudflare) có thể trả lại một trang xác minh thay vì nội dung khi lưu lượng truy cập có vẻ đáng ngờ. Trang này chạy mã JS phía máy khách tính toán một token, kiểm tra môi trường trình duyệt, thiết lập cookie và chỉ sau đó chuyển hướng khách truy cập đến nội dung thực sự. Mục tiêu là xác nhận yêu cầu đến từ một trình duyệt thực sự với hỗ trợ JS chứ không phải một khách hàng HTTP đơn giản. Một bot không thể thực thi JavaScript sẽ thất bại trong thử nghiệm này và không thể truy cập được.

Cách tránh: nếu bạn biết một trang web mục tiêu hiển thị CAPTCHAs, hãy quyết định trước cách bạn sẽ vượt qua chúng, cả về mặt kỹ thuật và tài chính. Nếu ngăn chặn CAPTCHA là không thể (một số trang web hiển thị nó mặc định), bạn sẽ cần tích hợp một giải pháp giải quyết của bên thứ ba. Đối với các thử thách JS, cách vượt qua rõ ràng nhất là sử dụng một trình duyệt headless thực thi kịch bản yêu cầu. Các công cụ tự động hóa phổ biến (Puppeteer, Playwright, v.v.) cho phép chạy một trình duyệt trong nền, nhưng đừng quên về việc giả mạo, bởi vì dấu vết tự động hóa phải luôn được ẩn.

Phớt lờ xác minh JS không phải là một lựa chọn: nếu nó tồn tại, bạn phải vượt qua nó hoặc bạn sẽ không lấy được dữ liệu. Hãy chắc chắn rằng trình cào của bạn tải các script liên quan, thực thi chúng, và lưu trữ cookie hoặc các token cho các yêu cầu tiếp theo.

Phân tích hành vi: tốc độ, thứ tự, tương tác

Ngay cả khi một bot vượt qua các trở ngại trực tiếp như CAPTCHAs và các phương pháp chống bot nhìn thấy khác, các mô hình hành vi không phải là con người vẫn có thể gây tử vong. Một người dùng điển hình dành vài giây trên một trang sản phẩm, cuộn, nhấp vào hình ảnh và sau đó điều hướng thêm. Một kịch bản, tuy nhiên, có thể tải các trang ngay lập tức và theo một thứ tự hoàn toàn lặp lại. Các trang web hiện đại theo dõi các bất thường như vậy. Các tốc độ điều hướng cực cao, khoảng thời gian giữa các yêu cầu đều đặn đáng ngờ, và các mẫu tương tự rõ ràng cho thấy tự động hóa.

Một chỉ báo khác là thứ tự điều hướng bất thường — ví dụ: quét URLs theo thứ tự bảng chữ cái hoặc tuân theo một sitemap một cách nghiêm ngặt, điều mà người dùng thực sự hiếm khi làm. Một chỉ số đơn giản là sự vắng mặt của các tương tác giống con người. Nếu nhật ký cho thấy một phiên xem 100 trang mà không có một cuộn hoặc di chuyển chuột nào, phiên đó có khả năng là lưu lượng của bot.

Các bẫy dựa trên thời gian cũng tồn tại. Các biểu mẫu có thể áp đặt thời gian hoàn thành tối thiểu. Hầu hết mọi người mất ít nhất 5–10 giây để nhập thông tin đăng nhập, trong khi một bot có thể gửi chúng trong vài milliseconds. Nếu một biểu mẫu được gửi gần như ngay lập tức, có xác suất cao là tự động hóa, và trang web có thể từ chối yêu cầu. Một cách tiếp cận tương tự áp dụng cho điều hướng: di chuyển quá nhanh đến bước tiếp theo — đặc biệt là một bước phức tạp như thanh toán — gây ra nghi ngờ trong các hệ thống chống bot.

Cách tránh: nguyên tắc chính là mô phỏng hành vi người dùng thực. Đưa vào tính ngẫu nhiên và các mẫu tự nhiên vào quy trình làm việc của trình cào của bạn.

Đầu tiên, đừng đặt mục tiêu đạt tốc độ quét nhanh nhất. Nếu tốc độ không quan trọng, làm việc chậm hơn một chút nhưng cẩn thận hơn sẽ an toàn hơn. Chèn các khoảng dừng giữa các yêu cầu — không cố định mà được ngẫu hóa trong một phạm vi. Thêm các khoảng dừng trên mỗi trang để mô phỏng thời gian đọc.

Thứ hai, tránh các thứ tự điều hướng nghiêm ngặt. Nếu có thể, đưa vào tính ngẫu nhiên trong thứ tự quét (ví dụ: thay đổi thứ tự của các phần hoặc lựa chọn ngẫu nhiên các liên kết trên một trang thay vì lặp lại theo thứ tự).

Thứ ba, thêm các dấu hiệu tương tác tự nhiên trong các kịch bản headless. Các đường ống tiên tiến có thể bao gồm cuộn, di chuyển con trỏ, mở các yếu tố giao diện và các khoảng dừng nhỏ giữa các bước. Các hành động này không ảnh hưởng trực tiếp đến việc thu thập dữ liệu nhưng làm cho quy trình làm việc tự nhiên hơn, đặc biệt là trên các trang dài và luồng nhiều bước (đăng nhập → lựa chọn → thanh toán), nơi mà thời gian hoàn hảo nhất quán trông không tự nhiên.

Cũng cần xem xét góc nhìn của trang web: nhiều hệ thống kết hợp phân tích hành vi với theo dõi và phân tích web. Các trình theo dõi trên một trang có thể ghi lại các sự kiện tương tác và thời gian của phiên. Nếu nhật ký cho thấy một phiên rỗng mà không có các tín hiệu điển hình, chỉ điều đó thôi cũng trông đáng ngờ. Do đó, điều quan trọng là đánh giá không chỉ các hành động của trình cào của bạn mà còn cả những dữ liệu phiên nào thực sự được tạo ra và cách nó được diễn giải từ phía theo dõi.

Tỉ lệ yêu cầu và giới hạn khối lượng

Một tiêu chí rõ ràng khác được sử dụng để phân biệt một máy với một con người là tần suất yêu cầu. Ngay cả người dùng nhanh nhất cũng không thể gửi hàng chục yêu cầu mỗi giây, nhưng một kịch bản có thể. Đó là lý do tại sao các giới hạn phía máy chủ được thực hiện: ví dụ, không quá N yêu cầu từ một địa chỉ IP duy nhất mỗi phút. Nếu vượt quá giới hạn, một khối tạm thời hoặc vĩnh viễn sẽ được kích hoạt. Ở cấp độ máy chủ web hoặc CDN, điều này được thực hiện bằng cách theo dõi số lượng yêu cầu và lọc ra những cơn bùng nổ vượt quá ngưỡng. Các con số chính xác phụ thuộc vào chính sách của trang web: ở một nơi nào đó, 5 yêu cầu mỗi giây có thể được chấp nhận, trong khi nơi khác thậm chí 1 yêu cầu mỗi giây sẽ bị coi là quá khả năng. Điều này dễ dàng thực hiện: với Nginx, bạn có thể cấu hình giới hạn 1 yêu cầu mỗi giây cho mỗi địa chỉ IP và từ chối bất kỳ điều gì vượt quá đó.

Ngoài tần suất, độ đồng thời cũng được theo dõi. Một người dùng thông thường khó có thể mở đồng thời 20 trang của một trang web trong các tab khác nhau, trong khi một trình cào có thể dễ dàng tạo nhiều luồng song song. Điều này cũng được theo dõi: quá nhiều phiên đồng thời từ một địa chỉ đủ là lý do để nghi ngờ một botnet hoặc trình cào.

Cách tránh: đầu tiên, giới hạn mức độ đồng thời trong kịch bản của bạn. Vâng, rất hấp dẫn để phân chia xử lý một danh mục ra thành 50 luồng và thu thập dữ liệu trong một phút, nhưng trong 99% các trường hợp điều này sẽ ngay lập tức thu hút sự chú ý không mong muốn. Tốt hơn là làm việc với một vài luồng (hoặc thậm chí một) nếu bạn thấy rằng trang web nhạy cảm với tải.

Thứ hai, chú ý đến việc xoay vòng địa chỉ IP của bạn. Hầu hết các trang web được ghi lại IP của mỗi khách truy cập và chặn cả địa chỉ khi hoạt động đáng ngờ được phát hiện. Đó là lý do tại sao sử dụng proxy là một thực tiễn tiêu chuẩn cho việc quét dữ liệu nghiêm túc. Có ý nghĩa khi sử dụng xoay vòng địa chỉ IP: sau một số yêu cầu nhất định hoặc khi chuyển đổi các phần, thay đổi địa chỉ điểm thoát. Tốt nhất là luôn sử dụng proxy dân cư hoặc di động. Quan trọng là cấu hình trình cào để một IP không thực hiện quá nhiều yêu cầu liên tiếp. Ví dụ, gửi không quá 5–10 yêu cầu từ một địa chỉ, sau đó thay đổi. Nếu hồ bơi proxy của bạn bị hạn chế, ít nhất hãy cố gắng thay phiên chúng và duy trì các khoảng dừng.

Ngoài ra, luôn luôn theo dõi các tiêu đề phản hồi và mã trạng thái cho các yêu cầu của bạn. Nếu bạn bắt đầu nhận được HTTP 429 Yêu cầu Quá Nhiều hoặc thấy điều gì đó như "Yêu cầu quá nhiều, thử lại sau" trong nội dung trang, đây là một tín hiệu rõ ràng rằng giới hạn yêu cầu đã được kích hoạt. Tình huống như vậy đòi hỏi hoặc giảm tốc độ quét, tăng số lượng proxy, hoặc sử dụng các kỹ thuật khác. Là một lựa chọn, nếu giới hạn được đặt trên mỗi địa chỉ IP và trang web có thể truy cập qua HTTP và cho phép thay đổi Tác Nhân Người Dùng và Người Giới Thiệu mà không cần kiểm tra thêm, xoay vòng chúng có thể giúp.

Nói chung, quy tắc chính là không nổi bật: càng hòa nhập vào lưu lượng nền của người dùng bình thường, trình cào của bạn sẽ hoạt động không bị chặn lâu hơn.

Tiêu đề và vân tay trình duyệt

Các trang web có thể phát hiện một trình cào ở giai đoạn kết nối bằng cách phân tích các tham số yêu cầu kỹ thuật. Mỗi yêu cầu HTTP mang một tập hợp các tiêu đề (Tác Nhân Người Dùng, Chấp Nhận, Ngôn Ngữ Chấp Nhận, cookie, v.v.), mà cùng nhau tạo thành một hồ sơ trình duyệt. Đối với các trình duyệt thông thường, các hồ sơ này khá có thể dự đoán được: ví dụ, khi truy cập một trang web với Chrome, bạn gửi một tập hợp các tiêu đề đặc trưng bắt đầu với User-Agent: Mozilla/5.0 … Chrome/version …, cùng với danh sách các ngôn ngữ được hỗ trợ (Accept-Language), các cờ tìm nạp (Sec-Fetch-* headers), và v.v. Một bot, tuy nhiên, có thể gửi một tập hợp các tiêu đề không bình thường hoặc không đầy đủ. Nhiều trang web ngay lập tức chặn các yêu cầu với chuỗi Tác Nhân Người Dùng đáng ngờ như Scrapy, curl, Wget, Python, và tương tự, ở mức tường lửa. Và ngay cả khi bạn không bị chặn vì gửi các chuỗi như vậy, thực tế đó sẽ được coi là một phần của điểm rủi ro tổng thể.

Khi thay thế Tác Nhân Người Dùng bằng một chuỗi trình duyệt chung, bạn vẫn có thể thất bại ở chi tiết. Ví dụ, Headless Chrome từng tiết lộ bản thân vì chuỗi Tác Nhân Người Dùng chứa từ HeadlessChrome. Một ví dụ khác: bot không gửi tiêu đề Accept-Language (trình duyệt thực sự luôn gửi các sở thích ngôn ngữ).

Một chỉ báo khác: thứ tự của các tiêu đề hoặc giá trị của chúng không khớp với trình duyệt đã khai báo. Các hệ thống chống bot duy trì các cơ sở dữ liệu lớn về vân tay trình duyệt — các mẫu với các tiêu đề và giá trị khác nhau từ các phiên bản khác nhau của Chrome, Safari và Firefox. Nếu bạn tuyên bố là Chrome 120+ và gửi Tác Nhân Người Dùng tương ứng, nhưng không bao gồm các tiêu đề Gợi ý Người Dùng UA Client Hints tiêu biểu cho Chromium hiện đại (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform), hoặc chúng có định dạng sai, hoặc một yêu cầu điều hướng do người dùng nhấp không bao gồm Sec-Fetch-User: ?1 trong khi các tiêu đề Sec-Fetch-* khác có mặt, những sự không nhất quán nhỏ như vậy có thể tiết lộ tự động hóa (đây chỉ là một ví dụ minh họa).

Hơn nữa, vượt qua các tiêu đề HTTP, trình duyệt có thể tiết lộ bản thân thông qua đối tượng navigator và môi trường JS. Các chế độ headless thường bao gồm một thuộc tính navigator.webdriver, thường là true cho các trình duyệt tự động hóa. Các trang web sau đó có thể chạy một đoạn mã phía máy khách đơn giản: if (navigator.webdriver) { /* Bot được phát hiện */ } — và cách tiếp cận đơn giản này đủ tốt để bắt người mới. Những người khác tìm kiếm các đối tượng cụ thể còn lại bởi Selenium hoặc Playwright. Ví dụ, Playwright chèn các biến dịch vụ nhất định vào window (__playwright__binding__ và các biến khác), và các script trên trang có thể tìm kiếm các dấu hiệu điều khiển từ bên ngoài như vậy.

Các kiểm tra tiên tiến hơn bao gồm các thử nghiệm API Canvas hoặc WebGL, nơi một hình ảnh ẩn được render và một vân tay canvas được thu thập có thể phù hợp với một chữ ký giả lập điển hình.

Nói tóm lại, có nhiều kiểm tra sẵn có cho các trang web, và việc giả danh môi trường có thể bị phát hiện ngay cả qua những sự không nhất quán nhỏ trong triển khai JS.

Cách tránh: giả danh chính mình như một thiết bị/trình duyệt thực sự càng nhiều càng tốt. Luôn thiết lập một Tác Nhân Người Dùng thực tế tương ứng với một trình duyệt phổ biến và giữ nó được cập nhật. Nhưng một tiêu đề không đủ: điều chỉnh các tiêu đề khác nữa. Thêm Ngôn Ngữ Chấp Nhận (dựa trên khu vực IP), Chấp Nhận với các loại nội dung điển hình cho một trình duyệt phổ thông, Kết Nối, Nâng Cấp Yêu Cầu Không An Toàn, tiêu đề Sec-Fetch-*, và v.v. Cách dễ nhất là kiểm tra tiêu đề mà trình duyệt của bạn gửi khi truy cập trang web mục tiêu (qua công cụ phát triển hoặc một proxy) và mô phỏng chúng. Chú ý đến sự nhất quán: nếu bạn tuyên bố là Chrome trên Windows, bạn nên có một Tác Nhân Người Dùng hướng tới Windows và, khi cần thiết, một tiêu đề Sec-CH-UA-Platform: "Windows".

Nếu bạn làm việc với một trình duyệt headless, sử dụng thư viện hoặc thiết lập tự động kích hoạt giả danh tự động hóa (ví dụ, Puppeteer có gói puppeteer-extra-plugin-stealth, vô hiệu hóa navigator.webdriver và các dấu hiệu khác dễ thấy, hoặc các phiên bản vá lỗi của playwright/puppeteer từ rebrowser giấu đi nhiều điểm yếu chuẩn của các thư viện như vậy). Nếu bạn đang tạo một trình cào cấp thấp, tự động sửa đổi navigator thông qua Giao Thức Công Cụ Nhà Phát Triển để thiết lập các thuộc tính khớp với một trình duyệt thực.

Tất nhiên, không cần phải mô phỏng tất cả mọi thứ cho đến tiếng ồn Canvas ngẫu nhiên. Thực hành tốt nhất là bắt đầu với các cơ sở — tiêu đề và JS đơn giản. Không gửi các chuỗi rõ ràng đáng ngờ, thường xuyên cập nhật các mẫu tiêu đề để khớp với các trình duyệt hiện tại, kích hoạt việc mô phỏng các tương tác nhỏ, và nếu có thể, kiểm tra bot của bạn chống lại các công cụ chống phát hiện. Các công cụ như BrowserScan hoặc FingerprintJS có thể cho thấy những tín hiệu nào mà kịch bản của bạn tiết lộ.

Các thủ thuật khác: từ “mê cung vô tận” đến các dịch vụ của bên thứ ba

Bên cạnh những gì đã đề cập, còn nhiều bẫy kỳ lạ hơn đáng được biết đến. Một số tài nguyên cố tình tạo các cấu trúc liên kết “vô tận” — một loại mê cung cho một trình cào.

Một ví dụ kinh điển là các trang lịch vô tận được tạo động hoặc các URL có thông số dẫn vào các vòng lặp. Một bot không có điều kiện dừng thích hợp có thể bị mắc kẹt khi cố gắng vượt qua một dòng vô tận của liên kết. Kết quả, nó lãng phí tài nguyên của bạn và cũng tự lộ diện cho các hệ thống chống bot qua hành vi bất thường. Đối với người dùng thực, các liên kết như vậy thường không thể đến được, nhưng một bot có thể rơi vào cái bẫy như vậy.

Cách tránh: đầu tiên, luôn phân tích dữ liệu đã thu thập để đảm bảo tính hợp lý. Nếu trình cào của bạn đột nhiên theo dõi một chuỗi liên kết đến đâu đó mà nó không được phép đi đến và tải xuống hàng tấn văn bản trông như các cụm từ ngẫu nhiên, bạn có thể đã đi vào một mê cung. Có ích để triển khai logic phát hiện vòng lặp: theo dõi các URL đã truy cập, giới hạn sâu quét, xác minh rằng các liên kết mới thuộc về cùng miền hoặc vùng mà bạn cần.

Thứ hai, luôn xem xét bối cảnh: nếu bạn quét ví dụ, một trang web đánh giá và bot đột nhiên bắt đầu tải các trang với văn bản rõ ràng không liên quan hoặc có ý nghĩa không rõ ràng sinh ra từ AI, đây là lý do để cẩn thận và ngừng phiên đó.

Cũng ghi nhớ rằng các dịch vụ của bên thứ ba cũng giúp các trang web phát hiện bot. Các sản phẩm như Cloudflare Quản lý Bot, Datadome, PerimeterX, và những dịch vụ khác chuyên biệt trong việc phát hiện lưu lượng tự động. Họ sử dụng sự kết hợp của các phương pháp từ phân tích hành vi và vân tay đến cơ sở dữ liệu của các bot đã biết và thậm chí cả học máy để xác định những khách truy cập bất thường.

Nếu bot của bạn gặp một hệ thống chống bot mạnh mẽ, nhiệm vụ trở nên phức tạp hơn, vì phát hiện có thể dựa trên sự kết hợp của các tín hiệu nhỏ. Trong những trường hợp như vậy, tất cả các vấn đề đã thảo luận ở trên đều áp dụng, và bạn cũng cần xem xét các cải tiến quy tắc liên tục từ phía bị quét. Đôi khi, việc thay đổi chiến thuật quét hoặc giới hạn khối lượng yêu cầu ở mức không gây kích hoạt hệ thống bảo vệ trở nên rẻ hơn. Khi sử dụng proxy, bạn có thể thử bắt chước các người dùng thực khác nhau và thay đổi không chỉ địa chỉ IP mà cả vị trí địa lý, tác nhân người dùng và thời gian yêu cầu (giả lập các lượt truy cập vào các giờ khác nhau trong ngày thay vì hoạt động không ngừng nghỉ).

Kết luận

Như bạn thấy, không có một nút ma thuật duy nhất nào có thể xóa vĩnh viễn rủi ro bị chặn. Bạn cần một sự kết hợp của các phương pháp kỹ thuật và thực hiện cẩn thận để quét dữ liệu thành công:

• Phát hiện và bỏ qua các yếu tố honeypot: trước khi nhấp vào một liên kết hoặc điền vào một trường, hãy đảm bảo yếu tố không bị ẩn khỏi tầm nhìn của con người. Không theo dõi các URL đáng ngờ và không điền vào các trường biểu mẫu vô hình.

• Mô phỏng một người dùng thực: sử dụng các tiêu đề và giá trị thực điển hình của các trình duyệt thông thường (Tác Nhân Người Dùng, Ngôn Ngữ Chấp Nhận, v.v.). Bất cứ khi nào có thể, chạy quét thông qua lõi trình duyệt của các trình duyệt chống phát hiện để vượt qua các kiểm tra JS và đảm bảo một môi trường thực tế (tác nhân người dùng, cookie, Bộ nhớ cục bộ, v.v.).

• Giới hạn tốc độ và độ đồng thời: cấu hình các khoảng dừng và khoảng dừng giữa các yêu cầu, sử dụng các khoảng thời gian ngẫu hóa. Đừng vượt quá giới hạn yêu cầu, mở rộng dần dần, và theo dõi phản ứng của trang web (mã HTTP 429, CAPTCHAs, v.v.).

• Xoay vòng địa chỉ IP và số nhận dạng phiên: sử dụng một hồ sơ proxy hoặc VPN, luân phiên IP, đặc biệt là đối với quét quy mô lớn. Đảm bảo rằng một IP duy nhất không được sử dụng quá thường xuyên. Luôn chọn các IP dân cư, vì chúng ít bị nghi ngờ hơn với các hệ thống chống bot.

• Đưa vào tính ngẫu nhiên vào hành vi quét của bạn: mô phỏng các hành động của người dùng, ví dụ như các cuộn nhỏ, di chuyển chuột, thời gian dành để đọc một trang. Tránh các lộ trình hoàn toàn tuần tự và thay đổi các mẫu hành động để không thể hiện một thuật toán cứng nhắc.

Cuộc chiến trong việc quét dữ liệu web vẫn tiếp tục, khi các trang web phát minh các phương pháp phát hiện mới và các nhà phát triển bot tìm kiếm cách vượt qua chúng. Trong trò chơi này, người thắng cuộc là người cẩn thận và sáng tạo hơn. Hãy để bot của bạn chính xác là như vậy: cẩn thận, linh hoạt và không thể đoán như con người.