Tại sao tôi bị chặn khi quét dữ liệu?

Một khối quét thực sự cho bạn biết gì

Một trình quét bị chặn khi một số thành phần từ chối, thách thức, làm chậm hoặc thay thế tài nguyên được yêu cầu trước khi người thu thập nhận được nội dung mục tiêu có thể sử dụng. Kết quả nhìn thấy có thể là 403, 429, trang riêng của nhà cung cấp, CAPTCHA, chuyển hướng đăng nhập, giao diện JavaScript trống, đóng kết nối hoặc HTML trông bình thường mà thực chất là một mẫu lỗi.

Chẩn đoán một khối quét bắt đầu bằng cách xác định thành phần nào đã đưa ra quyết định, bằng chứng nào đi kèm theo nó và liệu sự đại diện có đến từ nguồn mục tiêu, một bên trung gian hay khách hàng cục bộ hay không. Đối với một khối quét, một dòng trạng thái không có tiêu đề, URL cuối, nội dung phản hồi và thời gian ấn dấu những manh mối phân biệt một yêu cầu không hợp lệ với một quy tắc truy cập hoặc một lỗi từ phía trên.

Một bản ghi bằng chứng cho một khối quét nên chứa phương pháp chính xác, URL bình thường hóa, máy chủ đích, trạng thái phản hồi, tiêu đề, một mẫu nội dung đã biên soạn an toàn và khoảng thời gian sự kiện. Các nhật ký thu thập cho một khối quét phải loại trừ thông tin xác thực, cookies và dữ liệu cá nhân. Với một bản ghi khối quét gọn nhẹ như vậy, một kỹ sư có thể so sánh một trao đổi trình duyệt thành công với một trao đổi trình quét thất bại và xác định sự khác biệt có ý nghĩa.

Đối với một công việc bị ảnh hưởng bởi một khối quét, sự thành công có nghĩa là nhiều hơn là không có sự từ chối, thách thức, trang chậm lại, hay phản hồi thay thế không mong đợi. Việc khôi phục từ một khối quét yêu cầu một phản hồi phù hợp với trang công khai được phê duyệt với danh tính và các trường có thể lấy ra như mong đợi, chứa danh tính trang như mong đợi và phơi bày các trường cần thiết của trình phân tích. Trong một cuộc điều tra khối quét, một trang lỗi nhãn hiệu với vận chuyển thành công vẫn được coi là một thu thập thất bại, trong khi một lỗi API có cấu trúc có thể vẫn là bằng chứng chẩn đoán hữu ích.

Bản đồ khối đến lớp phát tín hiệu của nó

Các khối quét có thể phát sinh từ khách hàng, mạng, dịch vụ bảo mật đỉnh, ứng dụng nguồn, lớp xác thực hoặc đường dẫn hiển thị nội dung.

Sử dụng bảng khối quét này làm bản đồ định tuyến vì các lỗi nhìn tương tự có thể phát sinh tại các lớp thuộc quyền sở hữu của các nhóm khác nhau. Trong một cuộc điều tra khối quét, việc chỉnh sửa trình phân tích không thể sửa chữa một đường dẫn mạng, thay đổi proxy không thể sửa chữa JSON không hợp lệ, và thay đổi tiêu đề không thể sửa chữa một ngoại lệ nguồn. Việc xác lập quyền sở hữu cho một khối quét vì vậy nên được thực hiện trước bất kỳ danh sách các giải pháp đề xuất nào.

Một so sánh được kiểm soát cho một khối quét thay đổi một biến tại một thời điểm trong khi giữ cho URL mục tiêu và kiểm tra chấp nhận không đổi. So sánh các lộ trình địa phương, triển khai, trực tiếp, quản lý và trình duyệt chỉ khi mỗi lộ trình được ủy quyền, và giữ lại phản hồi hoàn chỉnh từ mọi nhánh kiểm tra khối quét. Những so sánh đó cho thấy liệu chủ sở hữu thu thập cùng với liên hệ bảo mật được ủy quyền của trang mục tiêu nên kiểm tra yêu cầu, chính sách truy cập, bên trung gian, ứng dụng hoặc môi trường triển khai.

Tại sao các trang lại chặn các yêu cầu tự động

Nhiều nguyên nhân của một khối cào có thể đồng thời tồn tại: một yêu cầu không hợp lệ có thể đầu tiên nhận được sự từ chối, thách thức, trang điều tiết, hoặc phản hồi thay thế bất ngờ, sau đó tiết lộ ranh giới tường lửa sau khi sửa chữa. Gắn mọi quan sát về khối cào với phiên bản yêu cầu chính xác đã tạo ra nó. Nếu không có liên kết khối cào đó, bằng chứng từ các nỗ lực riêng biệt có thể được kết hợp vào một chẩn đoán chưa từng tồn tại trong một lần trao đổi.

Xây dựng một Bản Tái Tạo Khối Tối Thiểu

Giảm trình cào xuống một URL được phê duyệt và làm cho phản hồi có thể quan sát được trước khi điều chỉnh hiệu suất hoặc logic phân tích.

1. Tái tạo sự cố với một yêu cầu từ môi trường mà công việc thực sự chạy.
2. Ghi lại trạng thái, URL cuối, tiêu đề, tiêu đề nội dung và bất kỳ mã định danh tương quan nào.
3. Phân loại xem phản hồi HTTP có đến hay không và liệu nội dung của nó có thuộc về trang dự kiến hay không.
4. So sánh yêu cầu với một lần điều hướng trình duyệt đã được xác thực thành công ở cấp độ phương thức, URL, địa phương, cookie và chuỗi điều hướng.
5. Kiểm tra xem tần suất, đồng thời hoặc hạn ngạch tài khoản có khác với lộ trình thành công hay không.
6. Xem lại các điều khoản, sở thích của robot, và bất kỳ thỏa thuận truy cập chính thức nào trước khi thay đổi lộ trình thu thập.
7. Áp dụng một thay đổi hẹp và giữ cùng một kiểm tra chấp nhận nội dung.

Một thiết lập tối thiểu hữu ích hơn một trình thu thập đầy đủ trong khi cách ly một khối cào: sử dụng một URL công cộng được phê duyệt, một yêu cầu, và một khẳng định danh tính trang. Tạm dừng phân tích, lưu trữ, hàng đợi và lập lịch phía hạ nguồn cho đến khi lộ trình thu thập phía sau một khối cào được hiểu rõ. Sau khi yêu cầu khối tối thiểu đã hoạt động, khôi phục các thành phần sản xuất một cách riêng lẻ trong khi giữ cùng một khẳng định danh tính.

Phân loại bằng chứng khối cào một cách rõ ràng: một sự cố vận chuyển không có phản hồi HTTP có thể sử dụng, một sự cố giao thức có định dạng phản hồi bất ngờ, một sự cố truy cập là sự từ chối có chủ ý, và một sự cố nội dung thiếu trang yêu cầu mặc dù đã vượt qua các kiểm tra vận chuyển. Từ vựng này giúp sự cố khối cào không bị gán nhãn tự động sai thành một vấn đề chống bot.

Sử dụng Bằng Chứng Chính, Không Truyền Thuyết

Các tiêu chuẩn giao thức định nghĩa các lớp trạng thái, trong khi tài liệu WAF giải thích lý do tại sao một yêu cầu tự động có thể bị từ chối hoặc thách thức.

Đối với một khối cào, các thông số ngữ nghĩa HTTP cung cấp định nghĩa giao thức gắn liền với chẩn đoán. Tiêu chuẩn đó giữ phân tích khối cào liên kết với phản hồi thực tế thay vì những giả định cụ thể về sản phẩm, sau đó mà các chi tiết của nhà cung cấp có thể xác định thành phần phát ra.

Đối với nguồn gốc có thể của một khối cào, tài liệu AWS WAF Bot Control thêm bối cảnh triển khai sau khi phản hồi đã được gán. Một dịch vụ biên, ủy quyền ngược, ứng dụng gốc hoặc thư viện khách có thể sản xuất văn bản tương tự về một khối cào trong khi yêu cầu hành động khắc phục khác nhau.

Đối với truy cập tự động liên quan đến một khối cào, Giao thức Loại Trừ Robot giúp định nghĩa ranh giới vận hành bên cạnh các điều khoản của trang, mô hình ủy quyền và sở thích thu thập được công bố. Giải quyết một khối cào không tạo ra quyền; việc thu thập phải vẫn giới hạn ở thông tin công cộng được phê duyệt ngay cả khi một dịch vụ thu thập được quản lý được sử dụng.

Sửa điều kiện chặn cụ thể

Các cách sửa chữa nên tuân theo thể loại đã chẩn đoán và chính sách truy cập của chủ sở hữu mục tiêu thay vì một danh sách kiểm tra khối tổng quát.

• Vấn đề vận chuyển Sửa chữa DNS, lòng tin chứng chỉ, khả năng tiếp cận proxy hoặc chính sách mạng xuất khẩu trước khi thay đổi hành vi HTTP.
• Yêu cầu không hợp lệ Sửa URL, phương thức, mã hóa, loại phương tiện, nội dung, hoặc tham số ứng dụng cần thiết.
• Từ chối quyền Sử dụng tài khoản ủy quyền đúng hoặc yêu cầu chủ sở hữu tài nguyên truy cập; không coi bề mặt riêng tư là công cộng.
• Dương tính giả WAF Cung cấp cho chủ sở hữu trang mã sự kiện và ngữ cảnh yêu cầu để có thể đánh giá một điều chỉnh quy tắc hẹp.
• Ranh giới tỷ lệ Giảm tần suất yêu cầu và song song xuống khối lượng công việc đã công bố hoặc đã thỏa thuận.
• Khoảng trống hiển thị Sử dụng một lộ trình hiển thị trình duyệt được hỗ trợ và xác thực trang được hiển thị trước khi phân tích.

Chọn thay đổi nhỏ nhất mà giải quyết nguyên nhân đã xác nhận của một khối cào. Trong trường hợp khối cào này, việc bắt chước tiêu đề rộng, xoay vòng địa chỉ không kiểm soát, hoặc tắt các kiểm soát an ninh có thể che giấu khiếm khuyết gốc và tạo ra một vấn đề về tuân thủ hoặc độ tin cậy. Sửa chữa khối cào được chọn nên có một chủ sở hữu đã đặt tên, phạm vi hẹp, hiệu ứng có thể quan sát được, và con đường đảo ngược.

Đối với việc thu thập trang công cộng được ủy quyền bị ảnh hưởng bởi một khối cào, Scrapeless Web Unlocker có thể tập trung việc tạo trình duyệt, xử lý xác thực lưu lượng, và định tuyến proxy phía sau một yêu cầu được quản lý. Một quy trình làm việc Web Unlocker cho một khối cào vẫn cần một URL mục tiêu hợp lệ, yêu cầu đầu ra rõ ràng, giới hạn khối lượng công việc có trách nhiệm, và một khẳng định nội dung. Kiểm tra kết quả khối cào được quản lý so với URL cuối danh định, danh tính trang mong muốn, nội dung không rỗng và các trường yêu cầu.

Một trạng thái đã thay đổi đơn thuần không chứng minh rằng một khối scraping đã được giải quyết vì kết quả có thể là một khối mã hóa khác, một chuyển hướng đăng nhập, hoặc một trang cổng chung mà không có dữ liệu mục tiêu. Sau mỗi lần sửa khối scraping, cần xác thực cả nội dung và URL cuối cùng để phân biệt lỗi ẩn với hợp đồng dữ liệu đã được khôi phục.

Xác thực trang mong muốn, không phải trạng thái

Một khối được giải quyết chỉ khi trang và các trường mong đợi xuất hiện nhất quán trong môi trường khối lượng công việc được phê duyệt.

• Xác minh người phát hành. Xác nhận rằng trang từ chối trước đó hoặc dấu hiệu thách thức không có mặt.
• Xác minh danh tính trang. Kiểm tra chủ thể chuẩn, tiêu đề trang, và một dấu hiệu tài nguyên ổn định.
• Xác minh độ hoàn chỉnh của các trường. Từ chối các khung rỗng, chuyển hướng đăng nhập, và các mẫu không đầy đủ.
• Xác minh phạm vi chính sách. Giữ bài kiểm tra giới hạn ở các URL công khai đã được phê duyệt và tần suất được chấp nhận.
• Xác minh sự tương đồng môi trường. Chạy cùng một khẳng định từ trình thu thập đã triển khai, không chỉ từ một trạm làm việc.

Xác thực việc sửa chữa một khối scraping ở thể tích thấp bên trong môi trường đã thất bại trước đó, so sánh với một trang công khai tốt đã biết, mục tiêu bị ảnh hưởng, và một kiểm soát có chủ ý không hợp lệ. Bài kiểm tra khối scraping thành công chỉ khi trang tốt thỏa mãn khẳng định nội dung của nó, mục tiêu bị ảnh hưởng thể hiện hành vi mong muốn, và kiểm soát không hợp lệ vẫn là một lỗi. Nếu tất cả ba đầu vào khối scraping xuất hiện thành công, công cụ kiểm tra có thể đang chấp nhận các trang lỗi.

Đối với một khối scraping, giữ các kết nối, HTTP, danh tính trang, trích xuất, và chỉ số chấp nhận bản ghi tách biệt vì chúng mô tả các ranh giới quy trình khác nhau. Tỷ lệ thành công của một khối scraping đơn lẻ che giấu liệu vấn đề còn lại là mạng, truy cập, hiển thị, phân tích, hay xác thực; các bộ đếm riêng biệt giúp việc xác định lại nhanh chóng hơn.

Thiết kế một đường ống scraping nhận biết khối

Các đường ống nhận biết khối phát hiện sự thay đổi vào thời điểm tiếp nhận và bảo tồn đủ bối cảnh cho một chuyển giao chủ sở hữu chính xác.

• Phân loại các phản hồi. Sử dụng các trạng thái khác nhau cho lỗi mạng, từ chối truy cập, giới hạn tần suất, thách thức, khoảng trống hiển thị, và lỗi phân tích.
• Khẳng định nội dung. Đối xử với dấu hiệu trang mong muốn như một phần không thể thiếu của thành công.
• Giới hạn đồng thời. Cho mỗi máy chủ một ngân sách yêu cầu đã được xem xét và xếp hàng công việc thừa.
• Bảo tồn phiên một cách có chủ ý. Giữ trạng thái được ủy quyền chỉ khi quy trình làm việc yêu cầu nó và bảo vệ thông tin đăng nhập đã lưu.
• Xem xét các quy tắc truy cập. Kiểm tra lại các điều khoản, sở thích robot, và thỏa thuận khi mục tiêu hoặc mục đích thu thập thay đổi.

Các kiểm soát vận hành cho một khối scraping nên bảo tồn bối cảnh có thể tái tạo mà không giữ lại dữ liệu nhạy cảm. Lưu một dấu vân tay yêu cầu không bí mật, lớp phát ra đã biết, loại phản hồi, kết quả khẳng định nội dung, và danh tính bản xây dựng đã triển khai cho mỗi sự kiện khối scraping. Giữ các mẫu nội dung khối scraping đã chỉnh sửa chỉ nơi chính sách cho phép và chỉ trong thời gian khắc phục sự cố.

Phòng ngừa mạnh nhất cho một khối scraping là một hợp đồng xác định trang công khai đã được phê duyệt với danh tính mong đợi và các trường có thể trích xuất trước khi công việc được thực hiện. Khi hợp đồng khối scraping đó bao gồm máy chủ mong đợi, mẫu URL cuối cùng, dấu hiệu cần thiết, ngôn ngữ cho phép, và các trường cần thiết, một trang từ chối, thách thức, giới hạn, hoặc phản hồi thay thế bất ngờ trở thành một kết quả được phân loại thay vì một dừng quy trình không được giải thích.

Bài học thực tiễn

Con đường nhanh nhất vượt qua một khối scraping bắt đầu với phân loại chính xác. Khi người phát hành và lớp được biết, người vận hành có thể sửa chữa yêu cầu, giảm khối lượng công việc, phục hồi một phiên được ủy quyền, hoặc liên quan đến chủ sở hữu trang mà không làm lẫn lộn các thay đổi không liên quan.

Để đóng một sự cố khối scraping, hãy ghi lại một phiên trao đổi, gán nó cho lớp chính xác, thử nghiệm thay đổi nhỏ nhất được hỗ trợ, và chứng minh rằng nội dung khớp với hợp đồng dữ liệu. Chuỗi đó giải quyết một khối scraping mà không làm lẫn lộn các thay đổi yêu cầu không liên quan và để lại bằng chứng rằng các nhóm vận hành, bảo mật, và ứng dụng có thể xem xét cùng nhau.

Tài liệu tham khảo

• Tài liệu về Scrapeless Web Unlocker
• Tổng quan sản phẩm Scrapeless Web Unlocker
• Hướng dẫn Scrapeless để chẩn đoán lỗi 403 trong web scraping
• Các dự án mã nguồn mở Scrapeless trên GitHub