DrissionPage proxy: khác biệt giữa Chromium mode và Session mode

DrissionPage proxy là cách cho thư viện tự động hóa DrissionPage của Python đi qua máy trung gian. DrissionPage có hai chế độ: Chromium mode điều khiển trình duyệt thật, Session mode gửi request như thư viện HTTP. Hai chế độ nhận proxy theo hai cách và hỗ trợ xác thực khác nhau. ProxyVN chạy DrissionPage 4.1.1.4 với Edge qua proxy tự dựng, ghi lại từng ca.

DrissionPage proxy và hai chế độ làm việc

Chromium mode và Session mode

DrissionPage do một tác giả Trung Quốc phát triển, tài liệu chính viết bằng tiếng Trung. Thư viện gói hai cách lấy dữ liệu web vào một API. Chromium mode, gọi tắt mode d, điều khiển Chrome hoặc Edge qua giao thức DevTools, chạy JavaScript, xử lý trang động. Session mode, gọi tắt mode s, gửi request HTTP trực tiếp bằng thư viện requests, nhanh và nhẹ hơn nhiều.

Lớp ChromiumPage chỉ có mode d, SessionPage chỉ có mode s, còn WebPage có cả hai và chuyển qua lại bằng change_mode. Proxy của mỗi mode được cấu hình bằng đối tượng tùy chọn riêng: ChromiumOptions cho mode d, SessionOptions cho mode s.

Đặt proxy cho một mode không tự áp cho mode kia. Với WebPage, phải cấu hình proxy cho cả hai đối tượng tùy chọn, nếu không một nửa số request sẽ đi thẳng.

Ranh giới với các bài trình duyệt khác

Bài cài đặt Selenium Python proxy và bài proxy Playwright nói về hai công cụ khác. Bài này không viết lại hướng dẫn cờ Chrome chung, chỉ chứng minh phạm vi proxy của từng mode DrissionPage: mode nào nhận được proxy có mật khẩu, mode nào hỗ trợ SOCKS5, cookie đi đâu khi đổi mode.

Brief của bài yêu cầu lab cùng một URL qua hai mode và báo cáo đường đi, cookie tách biệt. Phần lab bên dưới làm đúng việc đó, có nhật ký proxy để đối chiếu.

Môi trường lab

Lab chạy trên Windows 10, Python 3.12, DrissionPage 4.1.1.4 cài từ trang DrissionPage trên PyPI, trình duyệt Microsoft Edge có sẵn trên máy, chạy không giao diện. Proxy thử có hai bản: bản cần tài khoản user1 với mật khẩu p@ss#2026 ở cổng 8942, bản mở không cần tài khoản ở cổng 8932 và 8962. Proxy SOCKS5 cùng tài khoản ở cổng 8943.

Website thử tên shop.test chỉ phân giải được bên trong proxy. Request đi thẳng sẽ lỗi, request qua proxy nhận JSON có đường dẫn, User-Agent và cookie đã gửi. Một đường dẫn đặc biệt trả tiêu đề Set-Cookie để kiểm cookie giữa hai mode.

Cấu hình DrissionPage proxy cho Chromium mode

set_proxy trên ChromiumOptions

Trang thiết lập khởi động trình duyệt trong tài liệu chính thức của DrissionPage, và mã nguồn trên kho DrissionPage trên GitHub, có phương thức set_proxy trên ChromiumOptions. Phương thức nhận URL proxy và truyền xuống trình duyệt như tham số khởi động. Đoạn dưới là cấu hình mình chạy trong lab.

from DrissionPage import ChromiumOptions, ChromiumPage
 
co = ChromiumOptions()
co.set_browser_path(r"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe")
co.headless(True)
co.set_local_port(9302)
co.set_proxy("http://127.0.0.1:8932")
 
page = ChromiumPage(co)
page.get("http://shop.test:8931/c2")
print(page.ele("tag:body").text)
page.quit()

Với proxy mở, trang trả JSON có via là http-proxy, nhật ký proxy ghi GET http://shop.test:8931/c2. Không đặt proxy, cùng URL làm get trả False, trình duyệt không phân giải được shop.test.

Proxy có mật khẩu bị từ chối

Chromium mode không nhận mật khẩu

Mình đặt set_proxy với URL có tài khoản http://user1:p%40ss%[email protected]:8942. DrissionPage in một thông báo tiếng Trung, dịch nghĩa là bạn có vẻ đang đặt proxy dùng tài khoản mật khẩu, hiện chưa hỗ trợ loại proxy này, có thể tự dùng tiện ích để làm. Trang không được mở, get trả False.

Đặt set_proxy với proxy cần mật khẩu nhưng không đưa tài khoản vào URL, trình duyệt khởi chạy được, nhưng proxy trả 407 và get trả False. Nhật ký proxy ghi request không có tài khoản. Trình duyệt chạy không giao diện không có hộp thoại để nhập mật khẩu.

Với DrissionPage 4.1.1.4, Chromium mode không nhận proxy có tên và mật khẩu qua set_proxy. Đây là giới hạn do chính thư viện báo, không phải lỗi cấu hình.

Cách xử lý proxy có mật khẩu cho Chromium mode

Hai mode, hai cách đặt proxy

Có ba hướng. Hướng thứ nhất là dùng proxy xác thực theo IP: nhà cung cấp cho phép IP của máy chạy, không cần mật khẩu. Đây là cách gọn nhất và đúng với giới hạn của thư viện. Hướng thứ hai là chạy một proxy cục bộ không mật khẩu trên máy, proxy này chuyển tiếp sang proxy thật có mật khẩu.

Hướng thứ ba là tiện ích trình duyệt xử lý xác thực proxy, như thông báo của DrissionPage gợi ý. ChromiumOptions có phương thức nạp tiện ích. Cách này phức tạp hơn và phụ thuộc trình duyệt cho phép tiện ích ở chế độ không giao diện, mình chưa thử trong lab.

Cấu hình DrissionPage proxy cho Session mode

set_proxies trên SessionOptions

Session mode dùng requests bên dưới, nhận proxy qua set_proxies với hai tham số http và https. URL proxy có thể chứa tài khoản, mật khẩu mã hóa phần trăm.

from DrissionPage import SessionOptions, SessionPage
 
so = SessionOptions()
proxy = "http://user1:p%40ss%232026@127.0.0.1:8942"
so.set_proxies(http=proxy, https=proxy)
 
page = SessionPage(so)
ok = page.get("http://shop.test:8941/s2", retry=0, timeout=5)
print(ok, page.response.status_code, page.html[:80])

Trong lab, get trả True, mã 200, thân là JSON của shop.test có via là http-proxy. Nhật ký proxy ghi GET với tài khoản user1, xác thực đạt. Không đặt proxy, get trả False vì không phân giải được shop.test.

Mật khẩu sai trong Session mode

Với mật khẩu sai, get trả False, page.response là None, thân rỗng. Bật show_errmsg bằng True, DrissionPage ném ConnectionError kèm thông báo tiếng Trung có nghĩa nội dung trả về rỗng và dòng phiên bản 4.1.1.4. Nhật ký proxy ghi tài khoản bị từ chối.

Thông báo này không nói rõ proxy trả 407. Mã của anh em chỉ thấy get trả False, rất giống lỗi mạng hay website chết. Khi Session mode lỗi mà không rõ lý do, thử cùng URL bằng requests thuần với cùng proxy để thấy mã trạng thái thật. Bài sửa lỗi 407 Proxy Authentication Required liệt kê nguyên nhân phía nhà cung cấp.

SOCKS5 cần PySocks

Lần đầu đặt set_proxies với socks5h://, get trả False. Sau khi cài gói pysocks, cùng cấu hình trả True, mã 200, nhật ký SOCKS ghi CONNECT tới tên miền shop.test. Theo tài liệu requests về SOCKS, requests chỉ hỗ trợ SOCKS khi có PySocks, mà DrissionPage không tự kéo gói này khi cài.

Dùng socks5h để proxy phân giải tên miền, tránh rò truy vấn DNS. Bài DNS leak khi dùng proxy giải thích vì sao chữ h quan trọng.

Bảng so sánh DrissionPage proxy hai mode

Kết quả lab

Bảng dưới gom kết quả các ca đã chạy, cùng URL shop.test qua hai mode.

Bảng: Kết quả lab

Ca	Chromium mode	Session mode
Không proxy	get trả False, không phân giải được	get trả False
Proxy mở không mật khẩu	Qua proxy, via http-proxy	Qua proxy
URL proxy có tài khoản	Từ chối, thông báo chưa hỗ trợ	Qua proxy, xác thực đạt
Proxy cần mật khẩu, không đưa tài khoản	Proxy trả 407, get trả False	Không áp dụng
Mật khẩu sai	Không áp dụng	get trả False, response None
SOCKS5 qua socks5h	Chưa thử	Chạy khi có PySocks

Bảng cho thấy Session mode linh hoạt hơn về proxy, còn Chromium mode chỉ hợp với proxy không cần mật khẩu. Kế hoạch lấy dữ liệu nên dựa trên giới hạn này ngay từ đầu.

Chọn mode theo trang

Trang tĩnh hoặc API trả JSON nên dùng Session mode: nhanh, nhận proxy có mật khẩu, nhẹ tài nguyên. Trang cần JavaScript để hiện dữ liệu, cần đăng nhập phức tạp hay có thử thách chống bot nên dùng Chromium mode với proxy xác thực theo IP. Trang cần cả hai, ví dụ đăng nhập bằng trình duyệt rồi lấy dữ liệu bằng API, dùng WebPage và đổi mode.

Với DrissionPage proxy, Session mode nhận proxy có mật khẩu, Chromium mode thì không. Chọn loại xác thực proxy theo mode sẽ dùng, đừng để tới lúc chạy mới phát hiện.

DrissionPage proxy khi đổi mode bằng WebPage

Cấu hình proxy cho cả hai mode

WebPage nhận chromium_options và session_or_options khi khởi tạo. Mình đặt cùng một proxy mở cho cả hai, rồi chạy kịch bản: mở trang đặt cookie ở mode d, đổi sang mode s, gọi trang khác.

from DrissionPage import ChromiumOptions, SessionOptions, WebPage
 
co = ChromiumOptions().headless(True)
co.set_proxy("http://127.0.0.1:8962")
so = SessionOptions()
so.set_proxies(http="http://127.0.0.1:8962", https="http://127.0.0.1:8962")
 
page = WebPage(chromium_options=co, session_or_options=so)
page.get("http://shop.test:8961/setc-d")
print(page.mode, page.cookies())
page.change_mode()
page.get("http://shop.test:8961/after-switch")
print(page.mode, page.html[:120])
page.quit()

Ở mode d, trang trả cookie lab_session và page.cookies có cookie đó. Sau change_mode, page.mode là s, request tới after-switch qua proxy, website nhận được cookie lab_session.

Cookie và User-Agent được chép sang

Đổi mode chép cookie

Website thử in lại cookie và User-Agent nhận được. Sau khi đổi sang mode s, request gửi cookie lab_session và User-Agent giống của trình duyệt Edge, không phải User-Agent mặc định của requests. Nghĩa là change_mode chép cookie và User-Agent từ trình duyệt sang phiên requests.

Đây là tính năng có ích: đăng nhập bằng trình duyệt, rồi chuyển sang mode s để lấy dữ liệu nhanh mà website vẫn nhận ra phiên. Nhưng nó chỉ đúng khi hai mode đi cùng một IP. Nếu mode d và mode s dùng hai proxy khác nhau, website thấy cùng một cookie phiên từ hai IP, dễ coi là đáng ngờ.

change_mode tải lại trang hiện tại

Nhật ký proxy có hai dòng cho setc-d: một của trình duyệt, một của mode s ngay khi đổi. Giá trị cookie cuối cùng trong mode s khác giá trị ở mode d vì website đặt cookie mới ở request thứ hai. Theo mặc định, change_mode mở lại URL hiện tại ở mode mới.

Với trang có tác dụng phụ, như trang xác nhận đơn hàng hay trang trừ lượt dùng, request lặp này có thể gây hậu quả. Đổi mode khi đang ở một trang an toàn, hoặc đọc tham số của change_mode trong bản đang dùng để tắt việc mở lại.

Kiểm IP và cookie tách biệt trong DrissionPage proxy

Báo cáo đường đi từng mode

Brief yêu cầu báo cáo IP và cookie tách biệt. Cách làm là cho mỗi mode gọi một trang trả IP và cookie nhận được, rồi so. Với proxy thương mại, dùng dịch vụ trả IP công khai. Với lab, trang shop.test trả client, via và cookie là đủ.

• Mode d không proxy, mode s có proxy: hai IP khác nhau, website thấy hai nguồn.
• Cùng proxy cho hai mode: cùng IP, cookie chép qua khi đổi mode.
• Hai proxy khác nhau: cookie giống nhau từ hai IP, rủi ro bị đánh dấu.
• Proxy xoay cho mode s: mỗi request có thể ra IP khác, cookie phiên dễ bị website hủy.

Với luồng có đăng nhập, giữ một IP cho cả hai mode trong suốt phiên. Với lấy dữ liệu công khai không cần cookie, mode s có thể dùng proxy xoay.

Thư mục hồ sơ trình duyệt

Mỗi lần chạy Chromium mode, DrissionPage dùng một thư mục hồ sơ trình duyệt. Trong lab, mình đặt set_user_data_path và set_local_port riêng cho mỗi ca để hồ sơ không lẫn. Cookie của mode d nằm trong thư mục hồ sơ, còn tồn tại sau khi đóng trình duyệt nếu dùng lại thư mục đó.

Khi đổi proxy giữa các lần chạy, cookie cũ trong hồ sơ có thể làm website thấy một phiên cũ đến từ IP mới. Dùng thư mục hồ sơ riêng cho mỗi proxy hoặc xóa cookie trước khi chạy với proxy mới.

DrissionPage proxy qua proxy cục bộ chuyển tiếp

Ý tưởng

Vì Chromium mode không nhận proxy có mật khẩu, một cách làm phổ biến là chạy một proxy nhỏ trên chính máy chạy DrissionPage. Proxy cục bộ này nghe ở 127.0.0.1, không đòi mật khẩu, và chuyển mọi request sang proxy thật có mật khẩu. Trình duyệt chỉ cần set_proxy trỏ về 127.0.0.1, phần xác thực do proxy cục bộ lo.

Lab của bài thực chất đã dùng mô hình này theo chiều ngược lại: proxy mở ở cổng 8932 và 8962 không đòi mật khẩu, trình duyệt đi qua bình thường. Thay proxy mở bằng một bộ chuyển tiếp có cấu hình proxy cha có mật khẩu là đủ cho Chromium mode.

Dùng mitmproxy ở chế độ upstream

Một công cụ quen thuộc là mitmproxy với chế độ upstream, chuyển tiếp sang một proxy cha. Lệnh dưới là ví dụ triển khai, mình chưa chạy trong lab. Giá trị tài khoản lấy từ biến môi trường để không nằm trong lịch sử lệnh.

mitmdump --mode upstream:http://203.0.113.10:8080 --upstream-auth "$PROXY_USER:$PROXY_PASS" --listen-host 127.0.0.1 --listen-port 8899

Sau đó đặt co.set_proxy("http://127.0.0.1:8899") cho Chromium mode. mitmproxy mặc định giải mã HTTPS để kiểm nội dung, cần tin chứng chỉ của nó trong trình duyệt hoặc cấu hình để chỉ chuyển tiếp. Đọc tài liệu mitmproxy về chế độ chuyển tiếp không giải mã trước khi dùng thật.

Rủi ro và quản lý

Proxy cục bộ là một tiến trình nữa cần chạy, giám sát và dừng đúng lúc. Nếu nó chết, trình duyệt báo lỗi kết nối giống proxy thật chết. Chỉ cho proxy cục bộ nghe ở 127.0.0.1, đừng mở ra mạng, nếu không ai trong mạng cũng có thể đi qua tài khoản proxy của anh em.

Với nhiều trình duyệt chạy song song, mỗi trình duyệt có thể dùng một proxy cục bộ riêng trỏ tới một phiên proxy cha khác. Cách này cho mỗi trình duyệt một IP mà không cần trình duyệt biết gì về mật khẩu.

Lưu lượng nền của trình duyệt khi dùng DrissionPage proxy

Edge gửi nhiều request ngoài trang đích

Khi đọc nhật ký proxy của các ca Chromium mode, mình thấy rất nhiều kết nối không liên quan tới shop.test. Trong một lần chạy ngắn, proxy ghi CONNECT tới edge.microsoft.com, config.edge.skype.com, ntp.msn.com, www.bing.com, nav-edge.smartscreen.microsoft.com, clients2.google.com và vài tên miền khác của Microsoft và Google. Đó là lưu lượng nền của trình duyệt: cập nhật, cấu hình, trang tab mới, SmartScreen.

Tất cả lưu lượng này đi qua proxy giống như request tới trang đích. Với gói proxy tính theo băng thông, chi phí tăng lên mà không lấy thêm được dữ liệu nào. Với proxy giới hạn số kết nối, các kết nối nền chiếm chỗ của request thật.

Giảm lưu lượng nền

ChromiumOptions cho thêm tham số khởi động trình duyệt. Có thể tắt một số tính năng nền bằng các cờ khởi động của Chromium, hoặc dùng hồ sơ trình duyệt đã tắt sẵn đồng bộ, trang tab mới và các dịch vụ không cần. Mở trang đích bằng URL trực tiếp thay vì để trình duyệt hiện trang tab mới trước.

Một cách khác là dùng proxy cục bộ chuyển tiếp như phần trên, chặn các tên miền nền ngay tại proxy cục bộ, chỉ chuyển tiếp tên miền của trang đích. Cách này cũng giúp website đích không thấy những dấu hiệu lạ như trình duyệt cố tải dịch vụ của Microsoft qua IP dân cư ở một quốc gia khác.

Đo trước khi chạy lớn

Trước một đợt chạy lớn, chạy thử vài trang với proxy có nhật ký, đếm số kết nối tới trang đích và số kết nối nền. Tỷ lệ này cho biết bao nhiêu phần trăm băng thông proxy đi vào việc thật. Với Session mode, không có lưu lượng nền, mọi request đều là request của mã.

DrissionPage proxy với nhiều trình duyệt song song

Mỗi trình duyệt một cổng và một hồ sơ

DrissionPage điều khiển trình duyệt qua cổng debug. Trong lab, mỗi ca dùng set_local_port riêng như 9301, 9302, 9303 và set_user_data_path riêng. Hai trình duyệt dùng chung cổng sẽ khiến DrissionPage kết nối nhầm vào trình duyệt đang chạy, kèm proxy của trình duyệt đó, rất khó phát hiện.

Khi chạy song song nhiều proxy, ghép mỗi proxy với một cổng và một thư mục hồ sơ cố định. Ghi bảng ghép này vào cấu hình, kiểm lúc khởi động rằng không có hai proxy dùng chung cổng.

Tài nguyên máy

Mỗi trình duyệt chạy không giao diện vẫn tốn vài trăm megabyte bộ nhớ. Với hàng chục proxy song song, máy có thể cạn bộ nhớ trước khi proxy cạn hạn mức. Với dữ liệu lấy được bằng Session mode, dùng Session mode cho phần lớn request và chỉ mở trình duyệt khi thật sự cần JavaScript.

Đọc lỗi DrissionPage proxy

get trả False thay vì ngoại lệ

DrissionPage mặc định không ném ngoại lệ khi get thất bại, chỉ trả False. Cách này tiện cho kịch bản đơn giản, nhưng che mất nguyên nhân. Trong lab, không phân giải được tên, proxy trả 407, mật khẩu sai đều chỉ thấy False.

Đặt show_errmsg bằng True khi gỡ lỗi để DrissionPage ném ngoại lệ có thông báo. Kết hợp với nhật ký proxy hoặc một lần thử bằng requests thuần để biết nguyên nhân thật. Sau khi gỡ lỗi xong, xử lý giá trị False trong mã bằng nhánh ghi log rõ ràng.

Thông báo tiếng Trung

Nhiều thông báo của DrissionPage là tiếng Trung. Ghi nguyên văn thông báo vào log, kèm số phiên bản, để tra cứu. Thông báo về proxy có mật khẩu và thông báo nội dung trả về rỗng là hai thông báo mình gặp trong lab.

Bảng: Thông báo tiếng Trung

Thông báo hoặc hiện tượng	Mode	Nghĩa	Xử lý
Thông báo chưa hỗ trợ proxy dùng tài khoản mật khẩu	d	URL proxy có tài khoản	Proxy xác thực theo IP hoặc proxy cục bộ chuyển tiếp
get trả False, proxy ghi 407	d	Proxy cần mật khẩu	Như trên
get trả False, response None	s	Sai mật khẩu hoặc mạng	Bật show_errmsg, thử requests thuần
ConnectionError, nội dung trả về rỗng	s	Không nhận được nội dung	Kiểm proxy và URL
socks5h không chạy	s	Thiếu PySocks	Cài pysocks

Retry và timeout

get có tham số retry và timeout. Trong lab, mình đặt retry bằng 0 để thấy lỗi gốc ngay. Mặc định DrissionPage thử lại vài lần, với proxy chết mỗi lần get có thể mất khá lâu trước khi trả False. Đặt timeout vừa phải và retry thấp khi chạy qua proxy.

Kiểm DrissionPage proxy trước một đợt chạy

Bộ ca tối thiểu

Trước khi chạy một đợt lấy dữ liệu, chạy nhanh bộ ca dưới với proxy sẽ dùng thật. Mỗi ca chỉ mất vài giây nhưng bắt được phần lớn lỗi cấu hình.

• Session mode gọi trang trả IP: IP khác IP máy, mã 200.
• Chromium mode gọi trang trả IP: IP khác IP máy, trang hiện đúng.
• Hai mode trả cùng IP nếu luồng có cookie phiên.
• Session mode với mật khẩu sai cố ý: get trả False, chương trình ghi log rõ ràng.
• Chromium mode với proxy cục bộ chết: get trả False trong thời gian timeout đã đặt.
• Nhật ký proxy: số kết nối nền của trình duyệt nằm trong mức chấp nhận.

Ghi kết quả vào log của đợt chạy, kèm số phiên bản DrissionPage và trình duyệt đang dùng. Nếu ca thứ ba thất bại, dừng đợt chạy có đăng nhập, vì website sẽ thấy cùng phiên từ hai IP.

Khi nâng cấp DrissionPage

Thông báo chưa hỗ trợ proxy có mật khẩu là hành vi của bản 4.1.1.4. Bản sau có thể thêm hỗ trợ hoặc đổi cách báo. Mỗi lần nâng cấp, chạy lại ca URL proxy có tài khoản cho Chromium mode để biết giới hạn còn hay không, rồi cập nhật tài liệu nội bộ.

Tên phương thức cũng có thể đổi giữa các bản lớn. Ghim phiên bản trong tệp phụ thuộc và đọc ghi chú phát hành trước khi nâng, nhất là phần nói về tùy chọn khởi động trình duyệt.

Đưa DrissionPage proxy vào dự án thật

Tổ chức cấu hình

Viết hai hàm dựng tùy chọn: một trả ChromiumOptions với proxy không mật khẩu, một trả SessionOptions với proxy có mật khẩu. Đọc thông tin proxy từ biến môi trường. Không ghi tài khoản vào mã hay vào tệp cấu hình được commit.

Với dự án dùng WebPage, truyền cả hai tùy chọn khi khởi tạo, kiểm một lần lúc khởi động rằng cả hai mode đi đúng proxy bằng trang trả IP. Ghi IP của từng mode vào log khởi động.

Ghi log theo mode

Ghi mỗi lần get kèm mode đang chạy, URL, kết quả True hay False, thời gian và proxy đã dùng, không ghi tài khoản. Khi đọc lại log sau một đợt chạy, tách thống kê theo mode giúp thấy ngay mode nào lỗi nhiều. Thường Chromium mode lỗi vì trang nặng hoặc proxy chậm, còn Session mode lỗi vì website chặn request không có JavaScript.

Với WebPage, ghi thêm thời điểm đổi mode. Khi website hủy phiên đăng nhập, mốc đổi mode trong log giúp biết lỗi xảy ra trước hay sau khi chuyển, từ đó biết vấn đề nằm ở cookie, ở User-Agent hay ở IP.

Chọn loại proxy

Với Chromium mode, chọn gói proxy cho phép xác thực theo IP máy chạy, vì set_proxy không nhận mật khẩu. Proxy tĩnh dân cư hợp cho luồng đăng nhập cần giữ IP. Với Session mode lấy dữ liệu công khai, proxy xoay có mật khẩu dùng tốt.

ProxyVN có proxy dân cư tĩnh, datacenter và proxy xoay, hỗ trợ HTTP và SOCKS5, cấp tài khoản user và mật khẩu. Nếu cần proxy cho Session mode hoặc muốn kiểm cấu hình hai mode, anh em có thể mua proxy giá rẻ tại trang chủ ProxyVN rồi chạy lại bảng ca thử.

Tôn trọng website

Proxy chỉ đổi IP. Trình duyệt tự động vẫn có dấu hiệu nhận diện, và tần suất cao vẫn bị giới hạn. Giãn nhịp request, tôn trọng điều khoản và tệp robots của website. Bài lỗi 429 khi dùng proxy có cách xử lý khi bị giới hạn tần suất.

Câu hỏi thường gặp về DrissionPage proxy

Chromium mode có dùng proxy có mật khẩu được không. Với bản 4.1.1.4, set_proxy từ chối URL có tài khoản. Dùng proxy xác thực theo IP hoặc proxy cục bộ chuyển tiếp.

Session mode có dùng proxy có mật khẩu được không. Có, qua set_proxies với URL có tài khoản đã mã hóa phần trăm.

Đặt proxy cho WebPage một lần có đủ không. Không. Đặt cho cả ChromiumOptions và SessionOptions.

SOCKS5 cho Session mode cần gì. Cài gói pysocks, dùng socks5h.

Vì sao get trả False mà không có lỗi. DrissionPage mặc định không ném ngoại lệ. Bật show_errmsg để thấy thông báo.

Đổi mode có giữ cookie không. Có. Trong lab, cookie và User-Agent được chép sang mode s, và trang hiện tại được tải lại một lần.

Trình duyệt tự gửi nhiều request lạ qua proxy có sao không. Đó là lưu lượng nền của Edge hoặc Chrome. Nó tốn băng thông proxy và có thể chiếm kết nối. Giảm bằng cờ khởi động hoặc chặn tại proxy cục bộ.

Có cần mở cổng debug riêng cho mỗi trình duyệt không. Có, khi chạy song song. Dùng set_local_port và set_user_data_path riêng cho mỗi proxy.

Checklist DrissionPage proxy

Checklist DrissionPage proxy

Trước khi chạy thật

• Biết mỗi tác vụ chạy mode nào.
• Proxy không mật khẩu cho Chromium mode.
• Proxy có mật khẩu đã mã hóa cho Session mode.
• Cấu hình proxy cho cả hai mode khi dùng WebPage.
• Cài pysocks nếu dùng SOCKS5.
• Cùng IP cho hai mode khi có cookie phiên.
• Bật show_errmsg khi gỡ lỗi.
• Thư mục hồ sơ riêng cho mỗi proxy.

Giới hạn của lab

Lab chạy DrissionPage 4.1.1.4 với Edge trên Windows và proxy tự dựng. Chưa thử tiện ích xác thực proxy cho Chromium mode, chưa thử SOCKS5 cho Chromium mode, chưa thử Chrome thay cho Edge và chưa thử gateway thương mại.

DrissionPage proxy và những điều cần nhớ

DrissionPage proxy khác nhau theo mode: Chromium mode dùng set_proxy và không nhận proxy có mật khẩu, Session mode dùng set_proxies và nhận được, SOCKS5 cần PySocks. Đổi mode chép cookie và User-Agent, nên giữ cùng IP. Cần proxy ổn định cho DrissionPage proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.