Tự động hóa trình duyệt — headless Chrome, Playwright, Puppeteer, Selenium — kết nối với proxy không giống một HTTP client thông thường: địa chỉ được khai báo trong tham số khởi chạy driver chứ không nằm trong cài đặt hệ thống của hệ điều hành. Một lỗi ở khâu này sẽ làm lộ bot sớm hơn bất kỳ thiết lập antidetect nào, còn bản thân tự động hóa lại tiêu tốn lưu lượng nhiều gấp nhiều lần so với lúc mới bắt đầu bạn nghĩ. Bài viết này giải thích cách kênh proxy nằm trong chuỗi trình duyệt—driver—mạng, lượng GB dư thừa đến từ đâu và điều gì thực sự giúp giảm chi phí đó.
Cách proxy kết nối với trình duyệt headless và driver
Với trình duyệt headless, địa chỉ proxy không phải là cài đặt hệ thống mà được khai báo trong tham số khởi chạy: với Chromium là cờ «--proxy-server=host:port», với Playwright và Puppeteer là trường proxy trong tùy chọn của context, với Selenium là đối tượng Proxy trong capabilities của driver. Cài đặt hệ thống sẽ chuyển hướng toàn bộ lưu lượng của máy, kể cả các tiến trình nền; cài đặt ở cấp driver chỉ có hiệu lực bên trong phiên trình duyệt — đúng thứ bạn cần khi trên một máy có hàng chục profile chạy song song với các địa chỉ khác nhau.
Xác thực bằng tên đăng nhập và mật khẩu trong URL (hoạt động trong Playwright và Puppeteer qua tham số context, nhưng không dùng được khi chỉ khởi chạy Chromium bằng một cờ) hoặc bằng cách gắn với IP trắng của máy chủ tự động hóa. Cách thứ hai đáng tin cậy hơn cho CI runner có địa chỉ đi ra cố định: bạn không cần lưu mật khẩu proxy trong biến môi trường.
Vì sao tự động hóa tốn lưu lượng hơn bạn nghĩ
Khi cuộn trang, con người chỉ nhìn thấy phần trên của màn hình. Còn driver mặc định tải toàn bộ trang: phông chữ (hàng trăm kilobyte cho mỗi họ phông), script phân tích và mạng quảng cáo, pixel retargeting, websocket của chat hỗ trợ. Không phần tử nào trong số này cần thiết để kiểm tra giá hay văn bản, nhưng chúng vẫn được tải cùng với nội dung mục tiêu.
Trên trang sản phẩm, dữ liệu hữu ích — HTML chứa giá và thông số — chỉ nặng vài chục kilobyte, còn 2–5 MB còn lại của trang là hình ảnh, phông chữ và script bên thứ ba mà tác vụ của bạn không hề dùng đến. Đó chính là khoản trả dư cho lưu lượng không bao giờ đi vào kết quả. Phân tích chi tiết về việc nên tắt gì và cách tính mức tiết kiệm theo từng bước có trong bài cách giảm mức tiêu thụ GB của proxy.
Tắt media — cách tiết kiệm chính
Đòn bẩy tiết kiệm chính là chặn những gì không đi vào kết quả thu thập dữ liệu ngay ở cấp driver, chứ không phải chọn một kênh rẻ hơn. Với Playwright và Puppeteer, đó là chặn request và hủy các loại image, media, font, đôi khi cả stylesheet. Với Selenium và Chrome, hiệu quả tương tự đạt được nhờ cài đặt profile tắt tải hình ảnh.
Kết quả là dung lượng trang giảm từ 3 đến 10 lần, tùy số lượng hình ảnh và video ban đầu. Với các tác vụ chỉ cần văn bản — giá, tình trạng còn hàng, trạng thái đơn hàng — việc chặn media không ảnh hưởng đến kết quả: dữ liệu nằm trong HTML chứ không nằm trong chính các hình ảnh. Việc chạy theo kênh rẻ nhất thay vì tắt media thường cho kết quả ngược lại — sự khác biệt được phân tích trong bài proxy rẻ so với proxy đắt.
Đồng bộ locale, múi giờ và ngôn ngữ yêu cầu với vị trí địa lý của địa chỉ
Đổi IP không tự động đổi locale của trình duyệt, múi giờ hệ thống hay header Accept-Language. Nếu địa chỉ được cấp là của Mỹ, nhưng context lại báo múi giờ Europe/Moscow và tiếng Nga, trang web sẽ nhận được những tín hiệu mâu thuẫn. Một số trang trả nội dung theo ngôn ngữ của header chứ không theo IP, vì vậy sự lệch pha làm thay đổi chính kết quả hiển thị, chứ không chỉ khiến phiên bị nghi ngờ hơn.
Với Playwright và Puppeteer, locale, timezoneId và các header được đặt trong tùy chọn context khi tạo trang, và cần được đồng bộ theo vị trí địa lý của địa chỉ mỗi lần khởi chạy, chứ không phải một lần cho tất cả profile cùng lúc. Checklist cho cặp «profile cộng kênh proxy», bao gồm kiểm tra WebRTC và DNS, có trong bài proxy cho trình duyệt antidetect từng bước.
Profile chạy song song và một cổng riêng cho mỗi profile
Khi tự động hóa chạy nhiều profile cùng lúc, dùng chung một cổng cho tất cả sẽ gây ra hai vấn đề. Về mạng — các phiên chia sẻ băng thông và giới hạn luồng, dẫn đến timeout và phải thử lại. Về hành vi — nếu nhà cung cấp đổi IP đi ra trên cùng một cổng khi kết nối lại, trang web sẽ thấy địa chỉ thay đổi ngay trong phiên và có thể coi đó là bất thường.
Quy tắc rất đơn giản: mỗi profile chạy song song dùng một cổng riêng và một địa chỉ ổn định trong suốt phiên. Cách này làm tăng số kênh cần mua, nhưng loại bỏ cả hai nguyên nhân gây ra việc thử lại. Việc điều khiển thay đổi địa chỉ trên từng cổng bằng chương trình, không phải dựng lại cấu hình thủ công trước mỗi lần chạy, được thực hiện nhờ xoay vòng qua API — nội dung này được phân tích trong bài cách thiết lập xoay vòng IP qua API.
Câu hỏi thường gặp
Có thể dùng một proxy cho nhiều profile headless cùng lúc không?
Về mặt kỹ thuật là được, nhưng không nên: các phiên song song qua cùng một cổng chia sẻ băng thông và dễ gây timeout, đồng thời trang web có thể coi việc các request xen kẽ từ một địa chỉ là hoạt động đáng ngờ. Khi chạy song song, hãy dùng một cổng riêng cho mỗi profile.
Tắt hình ảnh và phông chữ có làm hỏng việc thu thập dữ liệu không?
Không, nếu dữ liệu cần thiết nằm trong HTML chứ không được hiển thị bằng hình ảnh hoặc phần tử canvas. Trước khi chạy hàng loạt, bạn nên chạy thử tác vụ với media bật và tắt rồi so sánh kết quả — với giá, tình trạng còn hàng và các trường văn bản thì thường không có khác biệt.
Làm sao kiểm tra locale và múi giờ của trình duyệt khớp với vị trí địa lý của proxy?
Qua bất kỳ dịch vụ kiểm tra dấu vân tay trình duyệt nào — dịch vụ đó sẽ hiển thị IP, quốc gia, múi giờ và ngôn ngữ mà trang web nhìn thấy. Nên đưa bước kiểm tra này vào chính script tự động hóa như bước đầu tiên trước tác vụ chính, thay vì kiểm tra thủ công lúc có lúc không.
Một cổng riêng cho mỗi profile tự động hóa, xác thực bằng IP trắng cho CI và lựa chọn kênh phù hợp với tác vụ — địa chỉ dân cư và di động tính theo lưu lượng hoặc datacenter tính theo tháng — có trong mục proxy.