Quay lại blog

Bốn loại trình duyệt: cục bộ, antidetect, đám mây và tự động hóa

Có thể chia trình duyệt thành bốn nhóm thực tế: trình duyệt cục bộ, antidetect, điện thoại/trình duyệt đám mây và trình duyệt chuyên cho tự động hóa. Hãy quyết định cách quản lý danh tính trước, rồi mới quyết định công việc sẽ chạy ở đâu.

Khi chọn trình duyệt, câu hỏi ban đầu thường bị đặt sai: loại nào tốt hơn? Một câu hỏi hữu ích hơn là: tôi cần làm công việc gì trong trình duyệt này? Nếu chia theo chức năng, có bốn nhóm thực tế: trình duyệt thông thường trên máy cục bộ, trình duyệt antidetect phục vụ danh tính tài khoản, điện thoại hoặc trình duyệt chạy trên đám mây, và trình duyệt chuyên cho tự động hóa bằng scripts và AI.

Trình duyệt cục bộ: đơn giản nhất nhưng cũng sớm chạm giới hạn

Đối với duyệt web hằng ngày, tìm kiếm thông tin và đăng nhập một vài tài khoản của chính bạn, trình duyệt cục bộ là lựa chọn đơn giản nhất. Cài một tiện ích quyền riêng tư, tắt đồng bộ không cần thiết, chi phí bổ sung gần như bằng không.

Vấn đề xuất hiện khi số lượng tài khoản tăng lên. Nhiều profile có thể tách Cookie, nhưng đặc tính nền của thiết bị vẫn giống nhau. Proxy thường chỉ được cấu hình ở cấp toàn cục, khó gán một lối ra riêng cho từng profile. Khi profile nhiều, thiếu group và label cũng khiến việc quản lý trở nên bất tiện. Quan trọng hơn là tính nhất quán của danh tính: nếu nhiều tài khoản tập trung trên một máy và một environment, phía nền tảng có thể nhìn chúng giống hoạt động từ cùng một người vận hành hơn.

Những công cụ này được thiết kế để làm tracking khó hơn bằng cách tăng randomness và giảm entropy của fingerprint. Công việc đa tài khoản lại cần điều ngược lại: ổn định dài hạn và các tham số nhất quán với nhau. Mục tiêu trái ngược nên hai cách không thể thay thế nhau.

Trình duyệt antidetect: một danh tính nhất quán cho mỗi tài khoản

Trình duyệt antidetect tạo một environment độc lập cho từng tài khoản. Các tham số fingerprint được sinh theo một bộ và sau đó giữ ổn định, bao gồm IP, múi giờ, User-Agent, Canvas, WebGL, audio fingerprint, font fingerprint và ID thiết bị media. Cookie và local storage được cách ly với nhau. Sau khi environment được tạo, tham số không đổi, vì vậy lần đăng nhập sau vẫn trông như cùng một thiết bị.

Proxy được gắn theo từng environment, giúp mỗi environment có lối ra riêng và hỗ trợ các giao thức phổ biến như HTTP, HTTPS và SOCKS5. Sau khi gắn Proxy, múi giờ và ngôn ngữ cũng có thể được điều chỉnh cho khớp, tránh những điểm bất hợp lý như IP ở Mỹ nhưng ngôn ngữ và múi giờ lại thuộc nơi khác. Nền tảng không bao giờ đánh giá một environment có giống người dùng thật hay không chỉ dựa trên IP.

Khả năng quản lý là nửa giá trị còn lại: group, label, ghi chú, nhập/xuất hàng loạt, thay đổi cấu hình hàng loạt và bật/tắt hàng loạt. Environment cũng có thể được tạo và recycle qua API để scripts và AI gọi trực tiếp.

Giới hạn cũng cần nói rõ. Loại này không dành cho việc duyệt web hằng ngày thông thường, đồng thời phức tạp và tốn kém hơn. Một vấn đề dài hạn khác dễ bị bỏ qua là browser core có theo kịp tốc độ cập nhật hệ thống kiểm soát rủi ro của nền tảng hay không. Khi lựa chọn, nên đọc changelog để xem họ mô tả thay đổi cụ thể hay chủ yếu dùng các câu chữ chung chung.

Điện thoại và trình duyệt đám mây: chuyển thiết bị lên cloud

Hai nhóm này đều chuyển nơi thực thi từ máy cục bộ lên đám mây. Điện thoại đám mây cung cấp mobile device từ xa, phù hợp với tình huống cần environment giống thiết bị thật hoặc cần cài App. Trình duyệt đám mây cung cấp browser instance từ xa, giúp máy cục bộ không phải gánh tải bộ nhớ và tính toán.

Đổi lại, chi phí rất trực tiếp: tính phí theo thời gian, nên chạy càng lâu và càng nhiều instance thì hóa đơn tăng gần tương ứng. Việc truyền dữ liệu qua lại trên mạng gây latency, không thân thiện với các tác vụ cần tương tác chính xác, và tài liệu cục bộ phải được upload trước. Bù lại, có thể truy cập thuận tiện từ nhiều thiết bị và địa điểm, đồng thời nhiều thành viên trong nhóm có thể kết nối vào cùng một cloud device.

Một điểm nữa thường bị bỏ qua: cloud instance thường chỉ là nơi thực thi. Account identity không tự xuất hiện ở đó, vì vậy identity management và isolation vẫn phải được thiết kế riêng.

Trình duyệt tự động hóa: executor cho scripts và AI

Loại trình duyệt này chỉ có một mục tiêu: thực thi workflow tốt. Nó hỗ trợ programmatic control, có thể kết nối với external framework qua giao thức CDP và cũng có thể được AI tools gọi qua interface để thao tác trang, chụp ảnh màn hình, đọc nội dung và điền biểu mẫu.

Nó phù hợp với thu thập dữ liệu, regression testing và các hành động lặp lại hàng loạt. Bản thân nó không mang account identity. Trong tình huống đa tài khoản, cách thường dùng là nối nó với một isolated environment có sẵn: execution thuộc execution layer, còn identity thuộc identity layer.

Giới hạn là không có business judgment. Nếu trang được thiết kế lại hoặc một element biến mất, script có thể thất bại. Vẫn cần con người đưa ra quyết định trước khi chạy và xử lý ngoại lệ sau đó.

Đi theo đặc điểm của tác vụ

Trước hết, hỏi xem có cần duy trì nhiều account identity ổn định trong thời gian dài hay không. Nếu có, hãy xem xét trình duyệt antidetect. Nếu không, tiếp tục.

Tiếp theo, hỏi có yêu cầu bắt buộc về environment thiết bị thật hoặc mobile App hay không. Nếu có, xem điện thoại đám mây. Nếu chỉ muốn chuyển tải khỏi máy cục bộ, xem trình duyệt đám mây.

Sau đó, hỏi tác vụ có do scripts hoặc AI điều khiển và lặp đi lặp lại cùng một workflow hay không. Nếu có, dùng trình duyệt tự động hóa, đồng thời để account identity cho environment layer quản lý và kết nối executor vào đó.

Nếu cả ba điều kiện đều không đúng, trình duyệt cục bộ cùng thiết lập quyền riêng tư là đủ. Không cần dùng công cụ nặng hơn.

按多身份、移动应用、云端算力和脚本或 AI 工作流要求选择指纹浏览器、云手机、云浏览器、自动化浏览器或本地浏览器

Trong dự án thực tế, các nhóm này thường được kết hợp: trình duyệt antidetect quản lý identity ở environment layer, trình duyệt automation chạy workflow ở execution layer, còn phần cần thiết bị thật hoặc truy cập từ xa được đưa lên cloud. Trong các tình huống đa tài khoản ở quy mô lớn, công cụ quản lý environment như PurpleMark đảm nhiệm đúng lớp này, tách identity và session của từng tài khoản để executor ở lớp trên có thể điều khiển.

Tóm lại trong một câu: trước hết quyết định cách quản lý identity, sau đó quyết định công việc sẽ chạy ở đâu.