Quay lại blog

Hướng dẫn Trình thu thập Cloudflare: Truy xuất và Xác thực Nội dung Trang với Scrapeless

Michael Lee
Michael Lee

Expert Network Defense Engineer

10-Oct-2026

Tóm tắt nhanh:

  • Một scraper Cloudflare phải kiểm tra lại nội dung được yêu cầu sau khi nhận về. Một yêu cầu HTTP hoàn tất vẫn có thể khiến ứng dụng không có dữ liệu trang usable.
  • Scrapeless Web Unlocker là con đường định hướng theo phản hồi. Agent Browser phù hợp khi quy trình cần phiên trình duyệt được kiểm soát hoặc tương tác với trang.
  • Phản hồi của dịch vụ và phản hồi từ origin là các quan sát riêng biệt. Đừng xem header của một API như thể chúng là header của website mục tiêu.
  • Chấp nhận bản ghi theo hợp đồng riêng của từng nguồn. Kiểm tra định danh trang, nội dung mong đợi, các trường bắt buộc và ý nghĩa của một kết quả rỗng.

Một scraper có thể lưu một tài liệu challenge dưới URL sản phẩm mà không nhận ra. Yêu cầu đã hoàn tất, parser tìm thấy văn bản, và bản ghi thu được trông có vẻ đã được điền dữ liệu. Nó vẫn mô tả sai tài liệu.

Hướng dẫn scraper Cloudflare này tập trung vào ranh giới chấp nhận đó. Nó sử dụng Scrapeless Web Unlocker để yêu cầu HTML và một bộ kiểm tra nhỏ viết bằng Python để phân biệt nội dung được chấp nhận với một challenge hoặc một bản ghi chưa đầy đủ. Ví dụ kiểm tra cục bộ sử dụng các trang minh họa rõ ràng; việc thu thập mục tiêu đã xác thực yêu cầu khóa của riêng bạn và nguồn được cho phép.

Một Scraper Cloudflare Cần Xử Lý Những Gì?

Một scraper Cloudflare cần lấy được nội dung mục tiêu được phép và nhận ra khi nó nhận được một phản hồi khác. Xử lý challenge và trích xuất dữ liệu là các phần riêng biệt của công việc đó.

Cloudflare có thể trả về một trang xen kẽ Challenge Page thay cho tài nguyên dự kiến. Tín hiệu phản hồi Challenge Page của nó sử dụng header origin cf-mitigated: challenge, và loại nội dung challenge là text/html.

Tín hiệu đó hữu ích khi ứng dụng có thể quan sát phản hồi từ origin. Một API thu thập được quản lý có thể trả về lớp JSON riêng của nó và các header dịch vụ. Nếu nó không lộ các header của mục tiêu, thì việc thiếu chúng trong phản hồi API không thể khẳng định rằng mục tiêu không bị challenge.

Giữ các kiểm tra nội dung dương tính song song với những tín hiệu challenge sẵn có. Tiêu đề bài viết mong đợi hoặc định danh sản phẩm là bằng chứng mạnh hơn cho trang được yêu cầu so với việc vắng mặt của một cụm từ chung chung.

HTTP Thành Công và Nội Dung Thành Công Là Khác Nhau

HTTP thành công mô tả kết quả của giao thức; nội dung thành công mô tả việc phản hồi có đáp ứng nhiệm vụ thu thập của bạn hay không. Ngữ nghĩa phản hồi HTTP không định nghĩa schema sản phẩm hay quy tắc chấp nhận bài viết của bạn.

Tách biệt yêu cầu dịch vụ, payload trả về và bản ghi đã trích xuất. Một phản hồi dịch vụ có thể là JSON hợp lệ trong khi dữ liệu của nó chứa một trang không phù hợp. Ngược lại, một trang tìm kiếm hợp lệ có thể không có kết quả khớp mà vẫn không bị chặn.

Lớp Câu hỏi Bằng chứng cần giữ
Yêu cầu API Dịch vụ có chấp nhận và hoàn tất thao tác không? Trạng thái dịch vụ và lớp bao (envelope)
Định danh trang Đây có phải trang dự định hay một trang canonical tương đương được phép? URL được yêu cầu và định danh cuối cùng sẵn có
Nội dung Trang có chứa nguồn tư liệu cần thiết không? Tiêu đề, marker hoặc đoạn văn hỗ trợ
Trích xuất Các trường bắt buộc có hợp lệ cho tác vụ này không? Giá trị đã parse và kết quả kiểm tra
Trạng thái rỗng Bản thân nguồn có xác nhận rằng không tồn tại bản ghi nào không? Bằng chứng trạng thái rỗng đặc thù cho nguồn

Sử dụng các lý do lỗi riêng biệt ở những lớp này. “Không có bản ghi” không phải là chẩn đoán thích hợp khi tài liệu đã thu không bao giờ chứa trang được yêu cầu.

Chọn Web Unlocker hay Agent Browser Theo Tác Vụ

Web Unlocker phù hợp với quy trình bắt đầu bằng URL mục tiêu và cần nội dung trả về. Cấu hình render của nó hỗ trợ yêu cầu HTML thông qua các trường jsRender được ghi trong tài liệu.

Agent Browser phù hợp với các tác vụ yêu cầu kiểm soát phiên trình duyệt, tương tác hoặc điều hướng qua các trạng thái trang. Chọn con đường đó khi ứng dụng phải làm việc với chính trang thay vì chỉ tiêu thụ một phản hồi thu thập.

Giữ mỗi phần triển khai trong bề mặt sản phẩm đã chọn. Ví dụ dưới đây dùng Web Unlocker. Nó không biến một phiên trình duyệt thành HTTP API ở giữa hướng dẫn, và nó không bảo đảm chấp nhận trên mọi mục tiêu được bảo vệ.

Bắt đầu với phương thức truy cập được nguồn hỗ trợ. Một dịch vụ thu thập không phải là giấy phép, và nội dung nằm sau một hạn chế không nên được coi là mục tiêu thu thập công khai chỉ vì một client có thể yêu cầu URL của nó.

Yêu Cầu Tiên Quyết và Cài Đặt

Ví dụ yêu cầu này cần một khóa API Scrapeless, quyền truy cập tài khoản vào Web Unlocker, Python và gói requests. Trình bộ xác thực chỉ sử dụng thư viện tiêu chuẩn của Python.

Thiết lập SCRAPELESS_API_KEY một cách riêng tư trong môi trường runtime của bạn. Đặt TARGET_URL thành một trang công khai hoặc được ủy quyền khác mà bạn đã kiểm tra tiêu đề mong đợi và trường nhận dạng. Không in thông tin xác thực hoặc đặt chúng trong các bản ghi đầu ra của bài viết.

Trước khi gọi dịch vụ, hãy cài đặt requests trong môi trường dự án của bạn và kiểm tra hướng dẫn bắt đầu nhanh Web Unlocker. Ghi lại phiên bản phụ thuộc của bạn trong lock file của dự án hoặc bản kê khai môi trường. Tài khoản dịch vụ và mục tiêu được cho phép là điều kiện tiên quyết cho phần mạng; không có việc bắt giữ đã xác thực nào được khẳng định ở đây.

Gửi Yêu Cầu HTML Đã Render Tối Thiểu

Yêu cầu render Web Unlocker hiện tại sử dụng endpoint v2 và một đối tượng lồng nhau jsRender. Lưu HTML được trả về tách biệt với phong bì dịch vụ để cả hai vẫn có thể được kiểm tra.

Lưu ý: Yêu cầu này cần một khóa API Scrapeless thật, quyền truy cập tài khoản và một TARGET_URL được ủy quyền. Nó đã được kiểm tra với tài liệu yêu cầu hiện tại nhưng không được thực thi đối với một mục tiêu trả phí trong ví dụ này.

python Copy
import json
import os
from pathlib import Path
import requests

target = os.environ["TARGET_URL"]
response = requests.post(
    "https://api.scrapeless.com/api/v2/unlocker/request",
    headers={"x-api-token": os.environ["SCRAPELESS_API_KEY"]},
    json={
        "actor": "unlocker.webunlocker",
        "proxy": {"country": "ANY"},
        "input": {
            "url": target,
            "jsRender": {
                "enabled": True,
                "response": {"type": "html"}
            }
        }
    },
    timeout=60
)
response.raise_for_status()
envelope = response.json()
html = envelope.get("data")
if envelope.get("code") != 200 or not isinstance(html, str):
    raise ValueError("Expected a successful HTML envelope")
Path("page.html").write_text(html, encoding="utf-8")
print(json.dumps({"requested_url": target, "html_characters": len(html)}))

Bước kiểm tra phong bì API thiết lập hình dạng phản hồi đã được ghi lại trong tài liệu. Nó vẫn chưa thiết lập rằng page.html chứa nguồn mà ứng dụng của bạn cần. URL được ghi lại là URL được yêu cầu; đừng đổi tên nó thành final_url mà không quan sát đích đến cuối cùng.

Xác Định Hợp Đồng Nội Dung Trước Khi Parse

Hợp đồng nội dung nêu tên bằng chứng tối thiểu cần có để chấp nhận một trang. Đối với một bài viết, nó có thể yêu cầu tiêu đề dự định và một định danh nguồn. Một tác vụ sản phẩm cần các trường sản phẩm và biến thể riêng của nó.

Viết hợp đồng từ một trang mục tiêu đã được kiểm tra. Tránh việc đặt một lớp CSS được đoán làm định nghĩa duy nhất cho thành công. Các định danh ổn định, trường có cấu trúc được ghi lại và các mẫu URL bền vững rất hữu ích khi nguồn cung cấp chúng.

Quyết định cách biểu diễn các trường tùy chọn. Việc thiếu tác giả có thể chấp nhận được đối với một nguồn bài viết; việc thiếu định danh sản phẩm có thể khiến toàn bộ bản ghi sản phẩm không sử dụng được. Ghi lại một lý do thay vì điền trường thiếu bằng văn bản bịa đặt.

Bắt Đầu Thu Thập Dữ Liệu với Scrapeless

Tăng cường quy trình thu thập dữ liệu web và tự động hóa của bạn với Scrapeless!
Đăng ký hôm nay và nhận $5 tín dụng miễn phí — không cần thẻ tín dụng.

Nhận tín dụng miễn phí của bạn ngay trong Bảng điều khiển Scrapeless.

Chạy Một Kiểm Tra Chấp Nhận Nội Dung Nhỏ

Một kiểm tra chấp nhận cục bộ nên từ chối tín hiệu thách thức rõ ràng và yêu cầu bằng chứng tích cực về trang mong đợi. Script hoàn chỉnh sau đây thực thi quy tắc đó trên các fixture HTML minh họa.

Tiêu đề và marker data-record-id thuộc về các fixture này. Chúng không được quảng cáo như các bộ chọn cho một trang web được bảo vệ bất kỳ. Script được chạy cục bộ để kiểm tra hành vi xác thực; đầu ra của nó không phải là kết quả thu thập Cloudflare trực tiếp.

python Copy
import json
from html.parser import HTMLParser

class Signals(HTMLParser):
    def __init__(self):
        super().__init__()
        self.heading = []
        self.ids = []
        self.in_heading = False

    def handle_starttag(self, tag, attrs):
        if tag == "h1":
            self.in_heading = True
        marker = dict(attrs).get("data-record-id")
        if marker:
            self.ids.append(marker)

    def handle_endtag(self, tag):
        if tag == "h1":
            self.in_heading = False

    def handle_data(self, data):
        if self.in_heading:
            self.heading.append(data)

def assess(html, origin_headers, expected_heading):
    headers = {k.lower(): v for k, v in origin_headers.items()}
    if headers.get("cf-mitigated") == "challenge":
        return {"status": "quarantined", "reason": "origin_challenge"}
    signals = Signals()
    signals.feed(html)
    heading = " ".join(" ".join(signals.heading).split())
    if heading != expected_heading or not signals.ids:
        return {"status": "rejected", "reason": "content_contract"}
    return {"status": "accepted", "heading": heading, "ids": signals.ids}

# Illustrative fixtures; these are not fetched target pages.
fixtures = [
    ("article", '<h1>Public Article</h1><main data-record-id="demo-a"></main>', {}),
    ("challenge", '<h1>Challenge</h1>', {"cf-mitigated": "challenge"}),
    ("incomplete", '<h1>Public Article</h1>', {})
]
print(json.dumps({name: assess(html, headers, "Public Article")
                  for name, html, headers in fixtures}))

Fixture bài viết được chấp nhận, fixture thách thức rõ ràng bị cách ly, và fixture thiếu định danh của nó bị từ chối. Điều này chứng minh hành vi nhánh cục bộ trên các đầu vào được hiển thị. Điều chỉnh hợp đồng cho nguồn thực tế trước khi đánh giá một bản thu từ dịch vụ.

Đối với việc lựa chọn trường phức tạp hơn, hãy giữ logic trích xuất tách biệt khỏi quyết định chấp nhận‑hay‑từ‑chối này. Hướng dẫn trích xuất HTML bao quát lớp phân tích cú pháp.

Phân Biệt Kết Quả Rỗng với Nội Dung Không Thể Sử Dụng

Một kết quả rỗng hợp lệ đòi hỏi bằng chứng tích cực về trạng thái rỗng của nguồn. Một kết quả bộ chọn rỗng một mình không thể cung cấp bằng chứng đó.

Đối với một trang tìm kiếm, hãy kiểm tra một marker không‑kết‑quả được ghi lại hoặc một điều kiện cụ thể khác của nguồn. Đối với một bài viết, việc thiếu tiêu đề thường là một bản thu không đầy đủ hoặc không phù hợp hơn là một bài viết rỗng. Giữ lại những phân biệt đó trong bản ghi.

Quan sát Cách diễn giải hữu ích Lần kiểm tra tiếp theo
Tín hiệu thách thức nguồn rõ ràng Phản hồi thách thức Thu thập và đường truy cập được cho phép
Tiêu đề mong đợi, thiếu định danh Bản ghi không đầy đủ Markup nguồn và hợp đồng trích xuất
Không có phần tử khớp Chưa được giải quyết Danh tính trang, việc render và bộ chọn
Trạng thái rỗng của nguồn đã được xác nhận Rỗng hợp lệ Lưu lại bằng chứng trạng thái rỗng
Nguồn dự định và các trường hợp lệ Nội dung được chấp nhận Lưu trữ và phân tích ở bước sau
Tránh gắn nhãn mọi lần thu thập bị từ chối là bị Cloudflare chặn. Một bộ chọn đã thay đổi, chuyển hướng theo khu vực, hoặc URL khởi đầu sai cũng có thể dẫn đến việc không có bản ghi.

Bảo Tồn Dữ Liệu Đầu Ra và Bằng Chứng Thu Thập

Một bản ghi được chấp nhận cần giữ đủ bằng chứng nguồn để giải thích tại sao nó được chấp nhận. Lưu trữ URL được yêu cầu, danh tính cuối cùng có sẵn, thời điểm thu thập, quy tắc trích xuất, trạng thái xác thực và các giá trị bắt buộc.

Sử dụng nguồn gốc dữ liệu (source provenance) để giữ cho quan sát được kết nối với hoạt động đã tạo ra nó. Giữ lại lý do của một bản ghi bị từ chối mà không chuyển tiếp nội dung của nó như một bản ghi nghiệp vụ thành công.

Ứng dụng của bạn sở hữu lược đồ này. Các trường phản hồi của dịch vụ và bản ghi đã chuẩn hóa của bạn là hai hợp đồng khác nhau, vì vậy hãy ghi lại việc chuyển đổi thay vì coi chúng là thể hoán đổi cho nhau.

Giới Hạn và Thu Thập Có Trách Nhiệm

Một trình thu thập dữ liệu Cloudflare phải tôn trọng quyền truy cập được cho phép từ nguồn và các giới hạn của phương thức thu thập đã chọn. Quy trình làm việc này không hứa hẹn tỷ lệ thành công phổ quát hay quyền truy cập vào các trang riêng tư.

Xem lại điều khoản của nguồn và quy tắc loại trừ robots trước khi thu thập. Giữ một danh sách mục tiêu có giới hạn và chỉ thu thập dữ liệu mà nhiệm vụ của bạn cần.

Bắt đầu với một mục tiêu được cho phép. Một giới hạn đồng thời nhỏ, chẳng hạn không quá ba worker trên mỗi host, là chính sách của ứng dụng cho ví dụ này, không phải giới hạn của dịch vụ Scrapeless. Chỉ mở rộng sau khi quyền từ nguồn, nội dung được chấp nhận và chi phí vận hành đã được xem xét.

Kết Luận

Một trình thu thập dữ liệu Cloudflare hữu ích trả về các bản ghi mà nguồn và các trường của chúng đã vượt qua các kiểm tra của nhiệm vụ. Yêu cầu chỉ là bước thu thập.

Hãy sử dụng Web Unlocker cho kiểu thu thập định hướng phản hồi, giữ nguyên payload của dịch vụ và xác thực trang dự định trước khi chấp nhận các trường đã trích xuất. Giữ riêng các trạng thái thử thách, chưa hoàn chỉnh và hợp lệ-nhưng-trống.

Sẵn Sàng Xác Thực Dữ Liệu Web Của Bạn?

Xây dựng một bước kiểm tra nội dung được cho phép với Scrapeless và đánh giá các bản ghi được chấp nhận dựa trên bảng giá hiện tại. Thảo luận về hợp đồng trích xuất của bạn trên Telegram.

Câu Hỏi Thường Gặp (FAQ)

H: Việc thu thập dữ liệu một trang web được Cloudflare bảo vệ có hợp pháp không?

Công nghệ bảo vệ không thiết lập quyền được phép thu thập một trang. Xem lại điều khoản của nguồn, các yêu cầu áp dụng, và sự cho phép của bạn trước khi sử dụng một trình thu thập dữ liệu.

H: Quy trình Web Unlocker này có cần một proxy cấu hình riêng không?

Yêu cầu được hiển thị sử dụng đường dẫn thu thập được quản lý và trường quốc gia được ghi nhận của nó. Thông tin xác thực proxy được cấp riêng chỉ cần thiết khi chính client của bạn sử dụng sản phẩm proxy độc lập.

H: Một phản hồi HTTP 200 có chứng minh rằng việc thu thập dữ liệu đã thành công không?

Một phản hồi HTTP 200 không chứng minh rằng nội dung nghiệp vụ được yêu cầu đã được lấy. Kiểm tra danh tính trang, payload và các trường bắt buộc trước khi chấp nhận bản ghi.

H: Khi nào quy trình làm việc nên sử dụng Agent Browser?

Sử dụng Agent Browser khi nhiệm vụ cần một phiên trình duyệt được kiểm soát hoặc tương tác với trạng thái trang. Một phản hồi nội dung đơn thường là đủ cho một nhiệm vụ định hướng phản hồi.

H: Cần thay đổi điều gì khi các bộ chọn trên trang không còn khớp?

Kiểm tra lại markup của nguồn và các trường bắt buộc, sau đó cập nhật hợp đồng trích xuất. Kết quả thiếu bộ chọn nên vẫn ở trạng thái chưa được giải quyết cho đến khi danh tính và nội dung trang được kiểm tra.

H: Ví dụ này nên sử dụng mức đồng thời bao nhiêu?

Bắt đầu với một tập nguồn giới hạn và không quá ba worker trên mỗi host như chính sách thu thập của ví dụ. Quyền từ nguồn và hoạt động quan sát được nên chi phối mọi việc mở rộng sau này.

H: Quy trình này có thể chạy mà không cần một tác nhân AI không?

Yêu cầu HTTP và bước xác thực bằng Python có thể chạy mà không cần một tác nhân AI. Một tác nhân có thể tiêu thụ các bản ghi đã được chấp nhận sau khi các kiểm tra quyết định đã hoàn tất.

H: URL được yêu cầu có nên được lưu như URL chuẩn tắc (canonical) không?

Lưu trữ URL được yêu cầu tách biệt với bất kỳ danh tính trang cuối cùng hoặc chuẩn tắc nào. Chỉ sử dụng một giá trị chuẩn tắc khi quá trình thu thập hoặc nội dung nguồn thực sự thiết lập nó.

Tại Scrapless, chúng tôi chỉ truy cập dữ liệu có sẵn công khai trong khi tuân thủ nghiêm ngặt các luật, quy định và chính sách bảo mật trang web hiện hành. Nội dung trong blog này chỉ nhằm mục đích trình diễn và không liên quan đến bất kỳ hoạt động bất hợp pháp hoặc vi phạm nào. Chúng tôi không đảm bảo và từ chối mọi trách nhiệm đối với việc sử dụng thông tin từ blog này hoặc các liên kết của bên thứ ba. Trước khi tham gia vào bất kỳ hoạt động cạo nào, hãy tham khảo ý kiến ​​cố vấn pháp lý của bạn và xem xét các điều khoản dịch vụ của trang web mục tiêu hoặc có được các quyền cần thiết.

Bài viết phổ biến nhất

Danh mục