Proxy bị chậm: 7 nguyên nhân và cách tăng tốc bằng Python

Proxy bị chậm là vấn đề quen thuộc của anh em làm scraping, chạy tool tự động hay gọi API số lượng lớn. Một proxy chậm hơn vài trăm mili giây nghe có vẻ không đáng kể, nhưng nhân với hàng chục nghìn request mỗi ngày thì có thể kéo dài thời gian chạy thêm nhiều giờ, gây timeout và làm dữ liệu thu về bị thiếu. Trong hướng dẫn này, ProxyVN cùng anh em đo tốc độ đúng cách, xác định điểm nghẽn và tối ưu mã Python. Mục tiêu là cải thiện hiệu suất dựa trên số liệu, thay vì đổi IP hoặc tăng số luồng theo cảm tính.

Proxy bị chậm do đâu: hiểu tuyến đi của một request

Trước khi sửa, cần hiểu request đi qua những chặng nào. Một request qua proxy đi theo tuyến: máy khách tới proxy, proxy tới website, website trả về proxy, rồi proxy trả về máy khách. Mỗi chặng mạng và mỗi bước xử lý ở giữa đều có thể cộng thêm thời gian.

Proxy hoạt động bị chậm

Tổng thời gian của một request thường gồm các phần: phân giải tên miền, thiết lập kết nối TCP tới proxy, bắt tay TLS với website đích, thời gian website xử lý, thời gian truyền dữ liệu về và thời gian proxy chuyển tiếp. Khi proxy bị chậm, anh em cần biết phần nào đang chiếm nhiều thời gian nhất thì mới sửa đúng chỗ.

Luôn đo kết nối trực tiếp trước

Quy tắc quan trọng nhất: luôn đo kết nối trực tiếp trước khi kết luận proxy chậm. Nếu không có số liệu nền, anh em không thể biết độ trễ đến từ proxy, từ website mục tiêu hay từ chính máy đang chạy chương trình. Nhiều trường hợp anh em đổi liên tục ba bốn nhà cung cấp proxy, rồi mới phát hiện website mục tiêu vốn đã phản hồi chậm ngay cả khi truy cập trực tiếp.

Những chỉ số cần theo dõi

Thay vì chỉ nhìn tốc độ trung bình, hãy theo dõi bốn chỉ số: trung vị, phân vị 95, tỷ lệ thành công và loại lỗi. Trung vị cho biết trải nghiệm thường gặp. Phân vị 95, hay p95, cho biết 5% request chậm nhất mất bao lâu. Một proxy có trung vị 400 ms nhưng p95 tới 5 giây sẽ gây nhiều phiền toái hơn một proxy có trung vị 700 ms nhưng p95 chỉ 1 giây, vì những request chậm bất thường mới là thứ gây timeout và làm treo luồng xử lý.

7 nguyên nhân khiến proxy bị chậm

Dưới đây là bảy điểm cần kiểm tra theo thứ tự từ dễ tới khó. Phần lớn trường hợp proxy bị chậm rơi vào một trong ba nguyên nhân đầu tiên.

1. Máy chủ proxy quá xa website mục tiêu

Khoảng cách địa lý làm tăng thời gian khứ hồi của gói tin, hay RTT. Mỗi lần bắt tay TCP và TLS cần nhiều lượt khứ hồi, nên proxy đặt xa website mục tiêu sẽ cộng dồn độ trễ rất nhanh. Ví dụ, anh em ở Việt Nam dùng proxy Mỹ để truy cập một website đặt máy chủ tại Singapore, gói tin phải đi vòng qua Thái Bình Dương hai lần.

Khoảng cách địa lý làm tăng độ trễ proxy

Trong một phép thử minh họa, 1.000 request tới cùng một website mất trung bình 180 ms qua proxy đặt gần máy chủ và 520 ms qua proxy ở khu vực xa hơn. Chênh lệch 340 ms mỗi request tương đương thêm 340 giây nếu chạy tuần tự, và còn nhiều hơn khi tính cả request lỗi phải chạy lại.

Cách xử lý: chọn IP gần website mục tiêu nhất có thể, trừ khi anh em bắt buộc phải dùng IP ở một quốc gia cụ thể để xem nội dung theo khu vực. Với proxy dân cư, nên thử theo từng khu vực vì hai IP cùng quốc gia vẫn có thể đi qua các tuyến mạng khác nhau.

2. Giao thức chưa phù hợp

HTTP proxy phù hợp với phần lớn nhu cầu gọi API và scraping web. SOCKS5 linh hoạt hơn vì hỗ trợ mọi loại lưu lượng TCP, nhưng hiệu suất còn phụ thuộc vào cách nhà cung cấp triển khai, phương thức xác thực và định tuyến.

Với thư viện Requests của Python, có một chi tiết hay bị bỏ qua: tiền tố socks5 phân giải tên miền ở máy khách, còn socks5h chuyển việc phân giải tên miền sang proxy. Chi tiết này được ghi trong tài liệu proxy của Requests. Nếu DNS ở máy khách chậm hoặc trả về IP không tối ưu cho vị trí của proxy, dùng socks5h có thể nhanh hơn đáng kể. Để dùng SOCKS với Requests, cần cài thêm gói hỗ trợ:

python -m pip install requests
python -m pip install "requests[socks]"

Hãy đo thử từng giao thức trên đúng website mục tiêu, thay vì mặc định một loại luôn nhanh hơn loại còn lại.

3. Proxy dùng chung bị quá tải

Proxy dùng chung phục vụ nhiều người cùng lúc. Khi băng thông, CPU hoặc số kết nối đồng thời của máy chủ proxy chạm ngưỡng, tốc độ dao động mạnh và có thể xuất hiện lỗi Connection reset by peer. Anh em không kiểm soát được người dùng chung đang chạy gì, nên hiệu năng có thể tốt buổi sáng và tệ buổi tối.

Dấu hiệu dễ nhận biết gồm:

• Thời gian phản hồi tăng gấp đôi trở lên vào giờ cao điểm.
• Số request timeout tăng ngay sau khi nâng số luồng.
• Tốc độ đầu phiên tốt nhưng giảm dần theo thời gian chạy.
• IP thường xuyên trả về lỗi 429, 502, 503 hoặc 504.

Cách xử lý: phân tải trên một nhóm IP, bắt đầu với 5 đến 10 request đồng thời cho mỗi proxy rồi điều chỉnh dần theo số liệu. Tác vụ tải cao và chạy liên tục nên cân nhắc IP riêng để không phụ thuộc vào người khác. Khi thấy nhiều lỗi 503, bài lỗi 503 Service Unavailable giải thích cách phân biệt lỗi do proxy và lỗi do website đích.

4. Timeout và retry cấu hình chưa đúng

Timeout quá dài khiến chương trình giữ một proxy lỗi quá lâu, các luồng khác phải chờ. Timeout quá ngắn lại loại nhầm những kết nối chỉ chậm hơn bình thường một chút. Requests cho phép tách timeout thành hai phần: thời gian chờ kết nối và thời gian chờ đọc dữ liệu. Theo hướng dẫn timeout của Requests, đây là giới hạn cho từng giai đoạn, không phải giới hạn cho toàn bộ lượt tải.

Có thể bắt đầu với thời gian chờ kết nối 3 đến 5 giây cho proxy datacenter, 5 đến 10 giây cho proxy dân cư và thời gian chờ đọc 10 đến 15 giây với trang HTML. Sau đó điều chỉnh theo p95 thực tế đo được.

Retry cũng cần giới hạn rõ ràng. Nên tự động thử lại các phương thức an toàn như GET và HEAD; thử lại POST có thể tạo thao tác trùng lặp như gửi đơn hai lần. Thư viện urllib3 hỗ trợ cơ chế retry với thời gian chờ tăng dần và tôn trọng header Retry-After mà máy chủ gửi về.

5. Tạo kết nối TCP và TLS mới liên tục

Mỗi kết nối HTTPS mới cần bắt tay TCP rồi bắt tay TLS, tốn vài lượt khứ hồi. Nếu mỗi request lại tạo một kết nối mới, chi phí này lặp lại hàng nghìn lần. Đây là nguyên nhân rất phổ biến khiến proxy bị chậm trong mã Python viết vội, khi anh em gọi trực tiếp requests.get trong vòng lặp.

Dùng requests.Session giúp tái sử dụng kết nối nhờ connection pooling và Keep-Alive. Với cùng một website, request thứ hai trở đi sẽ bỏ qua phần bắt tay, tiết kiệm đáng kể thời gian. TLS 1.3 cũng cải thiện độ trễ khi cả hai đầu cùng hỗ trợ, vì cần ít lượt khứ hồi hơn để bắt tay. Tuy nhiên, không nên chuyển sang HTTP hay tắt xác minh chứng chỉ chỉ để tăng tốc; đổi bảo mật lấy vài chục mili giây là đánh đổi không đáng.

6. DNS làm tăng thời gian chờ

DNS chậm, bộ nhớ đệm DNS hết hạn hoặc máy chủ phân giải của proxy kém chất lượng đều cộng thêm độ trễ cho request đầu tiên tới mỗi tên miền. Khi chương trình truy cập hàng trăm tên miền khác nhau, phần này trở nên đáng kể.

Với SOCKS, hãy thử cả socks5 và socks5h để so sánh DNS cục bộ với DNS phía proxy. Không nên tự thay tên miền trong URL HTTPS bằng địa chỉ IP, vì chứng chỉ và trường SNI sẽ không khớp. Nếu tự lưu bộ nhớ đệm DNS, phải đặt thời hạn để tránh giữ địa chỉ IP cũ khi website đổi máy chủ.

7. Hạ tầng hoặc tuyến mạng kém ổn định

Băng thông cao chưa đủ để kết luận proxy tốt. Hãy theo dõi trung vị, p95, tỷ lệ thành công, độ dao động và tỷ lệ mất gói. Một proxy trung bình 400 ms nhưng p95 lên tới 5 giây có thể kém hơn một IP ổn định ở mức 700 ms.

Hãy kiểm tra vào nhiều thời điểm khác nhau trong ngày, trên đúng website mục tiêu. Sự ổn định có giá trị hơn một lần kiểm tra tốc độ cho kết quả đẹp. Nếu muốn có công cụ kiểm tra nhanh trước khi viết mã đo riêng, bài công cụ kiểm tra proxy tổng hợp các lựa chọn phổ biến.

Bảng tóm tắt nguyên nhân và cách xử lý

Cách đo khi proxy bị chậm bằng Python

Một phép đo đáng tin cần giữ nguyên ba yếu tố: cùng URL, cùng số lượt và cùng máy chạy. Hãy chạy trực tiếp trước, rồi lần lượt qua từng proxy. Đo tuần tự trước; chỉ khi số liệu nền đã ổn định mới chuyển sang kiểm thử đồng thời.

Đo tốc độ proxy bằng Python

Đoạn mã dưới đây do ProxyVN viết minh họa. Hàm dùng time.perf_counter để đo, đọc hết nội dung phản hồi để kết nối được trả về pool, rồi tính trung bình, trung vị, p95 và tỷ lệ thành công. Một request làm nóng được gửi trước để kết quả không bị ảnh hưởng bởi chi phí kết nối đầu tiên.

import statistics
import time
from collections import Counter
 
import requests
 
 
def benchmark(url, proxy=None, samples=20):
    times = []
    errors = Counter()
    proxies = {"http": proxy, "https": proxy} if proxy else None
 
    with requests.Session() as session:
        session.trust_env = False
        # Request lam nong de bo qua chi phi ket noi dau tien
        try:
            session.get(url, proxies=proxies, timeout=(5, 15)).raise_for_status()
        except requests.RequestException:
            pass
 
        for _ in range(samples):
            start = time.perf_counter()
            try:
                response = session.get(url, proxies=proxies, timeout=(5, 15))
                response.raise_for_status()
                _ = response.content  # doc het noi dung de tra ket noi ve pool
                times.append(time.perf_counter() - start)
            except requests.RequestException as exc:
                errors[type(exc).__name__] += 1
 
    if not times:
        return {"success_rate": 0.0, "errors": dict(errors)}
 
    ordered = sorted(times)
    p95_index = max(0, round(0.95 * len(ordered)) - 1)
    return {
        "success_rate": len(times) / samples * 100,
        "mean_ms": statistics.mean(times) * 1000,
        "median_ms": statistics.median(times) * 1000,
        "p95_ms": ordered[p95_index] * 1000,
        "errors": dict(errors),
    }
 
 
url = "https://httpbin.org/get"
proxy = "http://USER:PASS@HOST:8080"
print("Direct:", benchmark(url))
print("Proxy:", benchmark(url, proxy=proxy))

Đọc kết quả đo thế nào cho đúng

Nếu kết nối trực tiếp đã chậm, vấn đề nằm ở website hoặc mạng của máy chạy, đổi proxy không giải quyết được. Nếu proxy chậm hơn trực tiếp vài chục mili giây, đó là chi phí bình thường của một chặng trung gian. Nếu proxy chậm hơn vài trăm mili giây trở lên hoặc tỷ lệ thành công dưới 95%, lúc đó mới cần xem xét bảy nguyên nhân ở trên.

Một lưu ý quan trọng: không lấy tổng thời gian chia đôi để gọi là độ trễ mạng. Tổng thời gian còn chứa phân giải DNS, bắt tay TCP, TLS, thời gian xử lý tại proxy và máy chủ, cùng thời gian tải nội dung. Độ trễ mạng thuần cần được đo riêng.

Tối ưu code Python khi proxy bị chậm

Sau khi xác định proxy vẫn đạt tỷ lệ thành công tốt, anh em có thể tối ưu phía mã nguồn. Đoạn mã minh họa dưới đây dựng một Session dùng chung với retry có thời gian chờ tăng dần, chỉ thử lại các phương thức an toàn và tôn trọng header Retry-After.

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
 
 
def build_session():
    retry = Retry(
        total=3,
        connect=3,
        read=2,
        status=2,
        backoff_factor=0.5,
        status_forcelist=(429, 500, 502, 503, 504),
        allowed_methods=frozenset({"GET", "HEAD", "OPTIONS"}),
        respect_retry_after_header=True,
    )
    adapter = HTTPAdapter(
        max_retries=retry,
        pool_connections=10,
        pool_maxsize=20,
        pool_block=True,
    )
    session = requests.Session()
    session.trust_env = False
    session.mount("http://", adapter)
    session.mount("https://", adapter)
    return session
 
 
proxy = "http://USER:PASS@HOST:8080"
proxies = {"http": proxy, "https": proxy}
 
with build_session() as session:
    response = session.get("https://example.com", proxies=proxies, timeout=(5, 15))
    response.raise_for_status()
    print(response.status_code, len(response.content))

Giải thích các tham số quan trọng

Tham số pool_maxsize bằng 20 chỉ là sức chứa của pool kết nối, không phải số luồng nên chạy trên một IP. Hãy tăng số luồng từng nấc nhỏ và theo dõi p95 sau mỗi lần tăng. Khi p95 bắt đầu tăng nhanh hoặc lỗi 429 xuất hiện, đó là ngưỡng của IP đó.

Tham số pool_block bằng True khiến các luồng chờ khi pool đầy thay vì tạo kết nối mới vượt giới hạn. Điều này giúp tránh việc vô tình mở quá nhiều kết nối tới proxy và bị nhà cung cấp giới hạn.

Khi chạy đa luồng, nên tạo một Session cho mỗi luồng hoặc dùng biến cục bộ theo luồng. Session của Requests không được thiết kế để chia sẻ an toàn giữa nhiều luồng trong mọi trường hợp.

Phân bổ request qua nhiều proxy

Khi có nhiều proxy, đừng dồn hết request vào IP nhanh nhất. Hãy phân bổ đều theo vòng, đồng thời ghi nhận p95 và tỷ lệ lỗi của từng IP. IP nào vượt ngưỡng trong nhiều chu kỳ liên tiếp thì tạm loại ra và kiểm tra lại sau. Cách làm này giúp hệ thống tự thích nghi khi một vài IP xuống cấp, thay vì cả chương trình bị kéo chậm theo IP kém nhất.

Nếu một IP liên tục bị chặn chứ không chỉ chậm, nguyên nhân thường nằm ở website đích chứ không phải hạ tầng proxy. Bài vì sao mua proxy bị block hướng dẫn phân biệt lỗi 403, 429 và trang xác minh để xử lý đúng.

Chọn proxy đúng ngay từ đầu để tránh proxy bị chậm

Tối ưu mã chỉ giải quyết được một phần. Nếu loại proxy không phù hợp với tác vụ, mọi thủ thuật phía mã nguồn đều chỉ cải thiện chút ít. Dưới đây là cách chọn proxy theo từng kiểu công việc để giảm tình trạng chậm ngay từ đầu.

Gọi API và tải dữ liệu số lượng lớn

Với API công khai hoặc website ít chặn, proxy datacenter là lựa chọn nhanh nhất vì nằm trong trung tâm dữ liệu có băng thông lớn và độ trễ thấp. Nên chọn trung tâm dữ liệu cùng khu vực với máy chủ API. Nếu máy chủ API đặt tại Singapore, proxy ở Singapore hoặc Việt Nam sẽ nhanh hơn nhiều so với proxy ở Mỹ.

Thu thập dữ liệu từ website có chống bot

Với website chặn mạnh, proxy dân cư cho tỷ lệ thành công cao hơn nhưng tốc độ thấp hơn. Trong trường hợp này, đừng so sánh tốc độ từng request mà hãy so sánh số bản ghi hợp lệ thu được mỗi giờ. Một proxy nhanh nhưng bị chặn 30% request thường cho năng suất thực tế thấp hơn một proxy chậm hơn nhưng thành công 98%.

Phiên làm việc dài, cần giữ IP

Với công cụ cần đăng nhập và giữ phiên, proxy ISP tĩnh cân bằng tốt giữa tốc độ và độ ổn định. IP không đổi giúp tái sử dụng kết nối lâu dài, tận dụng tối đa lợi ích của Session và Keep-Alive.

Đặt máy chạy gần proxy

Một chi tiết hay bị bỏ qua là vị trí của máy chạy chương trình. Nếu máy chạy ở Việt Nam, proxy ở Mỹ và website đích ở châu Âu, mỗi request phải đi qua ba lục địa. Khi khối lượng lớn, đặt máy chạy trên máy chủ ảo cùng khu vực với proxy và website đích có thể giảm độ trễ đáng kể mà không cần thay đổi dòng mã nào.

Theo dõi liên tục thay vì kiểm tra một lần

Chất lượng proxy thay đổi theo thời gian. Hãy lưu kết quả đo của mỗi lần chạy vào một tệp nhật ký đơn giản gồm thời gian, IP, trung vị, p95 và tỷ lệ thành công. Sau vài tuần, anh em sẽ thấy rõ IP nào ổn định, khung giờ nào hay chậm và khi nào cần trao đổi với nhà cung cấp.

Phân biệt proxy chậm với proxy lỗi

Không phải mọi request chậm đều do proxy yếu. Đôi khi proxy đã gặp lỗi thật sự và chỉ đang phản hồi chậm trước khi trả về thông báo lỗi.

Lỗi phía máy chủ proxy

Các mã lỗi 502, 503 và 504 thường xuất hiện khi proxy không kết nối được tới website đích hoặc máy chủ proxy quá tải. Nếu thấy các mã này xuất hiện dày đặc, hãy kiểm tra trạng thái dịch vụ với nhà cung cấp. Bài các lỗi máy chủ proxy tổng hợp ý nghĩa từng mã lỗi và cách xử lý.

Lỗi xác thực và cấu hình

Lỗi 407 cho biết thông tin xác thực proxy không đúng. Lỗi kết nối bị từ chối ngay lập tức thường do sai cổng hoặc IP máy chạy chưa được đưa vào danh sách cho phép. Những lỗi này không làm proxy chậm nhưng khiến tỷ lệ thành công giảm, kéo theo retry và làm tổng thời gian chạy tăng.

Khi nào nên thay proxy

Nếu đã tối ưu mã, chọn đúng vị trí, giới hạn số luồng hợp lý mà p95 vẫn cao và tỷ lệ thành công vẫn thấp trong nhiều ngày, đó là lúc nên thay proxy. Bài dấu hiệu cần thay proxy liệt kê các tín hiệu cụ thể giúp anh em quyết định thay vì cứ chờ đợi.

Checklist xử lý proxy bị chậm

Anh em có thể làm theo thứ tự dưới đây để tiết kiệm thời gian khi gặp tình trạng proxy bị chậm.

Checklist xử lý proxy bị chậm

• Đo số liệu nền trực tiếp và qua proxy trên cùng một URL.
• Ghi lại trung vị, p95, tỷ lệ thành công và loại lỗi cho từng proxy.
• Chọn proxy gần website mục tiêu nhất có thể.
• So sánh HTTP, socks5 và socks5h nếu nhà cung cấp hỗ trợ.
• Dùng Session để tái sử dụng kết nối, không gọi request rời rạc trong vòng lặp.
• Đặt riêng thời gian chờ kết nối và thời gian chờ đọc, kèm retry có thời gian chờ tăng dần.
• Giới hạn số luồng trên mỗi IP, tăng tải từng nấc nhỏ.
• Đo vào nhiều thời điểm, tự động loại proxy vượt ngưỡng p95.
• Không tắt xác minh TLS và không ghi thông tin tài khoản proxy vào mã nguồn công khai.

Qua nhiều dự án gửi request hàng loạt, hiệu quả hiếm khi đến từ một thủ thuật đơn lẻ. Chọn đúng vị trí, tái sử dụng kết nối và loại IP kém theo p95 mới tạo ra cải thiện bền vững.

Xem thêm: Vì sao mua Proxy bị block? Cách phân biệt 403, 429, CAPTCHA

Câu hỏi thường gặp về proxy bị chậm

Proxy dân cư có luôn chậm hơn proxy datacenter không?

Thường là có, vì IP dân cư đi qua đường truyền gia đình với băng thông và độ ổn định thấp hơn trung tâm dữ liệu. Đổi lại, proxy dân cư ít bị chặn hơn. Nếu tốc độ là ưu tiên hàng đầu và website đích không chặn mạnh, proxy datacenter hoặc ISP là lựa chọn phù hợp hơn.

Tăng số luồng có làm nhanh hơn không?

Chỉ tới một ngưỡng nhất định. Vượt ngưỡng đó, proxy và website đích bắt đầu giới hạn, lỗi tăng lên và tổng thời gian còn dài hơn. Hãy tìm ngưỡng bằng cách tăng từng nấc và theo dõi p95.

Proxy miễn phí có đáng để thử không?

Proxy miễn phí thường bị hàng nghìn người dùng chung, tốc độ thấp, tỷ lệ lỗi cao và không rõ ai vận hành. Với bất kỳ dự án nghiêm túc nào, thời gian xử lý lỗi sẽ lớn hơn nhiều so với chi phí của một gói proxy trả phí.

Có nên dùng thư viện bất đồng bộ thay cho Requests?

Với khối lượng rất lớn, thư viện bất đồng bộ như aiohttp hoặc httpx giúp xử lý nhiều kết nối đồng thời hiệu quả hơn so với đa luồng. Tuy nhiên, các nguyên tắc về vị trí proxy, tái sử dụng kết nối và giới hạn tải trên mỗi IP vẫn giữ nguyên.

Nếu đã tối ưu code mà proxy vẫn chậm, anh em có thể mua proxy tốc độ cao tại ProxyVN và đo lại theo cách trong bài để so sánh.

Proxy bị chậm cần được xử lý bằng dữ liệu: đo số liệu nền, kiểm tra vị trí, giao thức, tải, DNS, TLS, thời gian chờ và connection pool. Khi cần kết nối ổn định, proxy chất lượng cùng hỗ trợ kỹ thuật liên tục, 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 để hạn chế gián đoạn và tối ưu hiệu suất.