Sai lầm cổ điển khi mở rộng trình phân tích — mua proxy "theo cảm tính": mua 100 IP, khởi động trình phân tích, nhận lệnh cấm sau nửa giờ. Vấn đề không nằm ở số lượng địa chỉ, mà ở chỗ không ai tính toán tải thực tế trên mỗi IP. Chúng ta sẽ phân tích công thức tính toán bể proxy dựa trên RPS (requests per second), độ trễ và giới hạn của trang web mục tiêu — với các con số cụ thể và mã trên Python.
Tại sao tính bể theo số lượng IP là sai lầm
Cách tiếp cận điển hình của người mới trong phân tích: "cần thu thập 50.000 thẻ sản phẩm, vì vậy mua 500 proxy và phân bổ tải". Lógica có vẻ hợp lý, nhưng không tính đến điều chính — các trang như Wildberries và Ozon không cấm theo số lượng yêu cầu tuyệt đối, mà theo cường độ yêu cầu từ một IP trong một khoảng thời gian. Nghĩa là 500 proxy, mỗi cái gửi 20 yêu cầu mỗi giây, sẽ bị cấm ngay lập tức — hệ thống chống bot thấy mẫu giống như DDoS.
Ngược lại, nếu bạn có 50 proxy, nhưng mỗi cái thực hiện 1 yêu cầu trong 5-10 giây với các khoảng dừng ngẫu nhiên, mô phỏng hành vi của con người, bạn có thể phân tích ổn định trong nhiều tuần mà không bị cấm. Số lượng IP không phải là lý do cho sự ổn định, mà là hệ quả của việc tính toán tải đúng cách. Chính vì vậy, công thức phải dựa trên "bao nhiêu RPS cần đạt được và tải an toàn trên một IP là bao nhiêu", chứ không phải "mua bao nhiêu IP".
Một điểm nữa: các loại proxy khác nhau có "sức chịu đựng" khác nhau trên một IP. Proxy trung tâm dữ liệu bị cấm nhanh hơn khi có tần suất yêu cầu cao, vì các subnet của chúng dễ dàng bị nhận diện là hosting. IP cư trú và di động trông giống như người dùng bình thường, và có thể cho phép tần suất cao hơn một chút mà không có nguy cơ bị chặn — nhưng điều này không có nghĩa là có thể bỏ qua hoàn toàn các giới hạn.
Công thức cơ bản tính toán bể proxy
Công thức tính toán số lượng proxy trong bể như sau:
N = (RPS_target × Delay_per_ip) / Concurrency_per_ip
Trong đó:
- N — số lượng proxy cần thiết trong bể;
- RPS_target — tốc độ phân tích mục tiêu (yêu cầu mỗi giây trên toàn hệ thống);
- Delay_per_ip — khoảng dừng an toàn tối thiểu giữa các yêu cầu từ một IP (tính bằng giây);
- Concurrency_per_ip — số lượng luồng song song mà bạn cho phép trên một IP (thường là 1, tối đa 2 cho proxy cư trú).
Logic rất đơn giản: nếu bạn muốn giữ 10 yêu cầu mỗi giây tổng cộng, và khoảng dừng an toàn giữa các yêu cầu từ một IP là 8 giây, thì một IP về mặt vật lý chỉ có thể gửi 1 yêu cầu trong 8 giây, tức là 0.125 RPS. Để đạt được 10 RPS tổng cộng, cần 10 / 0.125 = 80 proxy. Đây chính là phép tính thay thế cho việc đoán "500 IP cho chắc chắn".
Cách tính RPS mục tiêu cho việc phân tích
Trước khi tính toán bể, cần xác định RPS_target — số yêu cầu mỗi giây bạn thực sự cần để thu thập dữ liệu trong thời gian hợp lý. Công thức ở đây ngược lại:
RPS_target = Total_requests / Time_budget_seconds
Ví dụ: cần thu thập 100.000 thẻ sản phẩm từ Wildberries trong 8 giờ (28.800 giây). Nếu mỗi thẻ cần 1 yêu cầu, RPS_target = 100.000 / 28.800 ≈ 3.47 yêu cầu mỗi giây. Điều này không nhiều như có vẻ ban đầu — nhiều người đánh giá quá cao tốc độ cần thiết và mua số lượng proxy dư thừa.
Nếu nhiệm vụ bao gồm nhiều loại yêu cầu (ví dụ, trước tiên lấy danh sách danh mục, sau đó là thẻ sản phẩm, sau đó là đánh giá), hãy tính RPS cho từng giai đoạn riêng biệt — chúng có thể diễn ra song song với các bể proxy khác nhau, và tải tổng cộng trên nền tảng sẽ được phân bổ qua các endpoint khác nhau.
Giới hạn trên một IP: bao nhiêu yêu cầu mỗi phút là an toàn
Delay_per_ip — tham số quan trọng nhất trong công thức, và cần xác định một cách thực nghiệm cho từng trang web. Các chỉ số chung, dựa trên thực tiễn phân tích các thị trường:
| Nền tảng | Khoảng dừng an toàn giữa các yêu cầu từ 1 IP | Tối đa yêu cầu/phút từ 1 IP |
|---|---|---|
| Wildberries (API thẻ sản phẩm) | 4-6 giây | 10-15 |
| Ozon (trang sản phẩm) | 5-8 giây | 8-12 |
| Avito (tin rao) | 6-10 giây | 6-10 |
| Yandex.Market | 5-7 giây | 8-12 |
Những con số này là điểm khởi đầu, không phải là quy tắc cứng nhắc. Bắt đầu với các giá trị bảo thủ (giới hạn trên của khoảng dừng), theo dõi tỷ lệ lỗi 429 và 403, và từ từ giảm khoảng dừng nếu lệnh cấm không tăng. Tăng đột ngột RPS mà không thử nghiệm dần dần — là cách phổ biến nhất để làm hỏng toàn bộ bể proxy trong một ngày.
Các tính toán thực tế: Wildberries, Ozon, Avito
Chúng ta sẽ phân tích ba kịch bản thực tế với tính toán đầy đủ theo công thức.
Kịch bản 1: giám sát giá trên Wildberries. Cần cập nhật giá của 20.000 sản phẩm mỗi 2 giờ. RPS_target = 20.000 / (2 × 3600) ≈ 2.78 RPS. Với khoảng dừng 5 giây trên 1 IP và Concurrency = 1: N = (2.78 × 5) / 1 ≈ 14 proxy. Để dự phòng trong trường hợp bị cấm một phần IP, nên lấy bể với hệ số 1.5-2x, tức là 21-28 proxy.
Kịch bản 2: thu thập danh mục Ozon một lần. 500.000 thẻ trong 24 giờ. RPS_target = 500.000 / 86.400 ≈ 5.79 RPS. Với khoảng dừng 6 giây: N = (5.79 × 6) / 1 ≈ 35 proxy. Với dự phòng — 50-60 proxy.
Kịch bản 3: giám sát đối thủ trên Avito theo thời gian thực. 5.000 tin rao, cập nhật mỗi 15 phút. RPS_target = 5.000 / 900 ≈ 5.56 RPS. Với khoảng dừng 8 giây: N = (5.56 × 8) / 1 ≈ 45 proxy. Ở đây cần lưu ý rằng Avito thường xuyên phát hiện các subnet trung tâm dữ liệu, vì vậy cho nhiệm vụ này, hợp lý hơn là ngay từ đầu sử dụng IP cư trú hoặc di động.
Proxy cư trú, di động và trung tâm dữ liệu trong công thức
Loại proxy ảnh hưởng trực tiếp đến Delay_per_ip và do đó đến N cuối cùng trong công thức. Proxy trung tâm dữ liệu rẻ hơn và nhanh hơn, nhưng yêu cầu khoảng dừng dài hơn giữa các yêu cầu và thường xuyên bị cấm khi có tần suất cao — thực tế, để đạt được 5 RPS, bạn có thể cần 2-3 lần số IP trung tâm dữ liệu so với IP cư trú.
| Loại proxy | Delay_per_ip trung bình | Khi nào sử dụng |
|---|---|---|
| Proxy trung tâm dữ liệu | 8-15 giây | API mở, trang web không có hệ thống chống bot nghiêm ngặt |
| Proxy cư trú | 4-8 giây | Wildberries, Ozon, Avito và các thị trường khác có hệ thống chống bot |
| Proxy di động | 3-6 giây | Các bảo vệ mạnh mẽ nhất, mạng xã hội, API di động |
Để phân tích các thị trường như Wildberries và Ozon, lựa chọn tối ưu thường là proxy cư trú — chúng cân bằng giữa giá cả và sự ổn định, cho phép giữ khoảng dừng ngắn hơn mà không làm tăng đột ngột tỷ lệ bị cấm. Proxy trung tâm dữ liệu chỉ nên được xem xét cho các nền tảng không có hệ thống chống bot mạnh mẽ hoặc cho các nhiệm vụ một lần với RPS không cao.
Triển khai bể trên Python: mã với vòng lặp
Dưới đây là triển khai đơn giản của bể proxy với kiểm soát tần suất yêu cầu cho mỗi IP. Logic: mỗi proxy lưu trữ thời gian sử dụng cuối cùng, và bộ lập lịch chỉ chọn những IP mà đã đủ thời gian từ yêu cầu cuối cùng.
import time
import random
from dataclasses import dataclass, field
from typing import List, Optional
@dataclass
class ProxyNode:
address: str
delay_per_ip: float # khoảng dừng an toàn tính bằng giây
last_used: float = field(default=0.0)
class ProxyPool:
def __init__(self, proxies: List[str], delay_per_ip: float):
self.nodes = [ProxyNode(address=p, delay_per_ip=delay_per_ip) for p in proxies]
def get_available_proxy(self) -> Optional[ProxyNode]:
now = time.time()
available = [
node for node in self.nodes
if now - node.last_used >= node.delay_per_ip
]
if not available:
return None
# chọn ngẫu nhiên từ những cái có sẵn, để tránh mẫu hàng đợi
node = random.choice(available)
node.last_used = now
return node
def size(self) -> int:
return len(self.nodes)
def calculate_pool_size(rps_target: float, delay_per_ip: float, concurrency: int = 1) -> int:
"""Công thức: N = (RPS_target * Delay_per_ip) / Concurrency_per_ip"""
return max(1, int((rps_target * delay_per_ip) / concurrency))
# Ví dụ sử dụng
rps_target = 5.79 # tính từ khối lượng nhiệm vụ và thời gian
delay_per_ip = 6.0 # khoảng dừng an toàn cho Ozon
n_proxies = calculate_pool_size(rps_target, delay_per_ip)
print(f"Cần proxy trong bể: {n_proxies}") # ~35, với dự phòng 50-60
Trong trình phân tích thực tế, logic này cần được bổ sung với hàng đợi nhiệm vụ (ví dụ, qua asyncio hoặc multiprocessing), để các worker chờ đợi sự xuất hiện của proxy trống, thay vì kết thúc với lỗi khi không có proxy. Cũng nên thêm backoff theo cấp số nhân khi nhận được 429/403 — điều này sẽ tự động tăng khoảng dừng cho IP cụ thể khi có dấu hiệu bị chặn.
Giám sát và điều chỉnh động bể
Tính toán tĩnh theo công thức — là điểm khởi đầu, không phải là giải pháp cuối cùng. Trong thực tế, cần theo dõi ba chỉ số chính:
- Tỷ lệ thành công — tỷ lệ yêu cầu thành công (mã 200) so với tổng số. Giảm xuống dưới 90-95% báo hiệu rằng Delay_per_ip cần được tăng lên hoặc thêm proxy vào bể;
- Tỷ lệ bị cấm — tỷ lệ proxy đã cho thấy dấu hiệu bị chặn (captcha, 403, chuyển hướng đến biểu mẫu xác minh) trong giờ qua;
- RPS thực tế — tốc độ thực tế xử lý yêu cầu, có thể khác với tính toán do thời gian chờ và thử lại.
Quy tắc thực tế: nếu tỷ lệ bị cấm vượt quá 5-7% mỗi giờ, hãy tăng Delay_per_ip lên 20-30% và tính toán lại N theo công thức. Nếu tỷ lệ thành công ổn định trên 98% trong vài giờ, có thể từ từ giảm khoảng dừng và giảm kích thước bể — đây là cách tiết kiệm ngân sách cho proxy mà không mất đi sự ổn định.
Một thực tiễn tốt là ghi lại nhật ký cho từng IP riêng biệt: thời gian yêu cầu thành công cuối cùng, số lượng lỗi liên tiếp, thời gian phản hồi trung bình. Điều này cho phép tự động loại bỏ các proxy "hỏng" khỏi vòng lặp trong 30-60 phút thay vì tiếp tục gửi yêu cầu qua chúng và nhận captcha ở mỗi bước.
Những sai lầm thường gặp khi tính toán bể proxy
Ngay cả khi biết công thức, dễ dàng mắc sai lầm trong các chi tiết tính toán. Dưới đây là danh sách các sai lầm điển hình:
- Bỏ qua dự phòng cho các lệnh cấm. Ngay cả khi tính toán hoàn hảo, 5-10% proxy sẽ tạm thời không khả dụng do bị chặn hoặc các vấn đề mạng. Luôn thêm hệ số 1.3-2x vào N cơ bản;
- Delay_per_ip giống nhau cho tất cả các endpoint. Trang danh mục và trang thẻ sản phẩm có thể có các giới hạn khác nhau — hãy tính toán riêng;
- Concurrency lớn hơn 1 mà không thử nghiệm. Các yêu cầu song song từ một IP sẽ làm tăng nguy cơ bị cấm, đặc biệt là trên proxy cư trú — bắt đầu với Concurrency = 1;
- Thiếu vòng lặp User-Agent và tiêu đề. Ngay cả khi bể proxy được tính toán đúng, nó sẽ không cứu được nếu tất cả các yêu cầu đều đến từ cùng một dấu vân tay trình duyệt;
- Khoảng dừng cố định không có jitter. Khoảng thời gian hoàn toàn giống nhau giữa các yêu cầu (ví dụ, chính xác 5.0 giây) — là một mẫu dễ dàng bị hệ thống chống bot nhận diện. Thêm độ lệch ngẫu nhiên ±20-30%.
Kết luận
Công thức N = (RPS_target × Delay_per_ip) / Concurrency_per_ip biến đổi việc tính toán bể proxy từ đoán mò thành một nhiệm vụ kỹ thuật với các con số cụ thể. Đầu tiên, xác định tốc độ phân tích mục tiêu dựa trên khối lượng dữ liệu và thời gian, sau đó tìm kiếm khoảng dừng an toàn cho từng nền tảng một cách thực nghiệm, và chỉ sau đó tính toán số lượng IP cần thiết — với dự phòng 30-100% cho các lệnh cấm và sự cố.
Cách tiếp cận này tiết kiệm ngân sách: thay vì mua một số lượng IP dư thừa "cho chắc chắn", bạn chỉ trả tiền cho số lượng proxy cần thiết để đạt được RPS mục tiêu mà không có nguy cơ bị chặn. Đối với việc phân tích các thị trường và các trang web bảo vệ khác, chúng tôi khuyên bạn nên bắt đầu với proxy cư trú — chúng cung cấp sự cân bằng tốt nhất giữa sự ổn định và chi phí khi làm việc với các hệ thống chống bot của Wildberries, Ozon và Avito.