Cheerio proxy hướng dẫn tải HTML và trích dữ liệu Node.js

Cheerio proxy cần được cấu hình ở bước tải HTML, rồi mới chuyển nội dung cho bộ phân tích. Nếu đặt sai chỗ, anh em có thể nhận trang rỗng dù kết nối vẫn thành công. Bài này, ProxyVN hướng dẫn xây một ví dụ Node.js có kiểm tra đầu ra, phân biệt lỗi proxy với lỗi selector và nhận biết dữ liệu cần JavaScript.

Cheerio proxy và luồng tải HTML đến dữ liệu

Một chương trình thu thập dữ liệu cần làm đúng hai việc: lấy được phản hồi phù hợp và chuyển phản hồi đó thành bản ghi có ích. Hai việc liên quan với nhau nhưng không dùng cùng cấu hình. Hiểu ranh giới này giúp anh em sửa lỗi đúng chỗ ngay từ đầu.

Đặt proxy ở lớp gửi yêu cầu

Trong ví dụ của bài, Axios gửi yêu cầu qua một HTTP proxy bằng agent, còn Cheerio nhận chuỗi HTML để tìm phần tử. Proxy quyết định tuyến kết nối; selector quyết định phần dữ liệu được lấy. Thêm một thuộc tính proxy vào hàm load không tạo đường đi mạng cho chuỗi đã tải sẵn.

Cheerio có cả phương thức hỗ trợ tải tài liệu từ URL. Tuy nhiên, bài này chủ động tách bước tải và bước phân tích để kiểm soát timeout, phản hồi chuyển hướng và lỗi xác thực. Anh em có thể đối chiếu các cách nạp nội dung trong tài liệu Loading Documents của Cheerio.

Xác định kết quả cần thu thập

Đầu ra của ví dụ là danh sách sản phẩm gồm mã, tên, giá dạng số và URL chi tiết. Đầu vào là một trang danh mục thử có hai sản phẩm được viết sẵn trong HTML. Đây là dữ liệu mô phỏng để kiểm tra chương trình, không phải danh mục thật của một cửa hàng.

Khi triển khai cho trang khác, anh em cần thay selector và quy tắc kiểm tra tương ứng. Không nên lấy nguyên cấu trúc mẫu rồi kết luận website đích bị lỗi khi không tìm thấy dữ liệu. Một chương trình chỉ thành công khi bản ghi đáp ứng yêu cầu nghiệp vụ, thay vì chỉ nhận HTTP 200.

Kết nối qua proxy thành công chưa đủ. Hãy kiểm tra cả nội dung HTML và dữ liệu sau khi trích xuất.

Nếu cần ôn lại vai trò máy chủ trung gian, anh em có thể đọc bài web scraping proxy hoạt động thế nào. Phần còn lại tập trung vào một luồng xử lý cụ thể: tải trang, kiểm tra phản hồi, trích dữ liệu và lưu JSON.

Chuẩn bị môi trường Cheerio proxy có thể tái lập

Để người khác chạy lại được ví dụ, anh em cần ghi rõ phiên bản thư viện, cách khai báo biến môi trường và cấu trúc HTML. Một lệnh cài đặt không khóa phiên bản có thể cho kết quả khác sau vài tháng, ngay cả khi code trong bài không đổi.

Phiên bản dùng cho lần kiểm thử

Bộ ví dụ này được kiểm tra ngày 22/10/2026 bằng Node.js 24.19.0, Cheerio 1.1.2, Axios 1.12.2 và https-proxy-agent 7.0.6. Đây là các phiên bản của lần thử, không phải tuyên bố chúng là bản mới nhất. Khi đưa vào dự án, hãy đánh giá bản phát hành và yêu cầu bảo trì hiện hành.

Tạo thư mục làm việc riêng rồi chạy các lệnh dưới đây. Tệp có đuôi .mjs để Node.js hiểu cú pháp import mà không cần đổi cấu hình toàn dự án. Giữ package-lock.json sau khi cài; nếu chia sẻ cho đồng đội, dùng npm ci trên môi trường có cùng bộ khóa.

mkdir cheerio-proxy-demo
cd cheerio-proxy-demo
npm init -y
npm install --save-exact cheerio@1.1.2 axios@1.12.2 https-proxy-agent@7.0.6

Thông tin proxy và URL đích

Anh em cần địa chỉ máy chủ, cổng HTTP proxy và thông tin xác thực nếu gói dịch vụ yêu cầu. Mẫu sử dụng đích HTTPS và proxy HTTP hoặc HTTPS có hỗ trợ CONNECT. Nó không nhận URL SOCKS5; trường hợp đó cần một agent khác và kiểm thử riêng.

Trong PowerShell, khai báo các biến dưới đây sau khi thay giá trị mẫu. Miền example.test chỉ minh họa cú pháp, không phải website thử đang hoạt động. TARGET_URL phải trỏ tới trang HTTPS của anh em hoặc trang được phép thử với HTML phù hợp cấu trúc sản phẩm trong bài.

$env:TARGET_URL = 'https://example.test/products'
$env:PROXY_URL = 'http://USERNAME:PASSWORD@HOST:PORT'
node scrape.mjs

Nếu mật khẩu có ký tự @, dấu hai chấm hoặc dấu gạch chéo, hãy mã hóa riêng phần username và password trước khi ghép URL. Không mã hóa cả chuỗi địa chỉ vì sẽ làm mất các dấu phân tách cần thiết. Cũng không dán thông tin proxy thật vào log dùng để nhờ hỗ trợ.

Với nhu cầu đối chiếu nhiều kiểu agent, anh em xem thêm hướng dẫn cấu hình Axios proxy trong Node.js. Bài đó giải thích rộng về HTTP và SOCKS5; ở đây chỉ giữ một tuyến HTTPS qua CONNECT để tập trung vào đầu ra Cheerio.

Chuẩn bị đúng tuyến kết nối

Thiết kế dữ liệu mẫu cho Cheerio proxy

Một trang thử nhỏ giúp xác định vấn đề thuộc code hay website đích. Nếu cùng một hàm trích xuất thất bại với HTML tự kiểm soát, anh em cần sửa parser trước khi đánh giá chất lượng proxy. Cách này cũng tạo bộ dữ liệu cố định cho những lần chỉnh selector sau.

HTML có mã sản phẩm và giá dạng máy đọc

Lưu đoạn sau thành products.html trong thư mục thử. Hai thẻ article là hai bản ghi, thuộc tính data-product chứa mã riêng và data-value chứa giá chưa định dạng. Tên hiển thị có tiếng Việt để kiểm tra việc giữ nguyên ký tự khi xuất JSON.

<!doctype html>
<html lang="vi"><meta charset="utf-8"><title>Danh mục thử</title>
<article data-product="P01">
  <h2 class="name">Bàn phím cơ</h2>
  <span class="price" data-value="790000">790.000 đ</span>
  <a class="details" href="/san-pham/ban-phim">Chi tiết</a>
</article>
<article data-product="P02">
  <h2 class="name">Chuột không dây</h2>
  <span class="price" data-value="350000">350.000 đ</span>
  <a class="details" href="/san-pham/chuot">Chi tiết</a>
</article>
</html>

Giá hiển thị 790.000 đ dành cho người đọc, còn chuỗi 790000 trong data-value dành cho chương trình. Tách hai giá trị giúp ví dụ tránh nhầm dấu chấm ngăn hàng nghìn với dấu thập phân. Nếu website thực tế chỉ có giá hiển thị, anh em cần thiết kế quy tắc chuyển đổi theo định dạng của chính website đó.

Các liên kết chi tiết bắt đầu bằng dấu gạch chéo nên chưa đủ tên miền. Hàm trích xuất sẽ ghép chúng với URL trang danh mục. Không nên nối chuỗi thủ công vì đường dẫn tương đối có thể chứa thư mục cha, tham số hoặc địa chỉ đã đầy đủ.

Kiểm tra parser trước khi nối mạng

Anh em có thể nạp trực tiếp products.html từ ổ đĩa vào hàm parseProducts ở phần tiếp theo. Bước này không sử dụng proxy và không đo tốc độ mạng. Mục tiêu là xác nhận hai bản ghi được đọc đúng, giá là số và liên kết sau khi ghép vẫn đúng đường dẫn.

Trong lần thử của bài, kiểm tra parser dùng một URL gốc do máy chủ thử cấp. Kết quả nhận hai sản phẩm, với giá lần lượt 790000 và 350000. Đây là kết quả kiểm tra trên fixture do người viết tạo, không phải số liệu hiệu năng hay tỷ lệ thành công trên website thương mại.

import { readFile } from 'node:fs/promises';
import { parseProducts } from './scrape.mjs';
 
const html = await readFile('products.html', 'utf8');
const items = parseProducts(html,
  'https://example.test/products');
console.log(JSON.stringify(items, null, 2));

Đặt đoạn kiểm tra trên trong một tệp .mjs khác và chạy sau khi đã tạo scrape.mjs. Khi phần phân tích hoạt động với dữ liệu cố định, anh em mới chuyển sang phép thử có mạng. Thứ tự này giữ nguyên một biến mỗi lần kiểm tra, giúp tránh đoán nguyên nhân từ nhiều thay đổi đồng thời.

Viết bộ trích xuất Cheerio proxy có kiểm tra đầu ra

Một selector trả về chuỗi rỗng thường không làm chương trình dừng. Nếu ghi thẳng kết quả đó vào file, lô crawl có thể trông như đã chạy xong nhưng dữ liệu thiếu hàng loạt. Vì vậy, ví dụ kiểm tra từng trường trước khi chấp nhận bản ghi.

Hàm parseProducts cho từng thẻ sản phẩm

Tạo tệp scrape.mjs rồi dán lần lượt các phần code trong mục này và mục tải trang bên dưới. Đoạn đầu khai báo thư viện và định nghĩa hàm trích xuất. Mỗi phần tử được tìm trong phạm vi thẻ sản phẩm hiện tại để tránh trộn tên của một hàng với giá của hàng khác.

import axios from 'axios';
import { load } from 'cheerio';
import { HttpsProxyAgent } from 'https-proxy-agent';
import { writeFile } from 'node:fs/promises';
import { pathToFileURL } from 'node:url';
 
export function parseProducts(html, pageUrl) {
  const $ = load(html);
  const cards = $('[data-product]');
  if (!cards.length) throw new Error('NO_PRODUCT_CARDS');
  const items = [];
  cards.each((_, el) => {
    const card = $(el);
    const id = card.attr('data-product')?.trim();
    const name = card.find('.name').text().trim();
    const rawPrice = card.find('.price').attr('data-value');
    const price = Number(rawPrice);
    const href = card.find('a.details').attr('href');
    if (!id || !name || !rawPrice?.trim() ||
        !Number.isFinite(price) || price < 0 || !href) {
      throw new Error('INVALID_PRODUCT');
    }
    const url = new URL(href, pageUrl);
    if (!['http:', 'https:'].includes(url.protocol)) {
      throw new Error('INVALID_PRODUCT_URL');
    }
    items.push({ id, name, price, url: url.href });
  });
  return items;
}

Thuộc tính data-product được dùng làm mã bản ghi, nhưng ví dụ chưa kiểm tra trùng mã giữa các thẻ. Khi lưu nhiều trang vào cùng kho dữ liệu, anh em cần quy tắc định danh rõ ràng và cơ chế ghi đè hoặc loại trùng. Đừng mặc định tên sản phẩm là khóa vì nhiều mẫu có thể dùng chung một tên.

Phần kiểm tra rawPrice được đặt trước khi chấp nhận kết quả Number. Lý do là chuỗi trống có thể bị chuyển thành số 0, khiến một trường giá bị thiếu trông giống sản phẩm miễn phí. Chương trình cũng từ chối số âm và giá trị không hữu hạn để lỗi định dạng không đi tiếp vào file kết quả.

Đọc selector trong đúng ngữ cảnh

Biểu thức $('[data-product]') chọn toàn bộ thẻ có mã sản phẩm. Sau đó card.find('.name') chỉ tìm tên bên trong một thẻ đang xử lý. Nếu dùng $('.name').text() cho cả trang, nội dung của nhiều tên có thể bị ghép lại thành một chuỗi.

Anh em có thể đọc thêm cú pháp chọn phần tử của Cheerio khi cần kết hợp thuộc tính, cấu trúc cha con hoặc nhiều điều kiện. Với website thường đổi class sau mỗi lần build, hãy ưu tiên dấu mốc ổn định nếu chúng có sẵn, rồi kiểm thử trên nhiều trang đại diện.

Ví dụ chủ động dừng khi một thẻ không hợp lệ. Trong lô lớn, anh em có thể tách thành danh sách bản ghi đúng và danh sách lỗi, nhưng phải giữ lý do bị loại. Cách chọn phụ thuộc yêu cầu dữ liệu: báo cáo tài chính, kiểm tra tồn kho và nghiên cứu nội dung không có cùng mức chấp nhận thiếu trường.

Một điều kiện nhỏ khác là URL đầu ra chỉ được dùng HTTP hoặc HTTPS. Mẫu này lưu liên kết để tham chiếu, chưa tự truy cập trang chi tiết. Nếu sau đó thêm bước theo liên kết, cần kiểm tra cả miền được phép truy cập trước khi đưa URL vào hàng đợi.

Từ HTML đến bản ghi hợp lệ

Tải trang HTTPS trong Cheerio proxy và lưu JSON

Sau khi phần trích xuất hoạt động độc lập, anh em nối nó với HTTP client. Agent sẽ xử lý kết nối tới proxy, Axios nhận phản hồi từ trang đích và parseProducts kiểm tra dữ liệu. Mỗi lớp trả lỗi riêng để chương trình không lưu nhầm trang thông báo thành danh mục sản phẩm.

Cấu hình request và giới hạn phản hồi

Dán tiếp hàm crawl dưới đây vào scrape.mjs. Mẫu chỉ nhận TARGET_URL dùng HTTPS để giữ phạm vi dễ kiểm tra. Nó khai báo adapter HTTP của Axios, gắn agent vào httpsAgent và tắt cơ chế proxy riêng của Axios nhằm tránh chồng hai cách cấu hình trong cùng request.

export async function crawl(target, proxyUrl) {
  const destination = new URL(target);
  const proxy = new URL(proxyUrl);
  if (destination.protocol !== 'https:') {
    throw new Error('TARGET_MUST_USE_HTTPS');
  }
  if (!['http:', 'https:'].includes(proxy.protocol)) {
    throw new Error('HTTP_PROXY_REQUIRED');
  }
  const agent = new HttpsProxyAgent(proxy);
  try {
    const response = await axios.get(destination.href, {
      adapter: 'http', httpsAgent: agent, proxy: false,
      timeout: 15000, signal: AbortSignal.timeout(20000),
      maxRedirects: 0, maxContentLength: 2 * 1024 * 1024,
      responseType: 'text',
      headers: { Accept: 'text/html',
        'User-Agent': 'CheerioLearningExample/1.0' },
    });
    const type = String(response.headers['content-type'] || '');
    if (!type.toLowerCase().includes('text/html')) {
      throw new Error('EXPECTED_HTML');
    }
    return parseProducts(response.data, destination.href);
  } finally {
    agent.destroy();
  }
}

Tên HttpsProxyAgent nói tới tuyến kết nối cho đích HTTPS, không có nghĩa URL proxy bắt buộc phải bắt đầu bằng https://. Proxy HTTP hỗ trợ CONNECT vẫn có thể chuyển tiếp kết nối TLS tới đích HTTPS. Cơ chế này được mô tả trong README chính thức của https-proxy-agent.

Timeout 15 giây và tín hiệu hủy sau 20 giây là giá trị minh họa, cần điều chỉnh theo hệ thống thật. Giới hạn nội dung 2 MiB ngăn ví dụ vô tình nhận một phản hồi quá lớn. Nó cũng có thể từ chối một trang danh mục hợp lệ nhưng dài, nên phải đo kích thước trước khi chọn mức dùng lâu dài.

maxRedirects bằng 0 giúp anh em nhìn thấy phản hồi chuyển hướng thay vì tự đi tiếp tới trang đăng nhập hoặc một tên miền khác. Nếu website có chuyển hướng hợp lệ, hãy duyệt và cấu hình URL đích rõ ràng. Đừng kết luận proxy hỏng chỉ vì trang đang trả 301 hoặc 302.

Phần kiểm tra Content-Type yêu cầu text/html. Điều này phù hợp dữ liệu mẫu, không phải bộ nhận diện mọi loại tài liệu. Nếu nguồn là JSON hoặc XHTML, cần xử lý theo đúng kiểu phản hồi. Các tùy chọn giới hạn request có thể tra tại tài liệu cấu hình Axios.

Lưu file và báo lỗi ngắn gọn

Dán phần cuối vào cùng tệp. Chương trình lấy cấu hình từ biến môi trường, gọi crawl rồi mới ghi products.json. Nếu tải trang hoặc kiểm tra dữ liệu thất bại, code trả trạng thái lỗi cho tiến trình gọi thay vì ghi một danh sách rỗng và coi đó là thành công.

async function main() {
  const { TARGET_URL, PROXY_URL } = process.env;
  if (!TARGET_URL || !PROXY_URL) {
    throw new Error('MISSING_TARGET_OR_PROXY');
  }
  const items = await crawl(TARGET_URL, PROXY_URL);
  await writeFile('products.json',
    JSON.stringify(items, null, 2) + '\n', 'utf8');
  console.log(JSON.stringify({ count: items.length,
    file: 'products.json' }));
}
 
if (process.argv[1] &&
    import.meta.url === pathToFileURL(process.argv[1]).href) {
  main().catch(error => {
    console.error(JSON.stringify({
      error: error.code || error.message,
      status: error.response?.status ?? null,
    }));
    process.exitCode = 1;
  });
}

Thông báo thành công chỉ chứa số bản ghi và tên file, còn thông báo lỗi chứa mã lỗi cùng HTTP status nếu có. Ví dụ tránh in cả đối tượng Axios vì cấu hình request có thể chứa thông tin xác thực. Với hệ thống chạy lịch, anh em có thể đưa các trường này vào log có cấu trúc để theo dõi từng lần chạy.

Hàm crawl tạo agent cho một lượt gọi và hủy nó khi xong. Thiết kế này dễ hiểu cho ví dụ đơn lẻ. Nếu thu thập nhiều trang cùng tuyến proxy, hãy cân nhắc quản lý vòng đời agent ở cấp tác vụ để tái sử dụng kết nối; không sao chép mẫu một cách máy móc vào hàng nghìn request đồng thời.

Kiểm chứng Cheerio proxy bằng kết quả chạy thử

Một bài hướng dẫn cần nêu rõ đã kiểm tra ở đâu và kết luận được đến mức nào. Lần thử này sử dụng máy chủ HTTPS cục bộ cùng proxy HTTP có xác thực trên localhost. Chương trình phải mở đường hầm CONNECT rồi mới nhận HTML từ máy chủ thử.

Kết quả và giới hạn của phép thử

Bộ kiểm tra chạy qua 11 trường hợp vào ngày 22/10/2026. Ngoài việc đọc đủ hai sản phẩm, nó kiểm tra dữ liệu sai, URL không phù hợp, phản hồi chuyển hướng và lỗi xác thực. Một lượt chạy dòng lệnh riêng cũng được dùng để xác nhận products.json được tạo đúng.

Chứng chỉ của máy chủ cục bộ được thêm vào danh sách tin cậy riêng cho tiến trình thử. Không có bước tắt xác minh TLS. Anh em không cần dùng chứng chỉ này khi truy cập website thật có chứng chỉ hợp lệ, và cũng không nên sửa code để chấp nhận mọi chứng chỉ chỉ nhằm làm lỗi biến mất.

Các hàng trong bảng gom nhiều tình huống của bộ kiểm tra, nên không tương ứng một hàng cho mỗi test. Kết quả chứng minh ví dụ chạy được trong điều kiện đã dựng. Nó không đo latency Internet, khả năng xử lý tải lớn hay chất lượng một gói proxy thương mại.

Lần thử chưa sử dụng endpoint thương mại của ProxyVN và chưa kết nối tới danh mục sản phẩm thật. Vì thế, khi đổi sang nhà cung cấp hoặc website khác, anh em vẫn cần kiểm tra cổng, xác thực, khả năng CONNECT và cấu trúc HTML trước khi mở rộng.

Kiểm thử từng lớp xử lý

Chẩn đoán lỗi Cheerio proxy theo từng lớp

Khi một lần chạy thất bại, hãy kiểm tra theo thứ tự tuyến kết nối, trạng thái HTTP, nội dung phản hồi rồi mới tới selector. Đổi proxy ngay khi gặp dữ liệu rỗng dễ làm mất thời gian vì nguyên nhân có thể nằm ở HTML đầu vào hoặc quy tắc trích xuất.

Lỗi 407 và lỗi kết nối

HTTP 407 là tín hiệu cần kiểm tra thông tin xác thực của proxy. Hãy đối chiếu username, password, cổng và cách mã hóa ký tự đặc biệt. Một số dịch vụ còn có điều kiện cho phép IP nguồn; cần kiểm tra theo hướng dẫn của gói đã mua thay vì thêm ngẫu nhiên header vào request.

ECONNREFUSED hoặc timeout không tự chỉ ra một nguyên nhân duy nhất. Có thể sai cổng, dịch vụ dừng hoặc đường mạng chặn kết nối. Hãy xác nhận tuyến proxy bằng một yêu cầu nhỏ trước, sau đó mới thử trang danh mục. Không cần thay selector khi chương trình chưa nhận được HTML.

HTTP 200 nhưng không có thẻ sản phẩm

NO_PRODUCT_CARDS có nghĩa là selector mẫu không tìm thấy thẻ trong HTML nhận được. Trước hết kiểm tra title, kích thước và một đoạn nội dung phản hồi đã loại thông tin nhạy cảm. Đó có thể là trang đăng nhập, thông báo bảo trì, trang kiểm tra truy cập hoặc cấu trúc danh mục mới.

Nếu dữ liệu chỉ xuất hiện sau khi trình duyệt chạy script, Cheerio không tự tạo ra phần DOM đó. Anh em nên xác định nguồn dữ liệu được phép sử dụng hoặc chuyển sang công cụ render phù hợp. Hướng dẫn xử lý selection rỗng của Cheerio giải thích rõ giới hạn không thực thi JavaScript.

Cũng cần kiểm tra chính selector đang dùng. Một thẻ có .product-title sẽ không khớp .name; một trang dùng thuộc tính data-id sẽ không khớp data-product. Giữ một bản HTML đại diện làm fixture giúp anh em sửa selector rồi so sánh kết quả mà không phải gửi lại hàng loạt request.

Với lỗi INVALID_PRODUCT, hãy ghi mã bản ghi và tên trường bị thiếu trong hệ thống thật. Ví dụ tối giản chỉ trả một mã lỗi chung để code dễ theo dõi. Nếu nhiều sản phẩm cùng thiếu giá, đó có thể là thay đổi cấu trúc, trạng thái hết hàng hoặc định dạng tiền tệ chưa được xử lý.

HTTP 429 và lịch thử lại

HTTP 429 cho biết hệ thống đang giới hạn số yêu cầu. Header Retry-After, nếu được gửi kèm, có thể nêu khoảng chờ theo giây hoặc một thời điểm HTTP-date. Ý nghĩa hai dạng này có trong tài liệu HTTP 429 của MDN.

Code mẫu chưa tự thử lại: nó trả lỗi để người vận hành quyết định. Khi thêm retry, anh em cần giới hạn số lần, chờ theo phản hồi và tránh gửi lại đồng loạt. Đổi IP không thay thế cho việc kiểm soát tốc độ vì hạn mức có thể gắn với tài khoản hoặc toàn hệ thống.

Vận hành Cheerio proxy với nhiều trang danh mục

Khi ví dụ một trang đã ổn, bước tiếp theo là kiểm soát toàn bộ lô dữ liệu. Đừng tăng số request chỉ vì máy còn dư CPU. Một hệ thống hữu ích cần giữ dữ liệu nhất quán, biết dừng khi nguồn thay đổi và có khả năng chạy lại phần bị lỗi.

Giới hạn đồng thời và giữ ngữ cảnh

Hãy bắt đầu bằng hàng đợi tuần tự hoặc mức đồng thời nhỏ theo hạn mức được phép. Ghi thời gian phản hồi, HTTP status, số bản ghi hợp lệ và tỷ lệ thiếu trường. Chỉ điều chỉnh tốc độ khi những chỉ số này ổn định, thay vì dùng một con số luồng cố định cho mọi website.

Nếu các trang trong cùng phiên phụ thuộc cookie, code cần bổ sung quản lý cookie rõ ràng. Axios trong ví dụ không duy trì cookie jar qua nhiều lượt gọi. Giữ cùng một proxy cũng không tự giữ trạng thái đăng nhập; hai thành phần phải được quản lý cùng ngữ cảnh khi tác vụ yêu cầu.

Với danh sách nhiều tuyến, anh em nên đọc thêm cách chia proxy pool theo nhiệm vụ crawling. Phần điều phối đó nằm ngoài parser: nó quyết định request nào dùng tuyến nào, còn hàm trích xuất tiếp tục kiểm tra cùng một hợp đồng dữ liệu.

Lưu dữ liệu có thể đối chiếu và chạy lại

Một bản ghi nên giữ thêm URL nguồn và thời điểm thu thập nếu dùng cho theo dõi thay đổi. Thông tin này cho phép phân biệt dữ liệu mới với file cũ khi có lượt chạy thất bại. Với nhiều trang, cần khóa định danh để một sản phẩm xuất hiện ở hai danh mục không bị tính thành hai sản phẩm riêng.

products.json trong ví dụ là file đầu ra đơn giản, bị ghi lại sau mỗi lượt thành công. Nếu xây lịch chạy thật, hãy lưu theo mã tác vụ hoặc dùng bước ghi file tạm rồi đổi tên sau khi kiểm tra. Đồng thời giữ một bản kết quả đã xác nhận để người dùng không nhận nhầm file dở dang.

Khi cần mua proxy, anh em có thể xem các gói dân cư tĩnh hoặc datacenter đang hiển thị trên trang chủ ProxyVN, rồi kiểm tra tuyến HTTP với chính website và mức tải dự kiến. Việc chọn gói cần dựa trên kết quả thử tương thích, không chỉ dựa vào tên thư viện Cheerio.

Kiểm tra trước khi chạy nhiều trang

Checklist Cheerio proxy trước khi triển khai

Trước lần chạy thật, hãy thực hiện lại một lượt nhỏ với cấu hình gần môi trường sử dụng. Một script vừa chạy được trên máy cá nhân chưa thể đại diện cho máy chủ khác, nơi DNS, chứng chỉ, biến môi trường và quyền ghi file có thể khác.

• Đầu vào: xác nhận URL đích, quyền thu thập và HTML phản hồi có trường dữ liệu cần lấy.
• Kết nối: xác nhận giao thức proxy, cổng, xác thực và khả năng mở CONNECT tới đích HTTPS.
• Parser: kiểm tra cả bản ghi đúng, trường thiếu, giá bất thường và URL tương đối.
• Giới hạn: đặt timeout, kích thước phản hồi, số tác vụ đồng thời và chính sách dừng khi gặp lỗi.
• Đầu ra: kiểm tra file JSON, khóa định danh, thời điểm thu thập và số bản ghi hợp lệ.
• Nhật ký: giữ mã lỗi và HTTP status, che thông tin xác thực, không ghi cả cấu hình request.
• Triển khai: thử một nhóm URL đại diện trước khi chuyển sang toàn bộ danh mục.

Nếu một lượt thử thất bại, hãy ghi lại bước đầu tiên không đáp ứng điều kiện. Khi kết nối đã đúng nhưng dữ liệu sai, quay về HTML và hợp đồng đầu ra. Khi parser đã đúng với fixture nhưng request không tới được đích, xử lý tuyến mạng trước. Cách tách lớp này giúp kết quả dễ giải thích và dễ bảo trì.

Cheerio proxy vận hành dễ kiểm soát hơn khi tách tuyến tải HTML khỏi bộ trích xuất và kiểm tra dữ liệu trước khi lưu. Anh em có thể liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để trao đổi loại kết nối cần thử cho dự án Cheerio proxy.