Danh sách giá của nhà cung cấp proxy được thiết kế sao cho việc so sánh các nhà cung cấp trở nên đơn giản: một gigabyte có giá 1 đô la, một cái khác là 8 đô la — tính ra, chênh lệch là tám lần. Trong thực tế, đội ngũ đã mua gigabyte với giá một đô la thường xuyên trả nhiều hơn cho dữ liệu thu thập được so với đội ngũ đã mua với giá tám đô la. Nguyên nhân không phải do marketing hay các khoản phí ẩn: giá cho một gigabyte đơn giản không phải là đơn vị đo lường cho nhiệm vụ của bạn. Bạn không mua lưu lượng — bạn mua các bản ghi được trích xuất thành công, và giữa hai đại lượng này có một chuỗi các yếu tố nhân mà mỗi dự án có riêng của nó.
Hóa đơn không đến từ những gì bạn đã tính toán
Cảnh tượng điển hình: bạn dự định thu thập một triệu thẻ sản phẩm, dự kiến mỗi trang 200 KB, nhận được 200 GB và ngân sách khoảng một nghìn rưỡi đô la. Sau một tháng trong tài khoản cá nhân — 900 GB và hóa đơn gấp ba lần dự toán. Không ai lừa dối: ba điều đã thay đổi mà không có trong tính toán.
Khoảng cách giữa giá cả và hóa đơn luôn được phân tích thành những thành phần giống nhau. Hãy phân tích chúng một cách riêng biệt — sau đó công thức sẽ tự khớp lại.
Ba yếu tố giữa giá cả và hóa đơn
1. Trang thực sự nặng bao nhiêu
Đánh giá "200 KB" được lấy từ đầu và liên quan đến HTML trần. Trọng lượng thực tế phụ thuộc vào cách bạn lấy trang. Phản hồi HTML thô của một cửa hàng hiện đại — thường là hàng trăm kilobyte. Còn một trang đã được render hoàn toàn trong trình duyệt headless với tất cả các script, font chữ, hình ảnh và phân tích có thể nặng từ 2–5 MB. Sự khác biệt giữa hai cách lấy cùng một dữ liệu — là một bậc độ lớn, và nó hoàn toàn ảnh hưởng đến lưu lượng của bạn.
Các tính toán trong ngành thường sử dụng khoảng 1–3 MB cho việc thu thập không tối ưu và 100–300 KB cho việc tối ưu hóa. Giữa hai chế độ này — không phải là "tiết kiệm một chút", mà là sự khác biệt gấp mười lần trên cùng một dự án.
2. Tỷ lệ phản hồi nào thực sự có giá trị
Yếu tố thứ hai — tỷ lệ thành công, tỷ lệ yêu cầu trả về nội dung có giá trị. Captcha thay vì trang, 403, khung trống không có dữ liệu, chuyển hướng đến trang tạm — tất cả đều là lưu lượng đã trả tiền, nhưng không mang lại bất kỳ bản ghi nào.
Phép toán đơn giản và không thương tiếc: số lượng yêu cầu = bản ghi cần thiết ÷ tỷ lệ thành công. Với 95% thành công, để có một triệu bản ghi cần 1,05 triệu yêu cầu. Với 70% — đã là 1,43 triệu. Với 60% — 1,67 triệu. Nghĩa là sự giảm sút từ 95% xuống 60% tự nó đã thêm vào hóa đơn gần 60%, trong khi giá gigabyte hoàn toàn không thay đổi.
3. Retry, thời gian chờ và lưu lượng phụ
Trên tất cả những điều này là lưu lượng phụ của chính lớp bao bọc. Ở đây, sự chênh lệch giữa một stack trưởng thành và một stack được xây dựng vội vàng là rất lớn: với các nền tảng quản lý đã được tối ưu hóa, tỷ lệ chuyển tiếp tiêu tốn khoảng 0,1–3% trên tổng lưu lượng, trong khi với pipeline Scrapy tự viết — là 5–15%, và tỷ lệ này tăng lên cùng với quy mô. Logic retry hung hãn, liên tục tấn công một miền bị chặn năm lần liên tiếp, dễ dàng biến những phần trăm này thành hàng chục phần trăm.
Chỉ số không nói dối
Hãy tổng hợp mọi thứ thành một đại lượng. Cần tính không phải là đô la cho một gigabyte, mà là chi phí cho một nghìn bản ghi được trích xuất thành công:
- Giá cho 1000 bản ghi = (trọng lượng trung bình của phản hồi trong GB ÷ tỷ lệ thành công) × (1 + tỷ lệ retry) × giá cho GB × 1000
Giá trị của công thức này là nó làm cho những đề nghị không thể so sánh trở nên có thể so sánh. Một pool rẻ với tỷ lệ bị chặn 40% và một pool đắt với tỷ lệ bị chặn 5% cuối cùng cũng nằm trên cùng một trục. Đáng chú ý là trong năm qua, chính các nhà cung cấp cũng đã đến với chỉ số này: trong các tài liệu ngành, cụm từ "giá chia cho tỷ lệ thành công" ngày càng xuất hiện nhiều hơn, thay vì chỉ là giá thô cho gigabyte.
Cách điều này thể hiện bằng tiền
Giả sử một triệu bản ghi, trang trung bình 500 KB và lưu lượng cư trú với giá 8 đô la/GB — giữa thị trường điển hình. Chỉ thay đổi tỷ lệ thành công:
- 95% thành công — 1,05 triệu yêu cầu, khoảng 525 GB, khoảng 4.200 đô la
- 70% thành công — 1,43 triệu yêu cầu, khoảng 715 GB, khoảng 5.720 đô la
- 60% thành công — 1,67 triệu yêu cầu, khoảng 835 GB, khoảng 6.680 đô la
Sự chênh lệch — gần 2.500 đô la trên cùng một mức giá. Và bây giờ hãy so sánh hai đề nghị, mà trong danh sách giá trông như trời và đất. Nhà cung cấp A: 2 đô la/GB, nhưng giữ tỷ lệ thành công 55% cho mục tiêu của bạn. Nhà cung cấp B: 6 đô la/GB và 92% thành công. Với cùng 500 KB và một triệu bản ghi, A cho ra khoảng 910 GB và 1.820 đô la, trong khi B cho ra khoảng 545 GB và 3.270 đô la. Ở đây A thực sự rẻ hơn, và đó là một kết quả công bằng: với sự chênh lệch lớn về giá, tỷ lệ thành công thấp không phải lúc nào cũng làm mất đi lợi ích.
Nhưng thêm vào A tỷ lệ retry 15% so với 3% của B, thêm vào render headless, mà được sử dụng chính vì pool rẻ thường trả về trang tạm thay vì nội dung — và trọng lượng trang của A tăng lên 1,5 MB so với 500 KB của B. Tính toán lại: A — khoảng 3,1 TB và 6.200 đô la, B — khoảng 560 GB và 3.370 đô la. Thứ tự đã bị đảo ngược. Đó chính là lý do tại sao câu hỏi "ai có gigabyte rẻ hơn" không có ý nghĩa độc lập: câu trả lời phụ thuộc vào mục tiêu của bạn, stack của bạn và tỷ lệ bị chặn của bạn.
Tại sao các API scraping được tính toán khác — và cách so sánh chúng
Một khó khăn riêng là một phần thị trường không bán gigabyte. Các API scraping và các công cụ unblock web tính phí theo yêu cầu, và tính phí theo độ phức tạp. Mức giá năm 2026 cho 1000 trang như sau:
- HTML đơn giản: ScrapeOps khoảng 0,19 đô la, ScraperAPI khoảng 0,49 đô la, Scrape.do khoảng 0,58 đô la, ScrapingBee khoảng 0,66 đô la, Bright Data khoảng 1,00 đô la
- Với render JS (thường là 5 tín dụng thay vì một): ScrapeOps khoảng 0,95 đô la, Scrape.do khoảng 2,90 đô la, ScrapingBee khoảng 3,30 đô la, ScraperAPI khoảng 4,90 đô la, Bright Data khoảng 5,00 đô la
- Các trang web dưới bảo vệ chống bot (10–25 tín dụng): ScrapeOps khoảng 1,90 đô la, Scrape.do khoảng 4,45 đô la, ScraperAPI khoảng 5,96 đô la, ScrapingBee khoảng 6,60 đô la, Bright Data trong khoảng 8–15 đô la
Lưu ý sự chênh lệch bên trong một nhà cung cấp: một trang đơn giản và một trang dưới bảo vệ của ScraperAPI khác nhau đến mười hai lần. Mức phí "theo yêu cầu" có vẻ dễ dự đoán hơn gigabyte cho đến khi mục tiêu chuyển từ loại đầu tiên sang loại thứ ba — và điều này xảy ra mà không có sự tham gia của bạn, theo quyết định của chủ sở hữu trang web.
Điều này được đưa về một trục chung bằng công thức: chi phí cho yêu cầu ÷ tỷ lệ thành công × 1000. Sau đó, đề nghị "3,30 đô la cho 1000 trang JS" và đề nghị "6 đô la cho một gigabyte lưu lượng cư trú" cuối cùng có thể được đặt cạnh nhau. Phân tích sâu hơn về các phương pháp này — API chính thức, bộ dữ liệu sẵn có hoặc trình phân tích của riêng bạn — chúng tôi đã thảo luận riêng; ở đây chỉ quan trọng là khả năng so sánh của chúng về mặt tài chính.
Đo lường trong một buổi tối
Công thức không có giá trị nếu không có số liệu của riêng bạn, và tin tốt là việc thu thập chúng chỉ mất vài giờ. Một thử nghiệm với 1000 yêu cầu trên các URL thực tế của bạn sẽ cung cấp tất cả những gì cần thiết.
- Chọn một mẫu đại diện cho mục tiêu — không phải trang chính, mà là những thẻ, danh mục và kết quả mà bạn sẽ thu thập trong sản xuất. Tỷ lệ thành công trên trang chính không dự đoán được gì.
- Ghi lại bốn bộ đếm riêng biệt: phản hồi hợp lệ có dữ liệu, lỗi HTTP, captcha và thử thách, "hai trăm trống" — mã 200 không có nội dung cần thiết. Danh mục cuối cùng là mánh khóe nhất: về mặt hình thức, đây là thành công, nhưng thực tế — là rác đã trả tiền.
- Ghi lại khối lượng lưu lượng thực tế từ thống kê của nhà cung cấp, không phải từ ước tính của bạn. Sự khác biệt giữa trọng lượng tính toán và trọng lượng thực tế của trang — thường là phát hiện đầu tiên của thử nghiệm này.
- Tính toán tỷ lệ retry như một dòng riêng, không hòa trộn chúng vào tổng số yêu cầu.
- Thực hiện lại trên nhà cung cấp thứ hai trong cùng một ngày. Tỷ lệ thành công thay đổi cùng với tâm trạng của hệ thống chống bot, và không thể so sánh các phép đo cách nhau một tuần.
Nếu thử nghiệm cho thấy tỷ lệ thành công thấp, đừng vội vàng thay đổi nhà cung cấp: trước tiên hãy hiểu nguyên nhân. Phân tích các nguồn vấn đề điển hình được tập hợp trong tài liệu về cách chẩn đoán tỷ lệ thành công thấp của proxy, và việc kiểm soát định kỳ các chỉ số tương tự nên được thực hiện thường xuyên. Thường thì vấn đề nằm ở tiêu đề, thời gian hoặc dấu vân tay TLS của khách hàng, chứ không phải chất lượng IP.
Bốn đòn bẩy có thể làm thay đổi con số mạnh mẽ hơn cả giảm giá
Khi chỉ số đã được tính toán, bạn sẽ thấy nơi nào nó nhạy cảm nhất. Giảm giá 10% trên giá cả — là đòn bẩy yếu nhất có sẵn.
Trọng lượng phản hồi. Lợi ích nhanh nhất. Chỉ lấy những gì cần thiết làm giảm lưu lượng từ 2–10 lần. Nếu trình duyệt headless là bắt buộc, hãy chặn ở mức độ chặn yêu cầu hình ảnh, font chữ, phương tiện và script bên ngoài — nội dung không bị ảnh hưởng, nhưng khối lượng giảm đi nhiều lần. Bật nén và yêu cầu có điều kiện theo ETag: một trang không thay đổi từ lần quét trước phải trả cho bạn phản hồi 304, chứ không phải megabyte.
Tỷ lệ thành công. Mỗi mười điểm phần trăm thành công trong khoảng 60–95% — là hàng chục phần trăm hóa đơn. Ở đây không phải là tiền, mà là kỹ thuật: dấu vân tay khách hàng chính xác, tốc độ hợp lý, loại IP đúng cho mục tiêu cụ thể.
Hỗn hợp loại proxy. Chạy toàn bộ lưu lượng qua pool cư trú — là sai lầm phổ biến và đắt nhất. Một phần đáng kể các mục tiêu có thể được phục vụ tốt bởi proxy trung tâm dữ liệu, rẻ hơn một bậc; địa chỉ cư trú chỉ nên được sử dụng cho những gì thực sự cần thiết. Định tuyến theo mục tiêu, không phải theo thói quen, cắt giảm chi phí proxy từ 60–70%.
Kỷ luật về retry. Độ trễ theo cấp số nhân, giới hạn số lần thử, từ chối lặp lại trên các mã không thể chữa trị bằng lặp lại. Sự khác biệt giữa 3% và 15% lưu lượng phụ — là sự khác biệt giữa một lớp bao bọc cẩn thận và sự thiếu vắng nó. Khía cạnh thực tiễn của vấn đề đã được phân tích trong tài liệu về tối ưu hóa chi phí lưu lượng qua proxy.
Những gì còn lại ngoài lưu lượng
Bức tranh toàn cảnh về chi phí rộng hơn hóa đơn proxy, và điều này cần được nhớ khi lựa chọn giữa "tự thu thập" và "mua sẵn". Đối với một dự án quy mô một triệu trang mỗi tháng, các ước tính ngành cho giải pháp tự lưu trữ như sau: lưu lượng cư trú 500–1500 đô la, thời gian kỹ sư 1000–2000 đô la, cơ sở hạ tầng 300–500 đô la. Tổng cộng 2000–4400 đô la mỗi tháng — và đó là trước khi viết logic kinh doanh thực tế. Với mức lương kỹ sư khoảng 100 đô la mỗi giờ, vài ngày dành để sửa chữa các bộ chọn bị hỏng có thể tốn kém hơn hóa đơn hàng tháng cho proxy.
Điều này không phải là lập luận chống lại việc tự thu thập — mà là lập luận để tính thời gian kỹ sư như một dòng ngân sách tương tự như gigabyte. Mô hình định giá cũng cần được chọn một cách có ý thức: đối với các phiên ổn định dài, việc thanh toán cho IP riêng thường có lợi hơn so với theo megabyte.
Tóm tắt
Giá cho một gigabyte không phải là giá của dữ liệu, mà là giá của một trong bốn yếu tố nhân. So sánh các nhà cung cấp dựa trên nó — giống như chọn xe hơi dựa trên giá một lít xăng, mà không hỏi về mức tiêu thụ. Đơn vị làm việc để so sánh là một: chi phí cho một nghìn bản ghi được trích xuất thành công trên các mục tiêu của bạn, với trọng lượng phản hồi của bạn, tỷ lệ thành công của bạn và các lần retry của bạn.
Hãy tính toán nó trong thử nghiệm với một nghìn yêu cầu, trước khi đăng ký gói hàng năm. Thường thì sẽ phát hiện ra rằng đề nghị rẻ nhất trong danh sách giá lại tốn kém hơn tất cả các đề nghị khác — và rằng khoản tiết kiệm lớn nhất không nằm trong việc thương lượng giảm giá, mà trong hai chục dòng mã tắt tải hình ảnh.
```