1 Proxy Chạy Được Bao Nhiêu Luồng Và Cách Tính Tải Đúng

1 proxy chạy được bao nhiêu luồng là câu hỏi không có một con số duy nhất, vì giới hạn thật nằm ở website đích chứ không ở bản thân proxy. Nhưng có công thức ước lượng và cách đo để ra con số phù hợp với từng tác vụ. Bài viết này ProxyVN trình bày cách tính số IP theo tải, giới hạn kết nối đồng thời và cách đo thực tế.

1 proxy chạy được bao nhiêu luồng: vì sao không có con số cố định

Trước khi tính, cần tách rõ vài khái niệm hay bị gộp làm một, và xác định giới hạn thật đến từ đâu.

Luồng, request đồng thời và phiên là ba thứ khác nhau

Luồng là một đơn vị thực thi trong chương trình của anh em. Request đồng thời là số kết nối đang mở cùng lúc qua proxy. Phiên là một chuỗi thao tác gắn với một IP trong một khoảng thời gian. Một luồng có thể mở nhiều request nối tiếp; nhiều luồng có thể dùng chung một phiên. Khi hỏi một proxy chịu bao nhiêu luồng, thứ cần quan tâm là số request đồng thời và số request mỗi giờ mà website đích chấp nhận.

Giới hạn thật nằm ở website đích, không ở proxy

Một proxy tốt có thể chuyển tiếp rất nhiều kết nối. Cái chặn anh em lại là cơ chế đếm tần suất theo IP của website. Vượt ngưỡng đó thì proxy vẫn hoạt động nhưng request trả về 403 hoặc 429. Vì vậy con số luồng hợp lý phụ thuộc vào từng target, không phải một hằng số dán cho mọi trường hợp. Bao nhiêu request mỗi IP thì bắt đầu dính 429 được bàn cụ thể trong bài lỗi 429 khi mua proxy.

Đồng thời và song song

Theo bài của IPRoyal về đồng thời và song song, đồng thời là quản lý nhiều tác vụ luân phiên tiến triển, còn song song là chạy thật sự cùng lúc trên nhiều nhân. Việc gọi request là tác vụ chờ nhập xuất, nên hợp với mô hình đồng thời: một luồng hoặc một vòng lặp bất đồng bộ có thể giữ hàng chục kết nối mở mà không cần nhiều nhân CPU. Trong Python, thư viện bất đồng bộ hợp cho tác vụ chờ mạng, còn đa tiến trình mới vượt được giới hạn khóa thông dịch cho tác vụ nặng CPU.

Ý nghĩa thực tế: khi anh em nói chạy 200 luồng, phần lớn thời gian mỗi luồng chỉ đang ngồi chờ máy chủ trả lời. Số kết nối mở cùng lúc mới là thứ proxy và website nhìn thấy, chứ không phải số luồng trong mã nguồn. Một chương trình bất đồng bộ mở 200 kết nối gây tải lên IP đích tương đương 200 luồng đồng bộ, dù chỉ chạy trên một nhân.

Vì sao mỗi loại proxy có trần khác nhau

Trần luồng hữu ích của một IP phụ thuộc loại proxy. IP datacenter thường có đường truyền khỏe nên chịu được nhiều kết nối kỹ thuật, nhưng bị website siết sớm vì dễ nhận diện. IP dân cư đi qua đường truyền gia đình nên băng thông hẹp hơn và độ trễ cao hơn, giữ ít kết nối cùng lúc là hợp lý. IP di động chịu được nhiều phiên tài khoản nhờ CGNAT nhưng tốc độ dao động theo sóng. Cùng một công thức, con số cuối khác nhau theo loại IP anh em dùng.

Công thức tính 1 proxy chạy được bao nhiêu luồng cho việc quét

Với thu thập dữ liệu quy mô lớn, cách làm phổ biến là tính ngược từ tổng khối lượng cần quét ra số IP, thay vì hỏi một IP gánh được bao nhiêu. Cách chia và xoay tập proxy cho một job quét lớn được hướng dẫn trong bài web scraping proxy là gì.

Ngưỡng tham chiếu 500 request mỗi giờ cho một IP

Hướng dẫn dùng proxy để quét web của Hartley Brody lấy mốc 500 request mỗi giờ cho một IP làm quy tắc ngón tay cái, ước theo lượng truy cập của một người dùng thật. Đây là mốc thận trọng cho nhiều site phổ thông; site lỏng hơn có thể chịu nhiều hơn, site chặt hơn thì ít hơn.

Chia tổng tải cho ngưỡng để ra số IP

Công thức: lấy số request mỗi giờ mà hệ thống của anh em phát ra, chia cho 500. Ví dụ cần nạp 100.000 URL mỗi giờ thì cần 100.000 chia 500, bằng 200 IP. Đó là mức tối thiểu để không liên tục chạm trần.

Nhân hệ số an toàn 2 đến 3 lần

Cùng ví dụ trên, Hartley Brody khuyên nhân thêm 2 đến 3 lần để có khoảng đệm, tức 400 đến 600 IP thay vì 200. Khoảng đệm này hấp thụ các IP tạm bị chặn, các dải phản hồi chậm và những lúc tải dồn cục bộ. Nguồn proxy datacenter và dân cư số lượng lớn cho job quét có tại trang mua proxy.

Hiệu chỉnh lại ngưỡng 500 theo từng site

Con số 500 chỉ là điểm khởi đầu. Cách hiệu chỉnh: chạy thử một IP đơn ở nhiều mức, 200, 400, 800 request mỗi giờ, ghi mức nào bắt đầu xuất hiện 429. Lấy mức an toàn cuối cùng thay cho 500 rồi tính lại số IP. Với site tin tức mở, ngưỡng thực có thể lên tới vài nghìn; với sàn thương mại điện tử lớn có tường chống bot mạnh, ngưỡng có khi chỉ vài chục request mỗi giờ cho một IP datacenter.

Cũng cần biết hệ thống của mình phát ra bao nhiêu request mỗi giờ. Đếm số URL trong hàng đợi, chia cho số giờ dự kiến chạy xong. Nếu chưa có số này thì mọi phép tính phía sau đều là đoán mò.

# Uoc luong so proxy IP can cho mot tac vu quet
NGUONG_GIO = 500       # request an toan moi gio cho mot IP (moc tham chieu)
HE_SO_AN_TOAN = 3      # nhan them de khong lien tuc cham tran

def so_proxy_can(tong_request_moi_gio):
    toi_thieu = tong_request_moi_gio / NGUONG_GIO
    return round(toi_thieu * HE_SO_AN_TOAN)

print(so_proxy_can(100000))   # 600
print(so_proxy_can(20000))    # 120
print(so_proxy_can(5000))     # 30

1 proxy chạy được bao nhiêu luồng đồng thời

Số request mỗi giờ là một mặt. Mặt còn lại là bao nhiêu kết nối được mở cùng một lúc qua một IP. Hai giới hạn này độc lập nhau.

Số kết nối đồng thời trên một IP

Phần lớn máy chủ web tự giới hạn số kết nối đồng thời từ một địa chỉ. Vì vậy dù chương trình của anh em đặt số luồng rất cao, thực tế site đích mới là bên quyết định. Với nhiều target phổ thông, giữ 2 đến 5 request đồng thời cho mỗi tên miền là mức lịch sự, kèm khoảng nghỉ vài trăm mili giây giữa các lần gọi để không dồn cục.

Ví dụ giới hạn 20 luồng cho mỗi tài khoản

Nhà cung cấp cũng đặt trần riêng. Tài liệu của Oxylabs về giới hạn số kết nối đồng thời nêu mức 20 luồng đồng thời cho mỗi người dùng khi dùng IP datacenter miễn phí. Trần này tính theo tài khoản, không theo từng IP. Luôn đọc điều khoản của gói proxy để biết con số áp cho mình.

Chia luồng theo số IP, không dồn vào một địa chỉ

Nếu có 100 luồng và 50 IP, phân bổ để mỗi IP gánh khoảng 2 luồng, thay vì để 40 luồng dồn vào một địa chỉ còn các IP khác nằm không. Bộ điều phối nên theo vòng tròn và có ghi nhận IP nào đang bận để tránh tái sử dụng trong khoảng thời gian ngắn. Cách dựng bộ điều phối chia đều luồng cho pool IP được nói trong bài proxy pool là gì.

Câu hỏi đúng không phải một proxy chịu được bao nhiêu luồng, mà website đích cho một địa chỉ gửi bao nhiêu request trước khi nghi ngờ.

Đồng thời khác song song

1 proxy chạy được bao nhiêu luồng khi nuôi tài khoản

Khi mục tiêu là nuôi tài khoản chứ không phải quét, câu hỏi đổi thành: một IP gánh được bao nhiêu tài khoản mà không bị nối chúng với nhau.

Không có đáp án cố định, phụ thuộc cường độ dùng

Bài của IPRoyal về số tài khoản trên mỗi proxy di động nói thẳng là không có một con số chung cho mọi trường hợp. Ước lượng theo cường độ: dùng nhẹ như đọc và lướt thì mật độ cao hơn; dùng vừa như đăng bài đều và tự động hóa nhẹ thì khoảng 2 đến 3 tài khoản mỗi IP; tự động hóa nặng thì 1 tài khoản mỗi IP trong một phiên.

Bảng số tài khoản gợi ý theo nền tảng

Các nền tảng khắt khe với việc trùng IP ở mức khác nhau. Bảng dưới là mức gợi ý để tham khảo, luôn cần điều chỉnh theo mức độ tự động hóa của anh em.

Vì sao proxy di động chịu nhiều tài khoản hơn

Proxy di động nằm sau lớp CGNAT của nhà mạng, nghĩa là hàng trăm tới hàng nghìn người dùng thật cùng chia một IP công cộng. Website ngại chặn một IP như vậy vì sẽ ảnh hưởng người vô can, nên ngưỡng khoan dung cao hơn IP dân cư hay datacenter vốn thường là địa chỉ riêng. Vì sao proxy di động chịu được nhiều tài khoản hơn và khi nào nên trả thêm tiền được nói trong bài proxy di động là gì.

IP chỉ là một trong nhiều yếu tố

Số tài khoản một IP gánh được không chỉ do IP quyết định. Các yếu tố cùng trọng số:

• Tuổi và mức làm nóng tài khoản: tài khoản già, đã hoạt động đều thì bền hơn tài khoản mới lập.

• Tách biệt hành vi: mỗi tài khoản một lịch hoạt động riêng, không thao tác đồng loạt cùng giờ.

• Dấu vân tay trình duyệt riêng: mỗi tài khoản một profile fingerprint khác nhau.

• Nhất quán vị trí: IP, múi giờ và ngôn ngữ của một tài khoản không đổi vùng liên tục.

• Cường độ tự động hóa: càng nhiều thao tác máy trên một tài khoản, càng nên giảm số tài khoản mỗi IP.

Số tài khoản mỗi IP theo loại proxy

Rate limiting, throttling và mã 429

Hiểu cách website điều tiết lưu lượng giúp anh em chọn số luồng không chạm ngưỡng, và phản ứng đúng khi chạm.

Chặn cứng và làm chậm khác nhau

Theo giải thích của Decodo về rate throttling, giới hạn tần suất áp một trần cứng và từ chối phần vượt, còn điều tiết thì hoãn hoặc xếp hàng phần vượt thay vì từ chối thẳng. Một ví dụ trong bài là chỉ cho 100 request mỗi phút cho một IP; vượt mức đó, request bị xếp hàng hoặc trì hoãn cho vừa ngưỡng.

Hình dung trần tần suất như một cái xô

Nhiều hệ thống đếm tần suất hoạt động như một cái xô chứa lượt: mỗi request lấy đi một lượt, xô được rót lại đều theo thời gian, ví dụ mỗi giây thêm một lượt. Khi xô cạn, request phải chờ. Cách hình dung này lý giải vì sao gửi 100 request dồn trong một giây thì bị chặn, nhưng cũng 100 request đó rải đều trong một phút thì lọt: tốc độ tức thời mới là thứ chạm trần, không phải tổng số.

Đọc header Retry-After và lùi thời gian chờ

Khi nhận mã 429, phản hồi thường kèm header Retry-After cho biết nên chờ bao lâu. Tôn trọng con số đó. Nếu không có, dùng lùi thời gian chờ theo cấp số nhân cộng một lượng ngẫu nhiên, đặt trần cho thời gian chờ. Đoạn dưới là ví dụ triển khai chung.

import time, random
import requests

def gui(url, proxies, lan_thu=5):
    for i in range(lan_thu):
        r = requests.get(url, proxies=proxies, timeout=20)
        if r.status_code == 429:
            cho = r.headers.get("Retry-After")
            cho = float(cho) if cho else min(2 ** i + random.random(), 60)
            time.sleep(cho)
            continue
        return r
    return None

Mã 429 và header Retry-After

Đo thực tế 1 proxy chạy được bao nhiêu luồng

Công thức cho điểm khởi đầu. Con số cuối cùng chỉ ra được khi chạy thử đúng target và đọc phản hồi.

Tăng luồng dần và theo dõi mã trạng thái

Bắt đầu ở mức thấp, ví dụ 2 luồng cho một IP, chạy vài trăm request, ghi tỉ lệ mã 200. Tăng lên 4, rồi 8, rồi 16. Ở mỗi bậc, giữ nguyên vài phút để phản hồi kịp thể hiện. Khi tỉ lệ lỗi bắt đầu leo, anh em đã tới gần điểm gãy. Quy trình đo tốc độ và độ ổn định của một proxy được hướng dẫn trong bài benchmark proxy.

import concurrent.futures as cf
import requests

def thu_muc(url, proxies, so_luong):
    ok = 0
    tong = so_luong * 4
    with cf.ThreadPoolExecutor(max_workers=so_luong) as ex:
        futs = [ex.submit(requests.get, url, proxies=proxies, timeout=20)
                for _ in range(tong)]
        for f in cf.as_completed(futs):
            try:
                if f.result().status_code == 200:
                    ok += 1
            except Exception:
                pass
    return ok / tong

for n in (2, 4, 8, 16, 24):
    ti_le = thu_muc("https://example.com", proxies, n)
    print(n, "luong ->", round(ti_le * 100), "% thanh cong")

Ghi tỉ lệ thành công và thời gian phản hồi

Không chỉ nhìn mã trạng thái. Thời gian phản hồi tăng đều khi thêm luồng là dấu hiệu proxy hoặc site đang phải xếp hàng request của anh em. Điểm mà thời gian phản hồi vọt lên thường tới trước điểm mà mã lỗi xuất hiện.

Xác định điểm gãy rồi lùi lại một bậc

Giả sử 16 luồng cho tỉ lệ thành công 98% nhưng 24 luồng tụt còn 80%. Chọn mức vận hành là 16, thậm chí 12 để có biên. Chạy sát điểm gãy không đáng, vì chỉ cần site siết nhẹ là toàn bộ tác vụ hỏng theo.

Lặp lại phép đo này mỗi khi đổi target hoặc khi tỉ lệ lỗi tăng bất thường. Website thay đổi ngưỡng theo mùa cao điểm và theo đợt nâng cấp tường chống bot, nên con số tốt của tháng trước chưa chắc còn đúng tháng này.

Lỗi khi ước lượng 1 proxy chạy được bao nhiêu luồng

Vài nhầm lẫn phổ biến khiến con số ước lượng lệch xa thực tế.

Nhầm băng thông với số luồng

Băng thông đo lượng dữ liệu truyền qua, tính bằng megabit mỗi giây. Số luồng đo số kết nối song song. Một proxy băng thông lớn vẫn có thể bị site đích chặn ở mức vài luồng nếu vượt ngưỡng tần suất. Hai đại lượng này không quy đổi cho nhau.

Bỏ qua độ trễ giữa các request

Cùng một số luồng, thêm khoảng nghỉ 2 đến 5 giây giữa các request làm giảm mạnh số request mỗi giờ trên một IP, và nhờ đó một IP gánh được nhiều luồng hơn mà vẫn dưới ngưỡng. Nhịp quan trọng ngang số lượng.

Dùng một con số cho mọi website

Bài của IPRoyal về số proxy cần cho một tác vụ nhắc rằng nhu cầu phụ thuộc loại việc: quét dữ liệu và nghiên cứu thị trường thì càng nhiều IP càng tốt, còn vượt chặn vùng để duyệt riêng tư thì một IP đúng vị trí là đủ. Con số đo được ở site này không bê nguyên sang site khác được.

Checklist rút gọn

• Tính số IP tối thiểu bằng tổng request mỗi giờ chia 500.

• Nhân hệ số an toàn 2 đến 3 lần để có khoảng đệm.

• Giữ 2 đến 5 request đồng thời cho mỗi tên miền, thêm độ trễ giữa các lần gọi.

• Kiểm tra trần luồng theo tài khoản trong điều khoản gói proxy.

• Chạy thử tăng luồng dần, tìm điểm gãy, chọn mức vận hành thấp hơn một bậc.

Tăng luồng dần để tìm điểm gãy

Tóm lại, 1 proxy chạy được bao nhiêu luồng tùy vào website đích và loại tác vụ. Với quét dữ liệu, tính số IP bằng cách chia tổng tải cho ngưỡng 500 request mỗi giờ rồi nhân hệ số an toàn; với nuôi tài khoản, giới hạn số tài khoản mỗi IP theo cường độ dùng. Cuối cùng vẫn phải đo thực tế. Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam tư vấn anh em chọn số lượng và loại proxy khớp với khối lượng luồng cần chạy.