Ngiêm cấm sử đụng PROXY và VPS vào mục đích trái pháp luật bạn sẽ phải chịu toàn bộ trách nhiệm trước pháp luật khi sử dụng dịch vụ của chúng tôi tks!
Rod browser proxy: Launcher.Proxy và HandleAuth trong Go

Rod browser proxy: Launcher.Proxy và HandleAuth trong Go

Chuyên viên Kỹ thuật ProxyVN 08-08-2026 Đang tính... phút đọc

Rod browser proxy là cách cho thư viện Rod của Go điều khiển Chrome hoặc Edge đi qua máy trung gian. Rod đặt proxy bằng cờ khởi động trình duyệt, còn tài khoản proxy được trả qua giao thức DevTools bằng HandleAuth. ProxyVN đọc mã nguồn Rod v0.116.2, rồi mô phỏng đúng cơ chế CDP mà HandleAuth dùng trên Edge qua proxy có mật khẩu để xem trình duyệt thật sự làm gì.

Rod browser proxy đi qua cờ khởi động của trình duyệt

Rod điều khiển trình duyệt qua CDP

Rod, có tài liệu API trên pkg.go.dev, là thư viện Go điều khiển trình duyệt nhân Chromium qua Chrome DevTools Protocol, gọi tắt CDP. Rod gồm hai phần: launcher khởi chạy tiến trình trình duyệt với các cờ dòng lệnh, và đối tượng Browser, Page gửi lệnh CDP qua WebSocket. Proxy thuộc phần launcher, xác thực proxy thuộc phần CDP.

Đọc tệp lib/launcher/launcher.go trong kho go-rod/rod trên GitHub, hàm Proxy của Launcher chỉ có một dòng: đặt cờ proxy-server với giá trị anh em truyền vào. Rod không tự kết nối tới proxy, chính trình duyệt làm việc đó.

Với Rod, proxy là cấu hình của trình duyệt, không phải của thư viện. Mọi quy tắc về --proxy-server của Chromium đều áp dụng nguyên vẹn.

Ranh giới với bài Playwright và Puppeteer

Bài proxy Playwright và bài cách sử dụng proxy trong Puppeteer nói về hai thư viện khác. Bài này chỉ nói về API của Rod: Launcher.Proxy, HandleAuth, cách chúng gọi CDP, và hành vi thật của trình duyệt khi nhận tài khoản qua CDP.

Không viết lại danh sách cờ Chrome chung. Bài tập trung vào hai câu hỏi mà người dùng Rod hay gặp: vì sao URL proxy có user:pass không chạy, và HandleAuth có cần gọi lại cho mỗi trang không.

Phạm vi kiểm thử

Máy lab hôm viết bài không có trình biên dịch Go, nên chương trình Rod chưa được biên dịch. Mình đọc mã nguồn nhánh main, bản phát hành mới nhất v0.116.2. Sau đó mình dùng một công cụ Python khác để gửi đúng các lệnh CDP mà HandleAuth gửi tới Edge 156 chạy không giao diện. Proxy thử cần tài khoản user1 với mật khẩu p@ss#2026.

Mô phỏng này kiểm được hành vi của trình duyệt với cờ --proxy-server và lệnh Fetch của CDP. Nó không thay được một lần chạy Rod thật, nên mình ghi rõ chỗ nào là mô phỏng.

Đặt Rod browser proxy bằng Launcher.Proxy

Proxy là cờ của trình duyệt

Proxy là cờ của trình duyệt

Ví dụ từ mã nguồn

Tệp examples_test.go của Rod có ví dụ tùy chỉnh khởi chạy trình duyệt. Ví dụ dùng launcher.New().Proxy("127.0.0.1:8080"), chú thích ghi rõ là đặt cờ --proxy-server=127.0.0.1:8080, rồi MustLaunch để lấy URL điều khiển.

package main
 
import (
    "fmt"
    "os"
 
    "github.com/go-rod/rod"
    "github.com/go-rod/rod/lib/launcher"
)
 
func main() {
    u := launcher.New().
        Proxy(os.Getenv("PROXY_HOSTPORT")).
        Headless(true).
        MustLaunch()
 
    browser := rod.New().ControlURL(u).MustConnect()
    defer browser.MustClose()
 
    page := browser.MustPage("http://httpbin.org/ip")
    fmt.Println(page.MustElement("body").MustText())
}

PROXY_HOSTPORT có dạng 203.0.113.10:8080 hoặc http://203.0.113.10:8080, không có tài khoản. Với proxy xác thực theo IP, như vậy là đủ.

Không đưa tài khoản vào --proxy-server

Theo tài liệu cài đặt mạng của Chromium, --proxy-server nhận danh sách quy tắc proxy. Chromium không nhận tài khoản trong giá trị này. Viết user:pass@host:port vào Launcher.Proxy sẽ không làm trình duyệt gửi tài khoản. Trong lab DrissionPage cùng ngày, thư viện đó còn chủ động từ chối URL proxy có tài khoản vì cùng lý do: cờ khởi động của Chromium không mang được thông tin xác thực.

Tài khoản proxy phải đi đường khác. Với Rod, đường đó là CDP qua HandleAuth. Bài định dạng proxy giải thích cách tách ip:port:user:pass thành phần địa chỉ và phần tài khoản.

SOCKS5 và danh sách bỏ qua

Vì Launcher.Proxy chỉ đặt cờ, giá trị có thể là socks5://host:port theo cú pháp của Chromium. Chromium gửi tên miền cho proxy SOCKS5 để phân giải. Chromium không hỗ trợ SOCKS5 có tài khoản qua cờ này, và HandleAuth chỉ xử lý thử thách xác thực HTTP, nên SOCKS5 có mật khẩu không dùng được theo cách này.

Danh sách bỏ qua đặt bằng launcher.Set với cờ proxy-bypass-list. Trong lab, mình đặt giá trị <-loopback> để buộc cả địa chỉ cục bộ đi qua proxy, vì mặc định Chromium bỏ qua proxy cho localhost.

u := launcher.New().
    Proxy("127.0.0.1:8942").
    Set("proxy-bypass-list", "<-loopback>").
    MustLaunch()

Bài no_proxy là gì giải thích ý tưởng chung của danh sách bỏ qua.

HandleAuth trong Rod browser proxy

HandleAuth gọi CDP Fetch

Mã của HandleAuth trong tệp hijack.go dùng domain Fetch của CDP và làm năm việc. Bật domain Fetch với handleAuthRequests bằng true. Chờ một sự kiện Fetch.requestPaused rồi cho request đi tiếp bằng Fetch.continueRequest. Chờ một sự kiện Fetch.authRequired. Trả lời bằng Fetch.continueWithAuth với ProvideCredentials, tên và mật khẩu. Cuối cùng tắt Fetch.

Hàm trả về một hàm chờ. Ví dụ trong mã gọi go browser.MustHandleAuth("user", "pass")() để chạy hàm chờ trong một goroutine, trước khi mở trang. Chú thích trong ví dụ ghi dùng mitmproxy với tùy chọn proxyauth để thử.

go browser.MustHandleAuth(os.Getenv("PROXY_USER"), os.Getenv("PROXY_PASS"))()
page := browser.MustPage("https://example.com/")

Tên và mật khẩu là chuỗi riêng trong lệnh CDP, không nằm trong URL, nên không cần mã hóa phần trăm cho ký tự đặc biệt.

Chỉ một lần thử thách

Đọc kỹ mã, HandleAuth chỉ chờ một requestPaused và một authRequired rồi tắt Fetch. Nó không phải trình xử lý chạy suốt phiên. Câu hỏi thực tế là: các trang mở sau đó, khi Fetch đã tắt, có bị proxy hỏi lại và thất bại không.

Đây là chỗ mình dùng mô phỏng. Mình mở Edge với --proxy-server trỏ về proxy cần mật khẩu, bật Fetch với handleAuthRequests, trả tài khoản cho thử thách đầu tiên rồi tắt Fetch ngay, đúng như HandleAuth. Sau đó mở ba trang liên tiếp.

Kết quả: trình duyệt nhớ tài khoản

Tài khoản đi qua CDP

Tài khoản đi qua CDP

Cả ba trang đều mở được, chỉ có một lần authRequired được xử lý. Nhật ký proxy cho thấy request đầu tiên tới trang thứ nhất không có tài khoản và bị trả 407. Request tiếp theo tới cùng trang có tài khoản. Trang thứ hai và thứ ba gửi tài khoản ngay từ đầu dù Fetch đã tắt.

Nghĩa là sau khi nhận tài khoản qua CDP một lần, Edge nhớ tài khoản cho proxy đó và tự gửi tiêu đề Proxy-Authorization cho các request sau trong cùng phiên trình duyệt. Mình chạy thêm một bản giữ Fetch bật suốt phiên, kết quả giống hệt: vẫn chỉ một lần authRequired.

Trong mô phỏng, một lần HandleAuth đủ cho cả phiên trình duyệt với cùng proxy. Với phiên trình duyệt mới, context ẩn danh mới hay proxy khác, cần gọi lại.

Bảng: Kết quả: trình duyệt nhớ tài khoản

Ca mô phỏng

Số lần authRequired

Trang 1, 2, 3

Nhật ký proxy

Trả tài khoản một lần rồi tắt Fetch

1

Đều mở được

Lần đầu 407, sau đó có tài khoản

Giữ Fetch bật suốt phiên

1

Đều mở được

Lần đầu 407, sau đó có tài khoản

Bảng này chỉ đúng với Edge 156 trên Windows và proxy thử Basic. Chrome hay bản khác có thể khác. Hãy kiểm với trình duyệt sẽ dùng thật.

Rod browser proxy dùng HandleAuth một lần cho mỗi phiên trình duyệt và proxy. Trình duyệt tự nhớ tài khoản cho các request sau, ít nhất là với Edge trong lab.

Rủi ro khi dùng HandleAuth cho Rod browser proxy

Goroutine chờ mãi

Hàm chờ của HandleAuth chờ sự kiện requestPaused. Nếu không có request nào được gửi, ví dụ trang mở trước khi goroutine chạy hoặc proxy không đòi tài khoản, goroutine chờ cho tới khi context của Browser kết thúc. Với chương trình chạy lâu, mỗi lần gọi HandleAuth không dùng tới để lại một goroutine treo.

Gọi HandleAuth ngay trước khi mở trang đầu tiên của phiên, và chỉ khi proxy thật sự cần tài khoản. Với proxy xác thực theo IP, bỏ hẳn HandleAuth.

Request đầu bị tạm dừng

Khi Fetch bật, mọi request đều bị tạm dừng chờ client cho đi tiếp. HandleAuth chỉ cho request đầu tiên đi tiếp. Nếu trang mở song song nhiều request ngay lúc đó, các request khác có thể bị giữ tới khi Fetch tắt. Trong lab với trang đơn giản, mình không thấy chậm đáng kể, nhưng với trang nhiều tài nguyên thì cần để ý.

Nếu cần kiểm soát chặt hơn, tự viết trình xử lý bằng proto.FetchEnable với mẫu request giới hạn, xử lý mọi requestPaused và authRequired trong vòng lặp. Đó là cách làm chung khi Rod chưa có tính năng cần thiết, chú thích trong mã cũng khuyên gọi thẳng CDP.

Mật khẩu sai

Với mật khẩu sai, trình duyệt có thể gửi thêm thử thách. HandleAuth đã tắt sau lần đầu, nên thử thách tiếp theo không có ai trả lời, trang báo lỗi xác thực proxy hoặc dừng tải. Ghi log khi trang lỗi kèm URL và kiểm nhật ký proxy để thấy 407. Bài sửa lỗi 407 Proxy Authentication Required liệt kê nguyên nhân phía nhà cung cấp.

Rod browser proxy theo context và nhiều phiên

Một lần, cả phiên

Một lần, cả phiên

Một trình duyệt, một proxy

Cờ --proxy-server áp cho cả tiến trình trình duyệt. Mọi tab, mọi context trong trình duyệt đó dùng chung proxy. Muốn hai proxy, khởi chạy hai trình duyệt với hai launcher khác nhau, mỗi trình duyệt có thư mục dữ liệu riêng.

Chromium có tùy chọn đặt proxy cho từng context qua lệnh tạo context của CDP với tham số proxyServer. Rod có thể gọi thẳng CDP để dùng tính năng này. Mình chưa thử trong lab, và cần kiểm cách xác thực hoạt động với context có proxy riêng.

Thư mục dữ liệu và cookie

Launcher có tùy chọn UserDataDir. Mỗi trình duyệt với một proxy nên có một thư mục dữ liệu riêng. Dùng chung thư mục dữ liệu giữa các proxy làm cookie của phiên này lộ sang phiên kia, website thấy cùng một người đến từ nhiều IP.

Launcher của Rod mặc định có thể tự tải trình duyệt nếu máy chưa có. Với máy chủ không ra Internet trực tiếp, việc tải này cũng cần mạng. Chỉ định đường dẫn trình duyệt có sẵn bằng Bin để không phụ thuộc bước tải.

Kết nối vào trình duyệt có sẵn

Rod có thể kết nối vào trình duyệt đã chạy qua ControlURL. Khi đó proxy là của trình duyệt đã chạy, Launcher.Proxy không có tác dụng. Kiểm trình duyệt đó được khởi chạy với cờ proxy nào trước khi tin rằng request đi qua proxy.

Viết trình xử lý xác thực suốt phiên cho Rod browser proxy

Khi nào cần

HandleAuth đủ cho trường hợp đơn giản. Có ba trường hợp cần trình xử lý chạy suốt phiên. Thứ nhất là trình duyệt không nhớ tài khoản giữa các request. Thứ hai là proxy xoay yêu cầu xác thực lại khi đổi phiên. Thứ ba là chương trình mở nhiều trang song song ngay từ đầu. Trong cả ba, một lần trả lời là không đủ.

Ý tưởng là bật Fetch với handleAuthRequests một lần, rồi lắng nghe liên tục hai sự kiện requestPaused và authRequired. Mỗi requestPaused cho đi tiếp, mỗi authRequired trả tài khoản. Chỉ tắt Fetch khi đóng trình duyệt.

Mã mẫu

Đoạn dưới là ví dụ triển khai dựa trên các kiểu proto mà HandleAuth dùng, mình chưa biên dịch. Kiểm tên hàm EachEvent và chữ ký với bản Rod đang dùng.

func handleAuthForever(b *rod.Browser, user, pass string) {
    _ = proto.FetchEnable{HandleAuthRequests: true}.Call(b)
    go b.EachEvent(
        func(e *proto.FetchRequestPaused) {
            _ = proto.FetchContinueRequest{RequestID: e.RequestID}.Call(b)
        },
        func(e *proto.FetchAuthRequired) {
            _ = proto.FetchContinueWithAuth{
                RequestID: e.RequestID,
                AuthChallengeResponse: &proto.FetchAuthChallengeResponse{
                    Response: proto.FetchAuthChallengeResponseResponseProvideCredentials,
                    Username: user,
                    Password: pass,
                },
            }.Call(b)
        },
    )()
}

Mô phỏng ca Fetch bật suốt phiên trong lab cho thấy cách này chạy với Edge, tuy chỉ có một lần authRequired vì trình duyệt nhớ tài khoản. Lợi ích của nó lộ rõ khi proxy hỏi lại.

Chặn vòng lặp khi mật khẩu sai

Nếu mật khẩu sai, proxy hỏi lại, trình xử lý trả lại cùng mật khẩu sai, và vòng lặp có thể kéo dài. Đếm số lần authRequired cho cùng một request hoặc trong một khoảng thời gian ngắn. Vượt ngưỡng, trả CancelAuth thay vì ProvideCredentials, ghi log lỗi xác thực và dừng phiên.

Với proxy có cơ chế khóa tài khoản sau nhiều lần sai, ngưỡng này bảo vệ tài khoản khỏi bị khóa vì một lỗi cấu hình.

Rod browser proxy với proxy xoay

Một IP cho một trình duyệt

Cờ --proxy-server áp cho cả tiến trình, nên mọi trang trong một trình duyệt đi qua cùng proxy. Với proxy xoay đổi IP theo tên người dùng có mã phiên, mỗi trình duyệt dùng một mã phiên, tức một tài khoản trong HandleAuth. Trình duyệt nhớ tài khoản, nên giữ được cùng phiên proxy suốt thời gian chạy.

Với proxy xoay đổi IP theo thời gian ở phía nhà cung cấp, kết nối giữ lâu của trình duyệt có thể vẫn dùng IP cũ trong khi kết nối mới dùng IP mới. Trang tải nhiều tài nguyên có thể thấy hai IP trong một lần tải, website dễ nghi ngờ. Với luồng cần ổn định, chọn proxy tĩnh hoặc phiên giữ IP đủ dài.

Đổi IP bằng cách khởi chạy lại

Cách chắc nhất để đổi IP với Rod là đóng trình duyệt, khởi chạy lại với tài khoản phiên mới và thư mục dữ liệu mới. Tốn vài giây nhưng không để lại cookie hay kết nối cũ, và website thấy một phiên mới tinh từ IP mới. Với hàng trăm phiên, giữ một bể trình duyệt đang chạy, mỗi trình duyệt một phiên proxy, và quay vòng. Kích thước bể phụ thuộc bộ nhớ của máy và hạn mức kết nối của gói proxy, nên đo trước với vài trình duyệt rồi mới tăng dần.

Rod browser proxy trong Docker và CI

Trình duyệt trong container

Rod có ảnh Docker và có thể tự tải trình duyệt khi chạy. Trong container sau proxy công ty, bước tự tải trình duyệt cũng cần ra Internet. Chỉ định đường dẫn trình duyệt có sẵn trong ảnh bằng Bin của Launcher để không phụ thuộc bước tải lúc chạy.

Biến môi trường HTTP_PROXY trong container không tự áp cho trình duyệt điều khiển bằng Rod, vì Launcher không chuyển nó thành cờ. Đặt proxy bằng Launcher.Proxy từ giá trị đọc trong biến môi trường, như ví dụ ở đầu bài.

Chứng chỉ trong container

Sau proxy kiểm tra TLS của công ty, trình duyệt trong container cần tin CA nội bộ. Thêm CA vào kho chứng chỉ của ảnh hoặc vào kho NSS mà Chromium dùng trên Linux. Đừng chữa bằng bỏ qua lỗi chứng chỉ trên môi trường thật.

Kiểm trong pipeline

Thêm một bước mở trang trả IP qua trình duyệt có proxy, so với IP của máy dựng. Nếu trùng, dừng pipeline. Bước này bắt lỗi quên Launcher.Proxy hay kết nối nhầm vào trình duyệt có sẵn không có proxy.

So sánh Rod browser proxy với Puppeteer

Cùng cơ chế bên dưới

Puppeteer cũng đặt proxy bằng cờ --proxy-server khi khởi chạy và trả tài khoản qua phương thức authenticate của trang, bên dưới cũng dùng Fetch của CDP. Khác biệt là Puppeteer gắn xác thực với từng trang, còn HandleAuth của Rod gắn với Browser và chỉ xử lý một lần.

Hiểu cơ chế chung giúp chuyển kinh nghiệm qua lại. Lỗi URL proxy có tài khoản trong cờ khởi động, lỗi localhost không qua proxy, lỗi SOCKS5 có mật khẩu đều giống nhau giữa hai thư viện, vì chúng đều là hành vi của Chromium.

Kiểm Rod browser proxy bằng nhật ký

Proxy có nhật ký

Cách chắc nhất để biết trình duyệt đi đường nào là cho nó qua một proxy ghi nhật ký. Proxy thử của mình ghi mỗi request kèm đích, có tài khoản hay không, xác thực đạt hay không. Mitmproxy với tùy chọn proxyauth như ví dụ trong mã Rod cũng làm được.

Bộ ca kiểm tối thiểu

  • Không Proxy: trang tới tên chỉ có trong proxy báo lỗi phân giải.
  • Proxy xác thực theo IP: trang mở, nhật ký có request.
  • Proxy cần mật khẩu, không HandleAuth: trang lỗi, nhật ký ghi 407.
  • Proxy cần mật khẩu, có HandleAuth: trang mở, nhật ký có một 407 rồi có tài khoản.
  • Mở thêm trang sau HandleAuth: trang mở, nhật ký có tài khoản ngay.
  • Phiên trình duyệt mới: cần HandleAuth lại.
  • Kiểm IP ra: trang trả IP hiện IP của proxy.

Ca thứ năm xác nhận kết luận mô phỏng trên trình duyệt thật của anh em. Nếu trang thứ hai lỗi, trình duyệt đó không nhớ tài khoản và cần trình xử lý chạy suốt phiên. Ca thứ sáu cho biết khi nào phải gọi lại HandleAuth, ví dụ sau mỗi lần khởi chạy lại để đổi IP. Hai ca này nên nằm trong bộ kiểm chạy mỗi khi nâng bản Rod hoặc nâng trình duyệt, vì cách trình duyệt nhớ tài khoản proxy có thể đổi giữa các bản.

Lưu lượng nền

Nhật ký proxy trong lab cũng ghi nhiều kết nối nền của Edge tới các tên miền của Microsoft và Google: cập nhật, cấu hình, SmartScreen, trang tab mới. Lưu lượng này đi qua proxy và tốn băng thông. Launcher của Rod đặt sẵn một số cờ giảm hoạt động nền, nhưng vẫn nên đọc nhật ký để biết tỷ lệ request nền trên request thật.

Đo hiệu năng Rod browser proxy

Thời gian tải trang qua proxy

Trình duyệt qua proxy chậm hơn đi thẳng vì mỗi tài nguyên của trang đều đi thêm một chặng. Trang có hàng trăm tài nguyên như ảnh, script, font sẽ chịu độ trễ cộng dồn. Đo thời gian từ lúc gọi MustPage tới lúc MustWaitLoad xong, so giữa đi thẳng và qua proxy để biết con số thật.

Với proxy dân cư, độ trễ thường cao hơn proxy datacenter vì đi qua mạng của người dùng cuối. Nếu chỉ cần dữ liệu từ API mà trang gọi, cân nhắc gọi API trực tiếp bằng thư viện HTTP qua proxy thay vì mở cả trình duyệt.

Chặn tài nguyên không cần

Rod có cơ chế chặn bắt request qua HijackRequests. Chặn ảnh, font, video khi chỉ cần văn bản giúp giảm băng thông proxy và giảm thời gian tải. Lưu ý chặn bắt request cũng dùng Fetch của CDP, có thể tương tác với trình xử lý xác thực. Thử kỹ trên proxy có nhật ký khi kết hợp hai cơ chế.

Kết hợp với lưu lượng nền của trình duyệt đã nói ở trên, việc chặn tài nguyên có thể cắt đáng kể số request qua proxy. Đếm số request trong nhật ký trước và sau khi chặn để biết hiệu quả thật.

Lỗi hay gặp với Rod browser proxy

Bảng tra

Bảng: Bảng tra

Hiện tượng

Thường do

Xử lý

Trang vẫn ra IP máy

Launcher.Proxy không được gọi hoặc kết nối vào trình duyệt có sẵn

Kiểm cờ khởi động thật

Trang lỗi ngay với proxy có mật khẩu

Thiếu HandleAuth

Gọi HandleAuth trước trang đầu

URL proxy có user:pass không chạy

Chromium không nhận tài khoản trong cờ

Tách tài khoản ra HandleAuth

Goroutine treo

HandleAuth gọi mà không có request

Chỉ gọi khi proxy cần mật khẩu

Trang thứ hai lỗi xác thực

Trình duyệt không nhớ tài khoản

Trình xử lý Fetch suốt phiên

SOCKS5 có mật khẩu không chạy

Cờ không mang tài khoản SOCKS

Dùng cổng HTTP hoặc xác thực theo IP

localhost không qua proxy

Chromium mặc định bỏ qua loopback

proxy-bypass-list <-loopback>

Lỗi chứng chỉ

Ví dụ trong mã Rod gọi MustIgnoreCertErrors(true) vì dùng mitmproxy, vốn giải mã HTTPS. Với proxy HTTP thông thường kiểu CONNECT, không cần và không nên bỏ qua lỗi chứng chỉ. Chỉ bật bỏ qua khi dùng công cụ kiểm thử chặn bắt HTTPS trên máy lab, không bao giờ trên hệ thống thật.

Đưa Rod browser proxy vào dự án Go

Gom cấu hình

Viết một hàm nhận cấu hình proxy, trả Browser đã kết nối và đã gọi HandleAuth nếu cần. Mã nghiệp vụ chỉ nhận Browser. Đọc địa chỉ và tài khoản proxy từ biến môi trường, không ghi trong mã.

Không in tài khoản ra log. Khi ghi log trang, chỉ ghi URL, trạng thái tải, thời gian và tên máy proxy.

Ghi log mỗi phiên trình duyệt

Mỗi lần khởi chạy trình duyệt, ghi tên máy proxy, mã phiên nếu là proxy xoay, thư mục dữ liệu, cổng điều khiển và IP ra từ trang kiểm IP. Khi một phiên bị website chặn, log này cho biết phiên đó dùng IP nào, từ đó quyết định đổi IP hay đổi cách thao tác. Không ghi mật khẩu proxy vào log, kể cả khi log chỉ lưu trên máy.

Chọn loại proxy

Vì tài khoản đi qua CDP, Rod dùng được proxy HTTP có mật khẩu. Nhưng proxy xác thực theo IP đơn giản hơn: không HandleAuth, không goroutine chờ, không lo trình duyệt có nhớ tài khoản hay không. Với luồng có đăng nhập, chọn proxy tĩnh để giữ IP suốt phiên.

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 trình duyệt điều khiển bằng Rod, anh em có thể mua proxy tại trang chủ ProxyVN rồi chạy bộ ca kiểm ở trên.

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 mở trang, tôn trọng điều khoản của website. Bài headless browser có thêm về đặc điểm của trình duyệt không giao diện.

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

Launcher.Proxy có nhận user:pass không. Không. Nó chỉ đặt cờ --proxy-server, Chromium không nhận tài khoản trong cờ này.

HandleAuth có phải gọi cho mỗi trang không. Trong mô phỏng với Edge, một lần là đủ cho cả phiên với cùng proxy, vì trình duyệt nhớ tài khoản. Kiểm lại với trình duyệt của anh em.

Vì sao HandleAuth treo. Nó chờ request đầu tiên. Nếu không có request nào hoặc proxy không đòi tài khoản, nó chờ mãi.

Dùng hai proxy trong một trình duyệt được không. Cờ áp cho cả tiến trình. Dùng hai trình duyệt, hoặc thử proxy theo context qua CDP.

SOCKS5 có mật khẩu dùng được không. Không qua cờ và HandleAuth. Dùng cổng HTTP hoặc proxy SOCKS5 xác thực theo IP.

Có cần bỏ qua lỗi chứng chỉ không. Không, trừ khi dùng công cụ giải mã HTTPS như mitmproxy trong lab.

Biến HTTP_PROXY có áp cho trình duyệt Rod không. Không tự động. Launcher không chuyển biến môi trường thành cờ. Đọc biến rồi truyền vào Launcher.Proxy.

Có thể chặn tài nguyên để tiết kiệm băng thông proxy không. Có, qua HijackRequests. Thử kỹ khi kết hợp với trình xử lý xác thực vì cả hai cùng dùng Fetch.

Proxy xoay dùng với Rod thế nào. Một trình duyệt cho một phiên proxy. Đổi IP bằng cách khởi chạy lại trình duyệt với phiên mới và thư mục dữ liệu mới, rồi gọi lại HandleAuth.

Checklist Rod browser proxy

Checklist Rod browser proxy

Checklist Rod browser proxy

Trước khi chạy thật

  • Launcher.Proxy với host:port, không kèm tài khoản.
  • HandleAuth trước trang đầu tiên nếu proxy cần mật khẩu.
  • Không gọi HandleAuth thừa để tránh goroutine treo.
  • Một trình duyệt, một proxy, một thư mục dữ liệu.
  • proxy-bypass-list đúng nhu cầu.
  • Không bỏ qua lỗi chứng chỉ trên hệ thống thật.
  • Kiểm IP ra và đọc nhật ký proxy.

Giới hạn của bài

Chương trình Rod chưa được biên dịch vì máy lab không có Go. Bài dựa trên mã nguồn Rod nhánh main, bản v0.116.2, và mô phỏng lệnh CDP Fetch của HandleAuth trên Edge 156 bằng công cụ Python. Chưa thử Chrome, proxy theo context, SOCKS5 và gateway thương mại.

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

Rod browser proxy đặt bằng Launcher.Proxy, tức cờ --proxy-server của Chromium, không mang được tài khoản. Tài khoản đi qua HandleAuth bằng CDP Fetch, trong mô phỏng một lần đủ cho cả phiên. Một trình duyệt một proxy, kiểm bằng nhật ký. Cần proxy ổn định cho Rod browser proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.

Quảng cáo
Xem ngay
TIN TỨC LIÊN QUAN
Kinh Nghiệm Mua Proxy: 12 Điều Cần Hỏi Trước Khi Trả Tiền
Kinh Nghiệm Mua Proxy: 12 Điều Cần Hỏi Trước Khi Trả Tiền
Chuyên viên Kỹ thuật ProxyVN 03-11-2026
Nên Mua Proxy Loại Nào? Bảng Chọn Theo Từng Việc
Nên Mua Proxy Loại Nào? Bảng Chọn Theo Từng Việc
Chuyên viên Kỹ thuật ProxyVN 02-11-2026
Proxy Tĩnh Là Gì? Khi Nào Nên Giữ Một IP Cố Định
Proxy Tĩnh Là Gì? Khi Nào Nên Giữ Một IP Cố Định
Chuyên viên Kỹ thuật ProxyVN 01-11-2026