Một script scraping chạy tốt ở máy cục bộ vẫn có thể bị chặn sau một thời gian hoạt động trực tuyến. Nguyên nhân thường là nhiều tín hiệu chồng lên nhau như tần suất request, đặc điểm request và môi trường render. Khi hệ thống chống bot liên tục thay đổi, cách ổn định hơn là tuân thủ robots, kiểm soát tần suất và chỉ thu thập dữ liệu công khai.
Một script thu thập dữ liệu có thể chạy bình thường ở máy cục bộ nhưng dừng hoạt động sau một thời gian khi đưa lên môi trường trực tuyến. Phản hồi 403, bị chuyển sang trang xác minh hoặc chỉ nhận về HTML trống thường cho thấy cùng một vấn đề: hệ thống bảo vệ của website đánh giá lượt truy cập này không giống người dùng thông thường.
Vì sao script dần mất hiệu lực
Chống bot không phải là một công nghệ duy nhất mà là nhiều lớp đánh giá kết hợp. Tín hiệu dễ bị phát hiện đầu tiên thường là tần suất: cùng một IP gửi dày đặc request tới cùng một đường dẫn trong thời gian ngắn, với khoảng cách đều đặn một cách máy móc. Đây là một trong những mẫu dễ nhận diện nhất. Khi bị kích hoạt, website có thể trước hết giới hạn tốc độ và trong trường hợp nghiêm trọng sẽ chặn IP trực tiếp.
Lớp tiếp theo là danh tính. Request có thể dùng user agent mặc định của thư viện script, thiếu các header mà trình duyệt bình thường thường gửi, hoặc tự nhận là Chrome nhưng không có môi trường thực thi JavaScript và kết quả render tương ứng. Các điểm này đều có thể bị tính vào đánh giá. Website đặt sau CDN còn có thể thêm JavaScript challenge: trang trước tiên trả về đoạn mã phải được thực thi rồi mới lấy được nội dung. Thư viện HTTP đơn thuần không tạo ra được kết quả này nên sẽ dừng ở cổng.
Tín hiệu hành vi cũng rất rõ. Người dùng thật tải hình ảnh và CSS, cuộn trang và có khoảng dừng. Script thường chỉ lấy HTML rồi thoát. Website gộp các tín hiệu này thành điểm số và hiển thị CAPTCHA khi điểm thấp hơn ngưỡng.
Cơ chế này vẫn tiếp tục phát triển. Mỗi lần bên cung cấp bảo vệ thay đổi logic phát hiện, các script dựa vào tham số cố định và nhịp cố định lại phải sửa. Càng thêm nhiều tham số, script càng cồng kềnh và càng khó duy trì hành vi giống thực tế. Giả định rằng một script có thể dùng cho mọi website vốn đã không thực tế ngay từ đầu.
Vì sao vượt qua cơ chế bảo vệ không phải lựa chọn phù hợp
Trên mạng có nhiều hướng dẫn về cách vượt qua bảo vệ, nhưng đây không chỉ là lựa chọn kỹ thuật. Việc đó có thể vi phạm điều khoản của website. Điều khoản dịch vụ thường cấm né tránh biện pháp bảo mật và giới hạn truy cập. Làm được về mặt kỹ thuật không có nghĩa là hợp lý về hợp đồng hoặc pháp luật.
Hệ quả cũng rất cụ thể. Bị khóa tài khoản và IP là kết quả trực tiếp nhất. Tại nhiều khu vực pháp lý, lấy dữ liệu bằng cách vượt qua biện pháp kỹ thuật cũng có thể vi phạm pháp luật. Dữ liệu lấy bằng phương thức bất thường còn khó truy xuất nguồn gốc và kiểm chứng tính toàn vẹn, khiến rủi ro tăng khi dùng cho các quyết định về sau. Biến vấn đề kỹ thuật thành vấn đề tuân thủ không phải là sự đánh đổi hợp lý.
Những nguyên tắc cơ bản để thu thập dữ liệu đúng quy định
Trước hết hãy xem quy tắc robots và điều khoản sử dụng. robots.txt cho biết website cho phép crawler truy cập những đường dẫn nào. Đây không chỉ là gợi ý mà là ý chí được website thể hiện rõ. Điều khoản sử dụng thường còn có các hạn chế chi tiết hơn về việc dùng dữ liệu.
Nếu có API chính thức, hãy ưu tiên sử dụng. Cấu trúc dữ liệu rõ ràng, có tài liệu và quy định quota, đồng thời thay đổi front-end cũng không làm toàn bộ tích hợp hỏng theo. Nếu quota không đủ, có thể giảm kế hoạch thu thập hoặc yêu cầu hạn mức cao hơn qua kênh kinh doanh. Cả hai cách đều ổn định hơn việc vượt qua giới hạn.
Cần kiểm soát tần suất. Website cho phép crawl không có nghĩa là cho phép dùng hết băng thông. Hãy thêm khoảng nghỉ, giới hạn số request trong một đơn vị thời gian và tránh giờ cao điểm. Thực hiện được những việc này sẽ tránh phần lớn xung đột.
Chỉ thu thập dữ liệu công khai và không đụng tới thông tin cá nhân. Không lấy nội dung chỉ xem được sau khi đăng nhập hoặc dữ liệu mà website ghi rõ là cấm crawl. Thông tin cá nhân được pháp luật bảo vệ nghiêm ngặt; việc thu thập cần có cơ sở pháp lý rõ ràng và, khi áp dụng, sự đồng ý của người dùng. Đây không phải vấn đề kỹ thuật.
Nếu thực sự cần nội dung sau khi render thì sao
Một số trang chỉ hiển thị nội dung sau khi JavaScript chạy, nên thư viện request đơn thuần không đủ. Trong trường hợp đó có thể dùng browser automation để mở trang và đọc DOM đã render, nhưng vẫn phải giữ các giới hạn: truy cập theo nhịp bình thường, không chạy hàng chục instance cùng lúc vào một website và không dùng automation khi website ghi rõ cấm truy cập tự động.
Có một ranh giới dễ bị nhầm lẫn. Công cụ đa môi trường có mục đích hợp lệ là tách biệt nhiều tài khoản hợp pháp, chẳng hạn một nhóm cùng lúc đăng nhập vào bảng quản trị của nhiều khách hàng để xem dữ liệu. Nó không nhằm giả mạo thành số lượng lớn người dùng khác nhau để scrape cùng một website. Trường hợp đầu là quản lý tài khoản; trường hợp sau là né tránh giới hạn truy cập.
Câu hỏi thường gặp
Đổi IP chỉ thay đổi một tín hiệu trong quá trình đánh giá. Nếu header, tần suất và đặc điểm fingerprint vẫn giữ nguyên, script sẽ sớm gặp lại cùng một bức tường. Việc đổi IP quá thường xuyên tự nó cũng có thể trở thành tín hiệu bất thường.
Khi quota API nhỏ, hãy giảm lượng thu thập theo quota hoặc xin hạn mức cao hơn qua kênh kinh doanh. Cách này thường không chậm hơn quá nhiều so với vượt giới hạn, trong khi nguồn dữ liệu vẫn sạch và có thể truy vết.
Hiển thị công khai và được tự do sử dụng là hai chuyện khác nhau. Vẫn cần xem điều khoản website, tình trạng bản quyền của dữ liệu và mục đích sử dụng về sau. Nếu có thông tin cá nhân thì càng phải thận trọng.
Kết luận
Khi scraping bị chặn, website đã xác định rằng lượt truy cập không giống hành vi của người dùng thông thường. Có hai hướng khả thi: đưa hành vi truy cập về phạm vi bình thường hoặc chuyển sang giao diện chính thức. Vượt qua cơ chế bảo vệ có vẻ như đường tắt, nhưng thực chất chỉ chuyển rủi ro từ tầng kỹ thuật sang tầng tuân thủ.
