← Quay lại blog
RUENESZHARPTDEFRJAKOITTRIDVIFAHI

Proxy cho Firecrawl, Crawl4AI và Crawlee: Tạo bộ dữ liệu cho RAG không bị chặn

Firecrawl, Crawl4AI và Crawlee mặc định sử dụng IP của máy chủ của bạn và tải toàn bộ trang — với hình ảnh mà trong markdown vẫn không xuất hiện. Chúng ta sẽ phân tích nơi thiết lập proxy trong từng công cụ, cách kích hoạt tăng cường đa cấp (yêu cầu trực tiếp → trung tâm dữ liệu → cư trú) và cách cắt giảm lưu lượng phương tiện, để việc thu thập dữ liệu cho RAG không biến thành hóa đơn hàng gigabyte.

📅22 tháng 8, 2026
Proxy cho Firecrawl, Crawl4AI và Crawlee: Tạo bộ dữ liệu cho RAG không bị chặn
```html

Sơ đồ "đã khởi động Firecrawl trong Docker, nhắm vào danh sách miền, nhận markdown cho RAG" hoạt động chính xác cho đến khi đạt một nghìn trang. Sau đó, có hai hóa đơn đến. Hóa đơn đầu tiên - từ các hệ thống chống bot: một số miền bắt đầu trả về 403 thay vì nội dung, và trong cơ sở tri thức xuất hiện những lỗ hổng mà bạn chỉ biết khi trợ lý trả lời "không có thông tin trong tài liệu đã cung cấp". Hóa đơn thứ hai - cho lưu lượng truy cập: crawler trung thực kéo từng hình ảnh và từng phông chữ, mà cuối cùng vẫn không vào được markdown.

Chúng ta hãy xem cách kết nối proxy với ba crawler LLM phổ biến nhất năm 2026 - Firecrawl, Crawl4AI và Crawlee - và cách cấu hình chúng để proxy chỉ hoạt động ở những nơi cần thiết, thay vì tiêu tốn gigabyte trên mỗi trang.

Dành cho ai hướng dẫn này

Nếu bạn đang thu thập một tập tài liệu cho RAG, làm đầy cơ sở tri thức nội bộ, xây dựng pipeline dữ liệu cho việc đào tạo thêm hoặc chỉ đơn giản là thường xuyên tải xuống hàng trăm miền - đây là trường hợp của bạn. Cả ba công cụ dưới đây trong cấu hình mặc định đều sử dụng IP của máy chủ của bạn và tải toàn bộ trang. Cả hai mặc định này cần phải được thay đổi.

Quy mô của vấn đề được hiểu qua con số phổ biến: Firecrawl vào thời điểm xuất bản có khoảng 170.000 sao trên GitHub (giấy phép AGPL-3.0), Crawl4AI có khoảng 79.000, Crawlee từ Apify có khoảng 25.000. Đây không còn là những thử nghiệm ngách, mà là công cụ tiêu chuẩn, và các hệ thống chống bot biết hành vi của chúng không kém gì bạn.

Hóa đơn thứ nhất: 403 thay vì nội dung

Sai lầm chính khi thu thập tập tài liệu - là nghĩ rằng crawler đã hoạt động thành công nếu nó không bị sập. Firecrawl và Crawl4AI trên trang bị chặn trả về không phải là ngoại lệ, mà là kết quả: trang đệm của hệ thống chống bot, trang kiểm tra trình duyệt hoặc một đoạn văn ngắn về việc từ chối truy cập. Về mặt hình thức, đây là markdown hợp lệ, nó nằm yên trong cơ sở vector cho đến khi có yêu cầu từ người dùng.

Vì vậy, điều đầu tiên cần làm trước khi cấu hình proxy - là thêm kiểm soát chất lượng kết quả. Biến thể tối thiểu: loại bỏ các tài liệu ngắn hơn một ngưỡng nhất định (đối với một trang nội dung điển hình, hợp lý là 500-800 ký tự văn bản) và riêng biệt bắt các dấu hiệu đặc trưng trong văn bản - đề cập đến kiểm tra kết nối, JavaScript đã bật, "Access denied". Những tài liệu như vậy không được gửi vào cơ sở dữ liệu, mà vào hàng đợi để kiểm tra lại - đã qua proxy.

Hóa đơn thứ hai: gigabyte mà bạn đang vứt đi

Ở đây, toán học giúp ích. Theo dữ liệu từ Web Almanac của HTTP Archive cho năm 2025, trang chính trung bình nặng khoảng 2,86 MB trên máy tính để bàn và 2,56 MB trên di động. Trong số đó, hình ảnh chiếm khoảng 1.059 KB trên các trang chính và 911 KB trên các trang nội bộ, JavaScript - 697 KB và 632 KB tương ứng. Điều này có nghĩa là hình ảnh là loại nặng nhất, chiếm khoảng một phần ba trọng lượng của trang.

Và bây giờ hãy nhớ rằng bạn đang làm gì với kết quả. Bạn chuyển đổi trang thành markdown và cắt thành các khối cho việc nhúng. Hình ảnh trong pipeline này hoàn toàn không được đưa vào - trong trường hợp tốt nhất, chỉ còn lại một dòng với văn bản alt. Video, phông chữ, script phân tích, pixel quảng cáo - cũng không vào.

Nếu bạn chạy quét qua proxy cư trú với thanh toán theo gigabyte, bạn thực sự đang trả tiền cho việc giao dữ liệu mà bạn sẽ vứt đi ở bước tiếp theo của pipeline. Trên một tập hợp 100.000 trang, sự khác biệt giữa "kéo tất cả" và "kéo chỉ HTML và văn bản" không được đo bằng phần trăm, mà bằng nhiều lần. Tiết kiệm chính xác phụ thuộc vào chủ đề của các trang web: truyền thông và thương mại điện tử nặng hơn tài liệu và blog.

Bước 1. Tăng cường thay vì "proxy cho tất cả"

Chiêu thức kiến trúc chính tiết kiệm nhiều nhất: không cho phép toàn bộ lưu lượng đi qua proxy. Phần lớn các miền khi thu thập cơ sở tri thức - tài liệu, blog, trang thông tin, cổng thông tin chính phủ - cung cấp nội dung trực tiếp và không chặn ai cả. Proxy chỉ cần cho thiểu số.

Sơ đồ đúng là tăng cường nhiều cấp: đầu tiên là yêu cầu trực tiếp, khi có dấu hiệu bị chặn - chuyển sang cấp tiếp theo. Hơn nữa, đây không phải là một giải pháp tự viết, cả hai framework lớn đều có thể làm như vậy ngay từ đầu.

Trong Crawlee, có tieredProxyUrls cho điều này. Các cấp được liệt kê từ rẻ đến đắt, và crawler tự động tăng lên khi bị chặn, sau đó định kỳ thử quay lại cấp thấp hơn:

const proxyConfiguration = new ProxyConfiguration({
    tieredProxyUrls: [
        [null],
        ['http://user:pass@datacenter-proxy:8080'],
        ['http://user:pass@residential-proxy:8000'],
    ]
});

Điều quan trọng từ tài liệu: tieredProxyUrls chỉ hoạt động khi sử dụng qua một phiên bản của crawler. Các cuộc gọi trực tiếp newUrl() sẽ cho kết quả không mong đợi.

Trong Crawl4AI, cơ chế tương tự đã xuất hiện trong phiên bản 0.8.5 và sống trong nhánh hiện tại (phiên bản phát hành cuối cùng tại thời điểm xuất bản - v0.9.2 vào ngày 15 tháng 7 năm 2026). Nó được gọi là tăng cường proxy và được cấu hình ngay trong CrawlerRunConfig: phát hiện ba cấp độ chặn - các nhà cung cấp chống bot nổi tiếng, các chỉ số chặn chung và kiểm tra tính toàn vẹn cấu trúc của trang - cộng với tự động thử lại theo chuỗi proxy.

from crawl4ai import CrawlerRunConfig
from crawl4ai.async_configs import ProxyConfig

config = CrawlerRunConfig(
    proxy_config=[ProxyConfig.DIRECT, ProxyConfig(server="http://my-proxy:8080")],
    max_retries=2,
)

Lưu ý rằng ProxyConfig.DIRECT là phần tử đầu tiên - đây chính là "trước tiên hãy thử mà không có proxy".

Bước 2. Kết nối proxy trong từng công cụ

Tiếp theo - cụ thể về cấu hình. Thứ tự hành động giống nhau: trước tiên là proxy, sau đó là cắt bỏ lưu lượng không cần thiết, sau đó là kiểm tra.

  1. Firecrawl (tự lưu trữ). Proxy được xác định bằng ba biến môi trường, được truyền vào Playwright: PROXY_SERVER, PROXY_USERNAME, PROXY_PASSWORD. Được ghi trong .env cho apps/api; trong chú thích của chúng, các nhà phát triển viết rõ rằng thay vì địa chỉ tĩnh, bạn có thể chỉ định dịch vụ proxy, mà sẽ thay đổi IP cho mỗi yêu cầu.
  2. Crawl4AI. Proxy sống trong BrowserConfig, trong trường proxy_config - đây là đối tượng ProxyConfig hoặc từ điển với các trường server, username, password. Một cấu hình trình duyệt cho toàn bộ phiên crawling; một CrawlerRunConfig riêng biệt được truyền cho mỗi cuộc gọi arun().
  3. Crawlee. Lớp ProxyConfiguration với tùy chọn proxyUrls - danh sách các địa chỉ mà thư viện đi theo vòng (round-robin). Giá trị null trong danh sách có nghĩa là "không có proxy". Tích hợp xuyên suốt: HttpCrawler, CheerioCrawler, JSDOMCrawler, PlaywrightCrawler, PuppeteerCrawler.
  4. Quy tắc điểm. Nếu biết các miền nào bị chặn và các miền nào không, trong Crawlee có newUrlFunction - logic riêng để chọn proxy dựa trên URL yêu cầu. Đối với các miền trắng, trả về null, cho các miền khác - địa chỉ proxy. Đây là lựa chọn rẻ nhất khi danh sách mục tiêu ổn định.
  5. Kiểm tra. Trước khi chạy thực tế, hãy cho một trang trả về IP bên ngoài của bạn qua crawler đã cấu hình và đảm bảo rằng bạn thấy địa chỉ proxy, chứ không phải máy chủ. Ba dòng này tiết kiệm một ngày tìm hiểu.

Bước 3. Cắt bỏ mọi thứ không trở thành văn bản

Khi proxy đã được kết nối, hãy bật tiết kiệm lưu lượng - nếu không hóa đơn cho gigabyte sẽ đến nhanh hơn so với việc tập hợp cơ sở dữ liệu.

Trong Firecrawl, điều này được thực hiện bởi biến BLOCK_MEDIA. Trong ví dụ cấu hình chính thức, có một chú thích rõ ràng: hãy đặt nếu bạn muốn chặn các yêu cầu media, để tiết kiệm băng thông proxy. Đây là cách nhanh nhất để loại bỏ chi phí chính.

Trong Crawl4AI, các công cụ tương tự sống trong BrowserConfig: text_mode tắt hình ảnh và tăng tốc độ quét văn bản, light_mode tắt một số chức năng nền của trình duyệt, avoid_css chặn tải CSS. Chúng có thể được kết hợp. Đối với việc thu thập tập tài liệu cho RAG, đây gần như luôn là bộ công cụ đúng - bạn không cần bố cục, bạn cần văn bản.

Trong Crawlee, logic khác: nếu nội dung được trả về dưới dạng HTML, hãy sử dụng CheerioCrawler hoặc HttpCrawler thay vì các trình duyệt. Yêu cầu HTTP thông thường thay vì một bản render hoàn chỉnh - không chỉ là tiết kiệm lưu lượng, mà còn là một thứ tự chi phí khác. Các crawler trình duyệt (PlaywrightCrawler, PuppeteerCrawler) chỉ nên được giữ lại cho các trang không thể thu thập mà không có JavaScript.

Các cạm bẫy

Phiên chống lại việc thay đổi IP. Việc thay đổi IP cho mỗi yêu cầu tự nó trông đáng ngờ và phá vỡ các kịch bản nhiều bước - phân trang, chuyển tiếp trong cùng một miền. Trong Crawlee, mỗi cuộc gọi newUrl() liên kết proxy với đối tượng Session, và chúng được thay đổi cùng với dấu vân tay của trình duyệt và tiêu đề. Đừng phá vỡ mối liên kết này một cách thủ công.

Media đã tắt, nhưng nội dung đã biến mất. Một số trang web sử dụng tải lười không chỉ kéo hình ảnh mà còn cả văn bản. Sau khi bật text_mode hoặc BLOCK_MEDIA, hãy chắc chắn chạy một mẫu kiểm tra từ 20-30 trang và so sánh khối lượng văn bản với tiêu chuẩn.

Retry không giới hạn. Tăng cường theo cấp độ proxy có nghĩa là một trang cứng đầu có thể được tải xuống ba lần - và cả ba lần đều phải trả tiền. Hạn chế max_retries và tạo danh sách các miền mà sau N lần không thành công sẽ bị loại khỏi việc quét hoàn toàn.

Robots.txt và khung pháp lý. Việc thu thập dữ liệu cho đào tạo và RAG vào năm 2026 được quản lý chặt chẽ hơn so với vài năm trước - từ yêu cầu tiết lộ nguồn đến các cơ chế từ chối khai thác văn bản và dữ liệu. Hãy kiểm tra rằng pipeline của bạn tôn trọng các tín hiệu này trước khi nó hoạt động trên hàng trăm nghìn trang.

Loại proxy nào nên sử dụng cho pipeline RAG

Câu trả lời phụ thuộc vào cấp độ tăng cường mà bạn đang ở.

  • Cấp độ không - không có proxy. Tài liệu, các dự án mã nguồn mở, trang web chính phủ, hầu hết các blog doanh nghiệp. Ở đây IP của máy chủ hoạt động bình thường, và không có gì để trả tiền.
  • Cấp độ trung bình - proxy trung tâm dữ liệu. Nhanh và rẻ, phù hợp với việc chống lại việc giới hạn tỷ lệ đơn giản và các hạn chế khu vực. Khi thu thập các tập lớn, đây là con ngựa làm việc: khi khối lượng được đo bằng hàng trăm gigabyte, sự khác biệt về giá cho mỗi gigabyte trở thành yếu tố chính.
  • Cấp độ cao - proxy cư trú. Dành cho các miền có bảo vệ chống bot nghiêm ngặt, nơi các subnet trung tâm dữ liệu bị loại bỏ ngay từ đầu. Đó là lý do tại sao chúng không thể được đặt làm mặc định - việc thanh toán theo gigabyte biến mỗi hình ảnh thừa thành một dòng chi phí.

Trước khi xây dựng pipeline, nên tính toán kinh tế một cách trung thực: chúng tôi đã phân tích toàn bộ chi phí để phân tích một triệu trang với sự xem xét đến trọng lượng trang, số lần thử lại và các chi phí ẩn. Và một câu hỏi riêng mà hữu ích để đặt ra trước khi viết dòng mã đầu tiên: liệu việc quét có thực sự cần thiết không - trong phân tích API chính thức so với các tập dữ liệu sẵn có và việc phân tích cho thấy rằng đối với một số nguồn, dữ liệu sẵn có rẻ hơn so với crawler tự xây dựng.

Kết luận

Proxy trong LLM-crawler không phải là một công tắc "bật/tắt", mà là một sơ đồ ba cấp. Yêu cầu trực tiếp như cấp mặc định, proxy trung tâm dữ liệu ở cấp trung bình, proxy cư trú - chỉ dành cho các miền mà không thể thu thập theo cách khác. Thêm vào đó là việc cắt bỏ nghiêm ngặt media, vì bạn đang thu thập văn bản, nhưng lại trả tiền cho byte.

Thứ tự công việc rất đơn giản: trước tiên là kiểm soát chất lượng kết quả (nếu không bạn sẽ không biết rằng một nửa tập tài liệu là các trang đệm), sau đó là tăng cường proxy bằng các phương tiện của chính framework, sau đó là tiết kiệm lưu lượng. Theo thứ tự này - cả tập tài liệu sẽ đầy đủ, và hóa đơn sẽ dễ dự đoán.

```