Quản lý proxy pool: từ danh sách IP đến hệ thống chạy ổn định

Danh mục IP: lưu những gì

Bước đầu tiên là chuyển danh sách ip:port:user:pass thành một danh mục có cấu trúc. Có thể là bảng tính, file JSON hay bảng trong cơ sở dữ liệu, miễn là mỗi IP có cùng các trường thông tin. Nếu cần đổi định dạng hàng loạt, dùng công cụ chuyển định dạng proxy.

Kiểm tra sống chết định kỳ

Một IP được coi là sống khi kết nối được tới proxy, xác thực thành công, đi ra đúng IP mong đợi và tải được trang trong thời gian hợp lý. Kiểm tra mỗi bước riêng giúp bạn biết lỗi nằm ở đâu: không kết nối được thường là mạng hoặc tường lửa phía bạn, lỗi 407 là sai thông tin xác thực, còn IP ra khác IP mong đợi là cấu hình sai.

• Gửi một request nhẹ qua proxy tới trang trả về IP, ví dụ curl -x http://user:pass@ip:port -s -m 10 https://httpbin.org/ip, và so IP trả về với IP trong danh mục.
• Ghi lại thời gian phản hồi để thấy IP nào chậm bất thường; bài kiểm tra tốc độ proxy giải thích cách đo cho đúng.
• Thêm một kiểm tra theo trang đích nếu cần: IP sống chưa chắc đã truy cập được website bạn cào.
• Chạy kiểm tra định kỳ, ví dụ mỗi giờ cho pool đang chạy job, và trước mỗi lần khởi động job lớn.
• Kiểm tra nhanh thủ công cả danh sách bằng công cụ check proxy; các cách khác có trong bài kiểm tra proxy còn sống không.
• Đừng đánh dấu dead sau một lần lỗi. Lỗi mạng thoáng qua là bình thường; chỉ chuyển trạng thái khi lỗi lặp lại vài lần liên tiếp.

Trạng thái và vòng đời của một IP

Bốn trạng thái là đủ cho phần lớn hệ thống. active: sẵn sàng nhận việc. cooling: vừa gặp 429, 403 hoặc CAPTCHA từ trang đích, tạm nghỉ đến một thời điểm. dead: lỗi kết nối hoặc xác thực lặp lại, cần kiểm tra hoặc báo hỗ trợ. reserved: gắn cố định cho một tài khoản, không được đưa vào vòng xoay chung.

Tách riêng cooling và dead rất quan trọng. IP bị trang đích giới hạn tốc độ vẫn khoẻ, chỉ cần nghỉ; nếu bạn đánh dấu nó dead và báo lỗi, bạn đang nhầm vấn đề của nhịp request thành vấn đề của proxy. Nếu một IP dead thật sự do lỗi kỹ thuật phía nhà cung cấp, gửi ticket kèm IP, thời điểm và thông báo lỗi để được xử lý nhanh.

Phân bổ IP theo loại việc

• Tài khoản cần giữ phiên (mạng xã hội, shop, quảng cáo): mỗi tài khoản một IP reserved, không bao giờ đưa vào vòng xoay. Đổi IP của tài khoản đang ổn là tạo thêm tín hiệu bất thường.
• Cào dữ liệu công khai: dùng pool chung trạng thái active, xoay vòng hoặc ngẫu nhiên, mỗi IP giữ nhịp an toàn riêng. Cách viết code xoay có trong bài xoay danh sách proxy trong Python.
• Nhiều thị trường: chia pool theo quốc gia, job nào cần dữ liệu nước nào chỉ lấy IP nước đó.
• Nhiều người, nhiều tool: ghi rõ IP nào thuộc ai. Hai tool vô tình dùng chung một IP là nguyên nhân phổ biến của lỗi 429 khó hiểu. Xem chia sẻ proxy cho nhóm an toàn.
• Dự phòng: giữ vài IP rảnh để thay ngay khi một IP phải nghỉ dài, thay vì dồn tải lên số còn lại.

Chính sách retry

Retry không có kiểm soát là cách nhanh nhất để biến một lỗi nhỏ thành bão request. Viết chính sách rõ ràng và áp dụng chung cho mọi tool: lỗi kết nối hay timeout thì thử lại trên IP khác, tối đa vài lần; 429 và 503 thì tôn trọng Retry-After, chuyển IP sang cooling và giảm tốc độ chung; 403 lặp lại trên nhiều IP thì dừng job và xem lại cách gửi request, vì vấn đề không nằm ở IP.

Mỗi lần retry nên có độ trễ tăng dần kèm phần ngẫu nhiên. Đặt giới hạn tổng số lần thử cho mỗi URL, và đẩy URL thất bại vào hàng đợi chạy lại sau. Chi tiết về 429 có trong bài lỗi 429 Too Many Requests.

Log và chỉ số cần theo dõi

• Mỗi request ghi một dòng: thời điểm, job, URL hoặc domain, IP, mã trạng thái, thời gian phản hồi, số lần thử.
• Theo dõi tỷ lệ thành công theo IP và theo domain. IP có tỷ lệ thấp hơn hẳn phần còn lại cần xem riêng; domain có tỷ lệ giảm đồng loạt nghĩa là website đã đổi cách chặn.
• Theo dõi độ trễ trung vị và độ trễ ở nhóm chậm nhất theo IP, không chỉ trung bình.
• Đếm số IP ở từng trạng thái mỗi ngày; số IP cooling tăng đều là dấu hiệu bạn đang chạy quá nhanh.
• Không ghi mật khẩu proxy vào log. Chỉ ghi IP và cổng.
• Giữ log đủ lâu để so sánh trước và sau khi thay đổi cấu hình.

Theo dõi hạn thuê và gia hạn

IP riêng chỉ là của bạn trong thời gian thuê. Nếu để hết hạn, IP có thể được cấp cho người khác và bạn mất cả lịch sử log lẫn tài khoản đã gắn với IP đó. Đặt cảnh báo trước ngày hết hạn trong danh mục, và gia hạn trên dashboard để giữ nguyên IP. Bài gia hạn proxy giữ nguyên IP giải thích chi tiết.

Định kỳ rà lại pool: IP nào không được dùng trong nhiều tuần có thể không cần gia hạn, IP nào luôn bận có thể là dấu hiệu cần thêm IP. Quyết định dựa trên log thay vì cảm giác.

Câu hỏi thường gặp