Giới hạn lưu lượng truy cập cho việc lấy dữ liệu: không được sử dụng hết gói proxy hàng tháng.

Người bán khởi động trình thu thập dữ liệu giá của đối thủ vào ban đêm, và sáng hôm sau nhận được thông báo: lưu lượng đã hết, gói đã cạn 90%. Tình huống quen thuộc? Thường thì không phải do trình thu thập dữ liệu mà là do thiếu giới hạn ở mức proxy và kịch bản. Trong bài viết này, chúng ta sẽ phân tích cách mà lưu lượng "rò rỉ" một cách vô ích, và cách đặt bảo vệ để gói proxy cư trú hoặc di động hàng tháng đủ cho đến cuối thời gian tính toán.

Tại sao lưu lượng hết trong một đêm

Việc thu thập dữ liệu từ Wildberries, Ozon hoặc Avito có vẻ như là một nhiệm vụ đơn giản: gửi yêu cầu — nhận JSON với giá. Nhưng trên thực tế, lưu lượng không chỉ được sử dụng cho dữ liệu hữu ích. Các nguồn chính gây ra sự tiêu tốn:

Tải hình ảnh và phương tiện. Nếu trình thu thập mở toàn bộ trang sản phẩm qua trình duyệt (thay vì thực hiện yêu cầu trực tiếp đến API), nó tự động tải hình ảnh, video, banner — đó là hàng chục megabyte cho một thẻ sản phẩm.
Các yêu cầu lặp lại do captcha và chặn IP. Thị trường nhận diện bot, đưa ra captcha hoặc chặn IP tạm thời, kịch bản thực hiện yêu cầu lặp lại — lưu lượng bị tiêu tốn vô ích, và dữ liệu không đến.
Thiếu bộ nhớ đệm cho các yêu cầu. Nếu không có logic "đã thu thập trong giờ này — không lặp lại", kịch bản có thể hỏi cùng một thẻ sản phẩm nhiều lần trong một đêm.
Các luồng song song không có giới hạn. Khởi động 50-100 luồng cùng lúc có vẻ như tăng tốc độ làm việc, nhưng lưu lượng bị tiêu tốn nhanh hơn nhiều so với dự kiến, và một phần yêu cầu bị chặn.
Chọn sai loại proxy. Proxy cư trú và di động thường được tính phí theo khối lượng lưu lượng (GB), khác với proxy trung tâm dữ liệu, nơi thường tính phí theo số lượng IP hoặc thời gian thuê. Nếu trình thu thập được cấu hình cho nhóm cư trú mà không kiểm soát — giới hạn sẽ hết nhanh chóng.

Sự kết hợp của những yếu tố này dẫn đến việc kịch bản, được tính toán cho một tháng làm việc, tiêu tốn gói lưu lượng trong một phiên thu thập dữ liệu ban đêm cho 10-20 nghìn thẻ sản phẩm.

Cách tính lưu lượng ở các loại proxy khác nhau

Trước khi đặt giới hạn, quan trọng là hiểu rõ bạn đang trả tiền cho cái gì. Các loại proxy khác nhau tính toán tiêu thụ khác nhau, và điều này ảnh hưởng trực tiếp đến chiến lược tiết kiệm.

Loại proxy	Tính phí	Rủi ro tiêu tốn quá mức	Khi nào áp dụng
Proxy cư trú	Theo khối lượng lưu lượng (GB)	Cao nếu không có giới hạn	Thu thập dữ liệu với việc vượt qua bảo vệ chống bot của thị trường
Proxy di động	Theo khối lượng lưu lượng hoặc theo thời gian	Cao, lưu lượng đắt hơn	Thu thập dữ liệu từ các phiên bản di động của trang web, vượt qua các chặn nghiêm ngặt
Proxy trung tâm dữ liệu	Theo số lượng IP / thời gian thuê	Thấp, lưu lượng thường không giới hạn	Thu thập dữ liệu hàng loạt mà không có bảo vệ chống bot nghiêm ngặt

Nếu bạn đang thu thập dữ liệu từ Wildberries hoặc Ozon, nơi có bảo vệ chống bot hoạt động tích cực, proxy cư trú hoặc IP di động gần như luôn cần thiết — địa chỉ trung tâm dữ liệu bị chặn nhanh chóng. Nhưng chính vì tính phí theo lưu lượng ở đây, đặc biệt quan trọng là đặt giới hạn trước.

Cần bao nhiêu lưu lượng thực sự cho việc thu thập dữ liệu

Để đặt một giới hạn hợp lý, cần dựa vào các con số thực tế, chứ không phải cảm giác. Các chi phí ước tính trên thực tế:

Yêu cầu đến API của thẻ sản phẩm (JSON, không có hình ảnh): 5-30 KB cho mỗi thẻ. Trên 10.000 thẻ — khoảng 50-300 MB.
Tải trang sản phẩm qua trình duyệt headless với hình ảnh: 1-3 MB cho mỗi thẻ. Trên cùng 10.000 thẻ — 10-30 GB.
Giám sát giá mỗi giờ cho 1000 SKU: với các yêu cầu nhẹ — khoảng 1-5 GB mỗi ngày, với việc tải đầy đủ trang — 50-100 GB mỗi ngày.

Sự khác biệt giữa "thu thập nhẹ" và "thu thập nặng" là hàng chục lần. Do đó, bước đầu tiên để tiết kiệm lưu lượng — tắt tải hình ảnh, video và các kịch bản bên ngoài ở những nơi có thể, và làm việc trực tiếp với API của thị trường hoặc phiên bản di động của trang web, nhẹ hơn phiên bản desktop.

Giới hạn trong các trình duyệt chống phát hiện và quản lý proxy

Đối với những người thu thập dữ liệu qua trình duyệt chống phát hiện (ví dụ, Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) hoặc quản lý proxy riêng, cách đơn giản nhất để giới hạn tiêu thụ — là thiết lập giới hạn ở mức hồ sơ và tài khoản của nhà cung cấp proxy.

Đăng nhập vào tài khoản cá nhân của nhà cung cấp proxy và tìm phần quản lý lưu lượng hoặc giới hạn cho các người dùng con/cổng.
Tạo một tài khoản con hoặc cổng riêng cho việc thu thập dữ liệu — không sử dụng cùng một nhóm proxy mà bạn dùng cho việc nuôi tài khoản trên Instagram hoặc TikTok. Phân chia theo nhiệm vụ ngay lập tức cho thấy lưu lượng đi đâu.
Đặt giới hạn lưu lượng hàng ngày hoặc hàng giờ trên tài khoản con này — ví dụ, 5 GB mỗi ngày thay vì tiêu tốn toàn bộ gói hàng tháng trong một phiên.
Trong trình duyệt chống phát hiện, tắt tự động tải hình ảnh cho các hồ sơ, được sử dụng chỉ để thu thập dữ liệu, không phải để xem trực quan các trang.
Cài đặt lịch khởi động hồ sơ sao cho việc thu thập dữ liệu không diễn ra trong một phiên dài, mà là các khoảng thời gian ngắn với các khoảng dừng — điều này giảm rủi ro bị chặn và cho thời gian theo dõi tiêu thụ lưu lượng giữa các lần khởi động.

Cách tiếp cận này đặc biệt quan trọng đối với các đại lý và freelancer, những người thực hiện thu thập dữ liệu từ nhiều thị trường cùng lúc: nếu không phân chia theo tài khoản con, rất khó để hiểu dự án nào đã "tiêu tốn" lưu lượng.

Giới hạn lưu lượng ở mức kịch bản và API

Nếu trình thu thập được viết tự tay bằng Python hoặc Node.js, có thể và cần thiết tích hợp giới hạn ngay vào mã — điều này cung cấp kiểm soát chính xác hơn so với cài đặt giao diện của nhà cung cấp proxy.

Ví dụ về một bộ đếm lưu lượng đơn giản bằng Python với việc sử dụng requests:

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # giới hạn 5 GB mỗi ngày
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("Giới hạn lưu lượng hàng ngày đã hết, việc thu thập dữ liệu đã dừng lại")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# ví dụ về cách gọi
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("Lưu lượng đã sử dụng:", round(used_bytes / 1024 / 1024, 2), "MB")

Logic rất đơn giản: kịch bản tính toán khối lượng của mỗi phản hồi bằng byte và dừng lại ngay khi đạt đến giới hạn đã đặt. Điều này bảo vệ khỏi tình huống, khi do lỗi trong vòng lặp hoặc lặp lại vô hạn yêu cầu, kịch bản "tiêu tốn" gói lưu lượng hàng tháng trong vài giờ.

Ngoài ra, nên thêm:

Độ trễ theo cấp số nhân khi có lỗi (retry với backoff) — thay vì lặp lại ngay lập tức yêu cầu khi gặp captcha hoặc bị chặn, kịch bản sẽ chờ một khoảng thời gian tăng dần (5 giây, 15 giây, 60 giây), điều này giảm số lượng yêu cầu vô ích.
Giới hạn số lượng luồng song song — ví dụ, không quá 10-20 kết nối đồng thời qua nhóm proxy, để không kích thích việc bị chặn và không tiêu tốn lưu lượng vô ích.
Tắt tải tài nguyên trong trình duyệt headless — nếu việc thu thập dữ liệu diễn ra qua Selenium hoặc Puppeteer, trong cài đặt trình duyệt có thể chặn tải hình ảnh, phông chữ và CSS, chỉ để lại các phản hồi HTML/JSON.

Giám sát tiêu thụ theo thời gian thực

Giới hạn mà không có giám sát hoạt động kém hơn, vì bạn chỉ biết về vấn đề sau khi dừng kịch bản. Để kiểm soát tiêu thụ ngay lập tức:

Bật thông báo trong tài khoản cá nhân của nhà cung cấp proxy về việc đạt 50%, 80% và 100% gói lưu lượng hàng tháng — hầu hết các dịch vụ hỗ trợ các cảnh báo như vậy qua email hoặc Telegram.
Ghi lại một nhật ký đơn giản trong chính kịch bản: ghi lại vào tệp hoặc cơ sở dữ liệu khối lượng lưu lượng theo giờ, để thấy các đỉnh tiêu thụ và nhanh chóng tìm nguồn gốc của vấn đề.
Phân chia lưu lượng theo nhiệm vụ thông qua các tài khoản con hoặc nhãn riêng biệt — riêng cho việc thu thập dữ liệu Wildberries, riêng cho Ozon, riêng cho Avito. Điều này đơn giản hóa việc phân tích, dự án nào tiêu tốn nhiều nhất.
So sánh tiêu thụ với khối lượng dữ liệu dự kiến: nếu 10.000 thẻ tiêu tốn 20 GB thay vì 300 MB dự kiến, có nghĩa là có tài nguyên thừa được tải hoặc có các yêu cầu lặp lại.

Danh sách kiểm tra kiểm soát ngân sách lưu lượng

Tắt tự động tải hình ảnh và video trên các hồ sơ cho việc thu thập dữ liệu
Sử dụng yêu cầu trực tiếp đến API của thị trường ở những nơi có thể, thay vì tải đầy đủ trang
Đặt giới hạn lưu lượng hàng ngày hoặc hàng giờ trên tài khoản con của proxy
Phân chia việc thu thập dữ liệu thành các nhóm proxy riêng biệt theo dự án (Wildberries, Ozon, Avito)
Trong kịch bản, thực hiện bộ đếm lưu lượng với việc dừng lại khi đạt đến giới hạn
Cài đặt độ trễ và backoff khi gặp captcha hoặc bị chặn thay vì lặp lại ngay lập tức
Giới hạn số lượng luồng song song trong việc thu thập dữ liệu
Bật thông báo về tiêu thụ lưu lượng từ nhà cung cấp proxy
Ghi lại nhật ký tiêu thụ lưu lượng theo giờ để phân tích các bất thường

Những sai lầm thường gặp của người mới

Trên thực tế, phần lớn các gói lưu lượng "bị cháy" được giải thích bởi một số lỗi điển hình:

Khởi động thu thập dữ liệu "trong đêm không có giám sát" mà không có giới hạn. Kịch bản hoạt động 8-10 giờ liên tục, và nếu ở đâu đó có vòng lặp yêu cầu lặp lại, lưu lượng sẽ được tiêu tốn liên tục cho đến sáng.
Chỉ một nhóm proxy chung cho tất cả các nhiệm vụ. Nuôi tài khoản trên Instagram, thử nghiệm quảng cáo trên Facebook Ads và thu thập dữ liệu từ Ozon sử dụng cùng một lưu lượng — không thể hiểu cái gì thực sự tiêu tốn nó.
Bỏ qua captcha. Thay vì giảm tần suất yêu cầu khi có dấu hiệu đầu tiên của captcha, kịch bản tiếp tục tấn công trang web với cùng một cường độ, tiêu tốn lưu lượng cho các phản hồi vô ích với mã lỗi.
Chọn proxy cư trú ở nơi mà proxy trung tâm dữ liệu đã đủ. Nếu thị trường không chặn IP trung tâm dữ liệu một cách nghiêm ngặt, việc trả thêm cho lưu lượng của nhóm cư trú không được biện minh — cho các mục tiêu ít được bảo vệ hơn, proxy trung tâm dữ liệu với mô hình tính phí khác sẽ phù hợp.
Thiếu chạy thử nghiệm. Trước khi khởi động việc thu thập dữ liệu đầy đủ cho hàng nghìn thẻ, nên chạy kịch bản trên 50-100 thẻ và đo lưu lượng thực tế, để ngoại suy cho toàn bộ khối lượng.

Kết luận

Lưu lượng cho việc thu thập dữ liệu "bị cháy" không phải do khối lượng dữ liệu, mà do thiếu kiểm soát: hình ảnh thừa, yêu cầu lặp lại khi bị chặn, các luồng song song không có giới hạn và một nhóm proxy chung cho tất cả các nhiệm vụ. Giải pháp — phân chia lưu lượng theo dự án, đặt giới hạn hàng ngày ở mức tài khoản proxy, tích hợp bộ đếm tiêu thụ vào chính kịch bản và thiết lập giám sát với thông báo trước khi gói thực sự hết.

Nếu bạn đang thu thập dữ liệu từ các thị trường có bảo vệ chống bot hoạt động như Wildberries hoặc Ozon, chúng tôi khuyên bạn nên sử dụng proxy cư trú để vượt qua các chặn và thêm vào IP di động cho các kịch bản nhạy cảm nhất với bảo vệ chống bot — nhưng trong cả hai trường hợp, hãy chắc chắn đặt giới hạn lưu lượng trước, để gói hàng tháng không bị tiêu tốn trong một phiên đêm.