← Tất cả bài viết

FourA Digest, 14 tháng 8 đến 21 tháng 8, 2026

Quản lý tổ chức hiệu quả hơn, Proxy Finder xác định chính xác điểm chặn và Trình duyệt ngừng trả về hai kết quả trái ngược cho cùng một trang.

Điểm nổi bật

Trước đây, một tổ chức chỉ là một hàng dữ liệu chứa duy nhất một người. Giờ đây, đó là một trang quản lý hoàn chỉnh: mời đồng nghiệp, phân vai trò, cho phép họ tạo API key do công ty thanh toán. Proxy Finder cũng không còn trả về lỗi "out of tries" chung chung mà bắt đầu chỉ rõ rào cản gặp phải, và Browser đã được tối ưu để đảm bảo tính nhất quán tuyệt đối trong thông tin gửi tới trang web.

Tính năng mới

Quản lý tổ chức linh hoạt

Trước đây, muốn thêm đồng nghiệp bạn phải gửi email cho chúng tôi, dẫn đến việc các nhóm thường phải mua hai gói thuê bao riêng biệt.

Hiện tại, tổ chức của bạn đã có trang riêng trong Dashboard với ba vai trò rõ ràng. Owner nắm giữ gói thuê bao dùng để tính phí cho các API key, vì vậy chỉ có duy nhất một Owner và quyền này thay đổi thông qua chuyển giao. Admin quản lý lưu lượng, thanh toán và thành viên. Member sử dụng dịch vụ. Lời mời được gửi qua địa chỉ email và áp dụng được cho cả người chưa từng đăng ký tài khoản.

Bất kỳ ai trong tổ chức cũng có thể tạo API key thuộc sở hữu của tổ chức và chuyển API key cá nhân vào đó, giúp lập trình viên không phải dùng API key cá nhân trả phí cho công việc của công ty. Lưu lượng sử dụng trên API key của tổ chức sẽ tính vào gói của Owner, và mỗi thông báo xác nhận đều nêu rõ gói của ai đang thanh toán. Mọi Member đều có thể đổi tên API key; các thao tác tạo lại, vô hiệu hóa và xóa vẫn thuộc quyền của Owner và Admin, vì những thao tác này sẽ lập tức ảnh hưởng đến tất cả đồng nghiệp đang sử dụng.

Bộ lọc Owner áp dụng xuyên suốt Overview, Detailed Metrics, Recent Activity và danh sách API key của bạn. Usage & Limits và Billing vẫn giữ tính riêng tư, vì Member không cần xem hạn ngạch của Owner.

Proxy Finder xác định lỗi chính xác

Lỗi "Download maxTry limit reached" trước đây hiển thị giống nhau trong mọi trường hợp, dù là mọi exit node bị chặn, mọi exit node bị chết, hay chúng tôi đã tải đúng trang thực tế nhưng rule của bạn tự loại bỏ nó. Ba trường hợp này đòi hỏi các cách xử lý hoàn toàn trái ngược nhau.

Một task thất bại giờ đây sẽ kèm theo attemptReport: bao nhiêu exit node không phản hồi, bao nhiêu exit node bị hệ thống phòng thủ nhận diện từ chối kèm tên nhà cung cấp cụ thể, bao nhiêu exit node bị validate.status của bạn từ chối, và bao nhiêu exit node trả về HTTP 200 không hề có dấu hiệu bị chặn nhưng lại không vượt qua validate.data của bạn. Đi kèm với đó là một câu tóm tắt rõ ràng.

Số liệu cuối cùng đó là quan trọng nhất. Một rule nội dung không thể khớp trông hoàn toàn giống như việc bị chặn từ mọi góc độ theo cách đo trước đây của chúng tôi, và không một lần retry nào có thể khắc phục được. (Xem thêm về cách validate rule xác định thành công.)

Phần còn lại nằm ở profile. Trước đây, Proxy Finder luân chuyển exit node nhưng giữ nguyên client signature, do đó trang web từ chối một browser profile sẽ tiếp tục từ chối nó ở mọi exit node trong pool. Hiện tại, khi gặp lỗi từ chối, hệ thống sẽ tự động đổi profile trong lần retry tiếp theo, do đó số lượng request và credit trên mỗi task không thay đổi. Nếu bạn tự ghim profile thì cấu hình sẽ được giữ nguyên. Lưu ý rằng với các mục tiêu phức tạp nhất, exit node bạn kết nối tới vẫn quan trọng hơn profile bạn gửi đi.

Browser duy trì tính nhất quán

Yêu cầu Browser cung cấp User-Agent trước đây từng tệ hơn là không yêu cầu. Ba tầng hệ thống đều có nhận diện riêng về đối tượng gửi request, dẫn đến một request có thể đồng thời khai báo là Windows, Mac và một phiên bản mà hạ tầng fleet không hề chạy. Hiện tại chỉ còn một giá trị duy nhất, được xác định một lần và áp dụng đồng bộ khắp nơi: khi khởi chạy, trên trang, và trong các worker do trang khởi tạo.

Client hints được tạo ra từ chuỗi đó, giúp sec-ch-ua, platform và navigator.platform đồng nhất với nhau. Response trả về chính xác chuỗi mà chúng tôi đã gửi đi, điều này rất quan trọng vì clearance cookie được liên kết đồng thời với exit node và User-Agent. Câu lệnh truy vấn renderer hiện cũng trả về kết quả đồng nhất trong document và trong worker, giải quyết thêm một trong những tín hiệu nhỏ nhưng cộng dồn tạo nên khác biệt.

Ba cập nhật khác cũng được phát hành cùng đợt:

  • Đồng hồ đồng bộ theo exit node. Browser hoạt động theo múi giờ của quốc gia đặt exit node của bạn, nhờ đó trang hiển thị giờ địa phương đúng như trải nghiệm của người dùng tại đó. Nếu không xác định được quốc gia, đồng hồ sẽ giữ nguyên mặc định.
  • WebRTC đi cùng tuyến kết nối với mọi lưu lượng khác. Cấu hình proxy áp dụng cho dữ liệu browser gửi qua TCP. WebRTC không nằm trên tuyến đó, nên trang yêu cầu ICE candidates từ WebRTC sẽ nhận phản hồi riêng biệt. Browser sẽ tắt cơ chế này mỗi khi request có chỉ định exit node.
  • URL chứa anchor xử lý đúng thời gian cần thiết. URL kết thúc bằng #reviews trước đây thường làm hết thời gian chờ (run the clock out) mỗi lần xử lý. Hiện tại tốc độ đã trở lại bình thường.

Định tuyến tối ưu chi phí hơn và Dashboard thống kê chính xác

Imperva chèn script vào cả các trang hoạt động bình thường chứ không chỉ các trang từ chối truy cập, và Auto không phân biệt được hai loại này, khiến các trang bình thường bị nâng cấp lên browser không cần thiết. Trên một trang web cho thuê xe, quá trình này từng tốn 75 credit và 27.5 giây qua sáu lần thử; hiện tại chỉ mất một lần thử, 10 credit và khoảng sáu giây rưỡi. Một số trang trả về phiên làm việc (session) ngay trong thông báo từ chối đối với request không có session, và hiện tại cả bốn engine đều gửi lại session này trước khi nâng cấp browser.

Thẻ credit trên trang Overview trước đây hiển thị toàn bộ mức tiêu hao và gán nhãn là billed (đã tính tiền). Theo mô hình chỉ tính tiền khi thành công (pay-for-success), hai giá trị này khác nhau và phần chênh lệch là chi phí thực tế. Vì vậy, cả hai giá trị đều được đưa lên thẻ: billed là con số chính, spent (thực tế tiêu hao) nằm bên dưới, chi tiết theo từng sản phẩm và tổng cộng. Thẻ Requests cũng phân tách tương tự. Khoảng thời gian và mức độ chi tiết là hai bộ lọc riêng biệt, từ 30 phút đến một năm cùng với khoảng thời gian tùy chỉnh, thay thế nút trước đây ghi "1D" nhưng lại mở ra ba mươi ngày.

Trong Playground, nút carry hiện cung cấp profile từ response gần nhất, giúp request chạy với profile bạn không tự nhập có thể phát lại đúng phiên bản đã hoạt động. Mọi tham số đều có trong tài liệu API.

Chi tiết kỹ thuật

Proxy Finder lưu nhiều lịch sử hơn cho mỗi host: 32 exit thay vì một tá. Trên thử nghiệm A/B trực tiếp, nó tương đương ở các mục tiêu dễ và tốt hơn ở các mục tiêu khó, nơi thời gian trung vị để tải một trang giảm từ 5.5s xuống 3.8s trong khi độ trễ trên toàn bộ hệ thống không thay đổi. Một mục tiêu có xu hướng ngược lại và chúng tôi vẫn chưa rõ nguyên nhân, vì vậy mục tiêu này được theo dõi riêng.

Một tác vụ chắc chắn thất bại thì đằng nào cũng sẽ thất bại. Điểm khác biệt là bạn đóng ticket trong một phút hay dành cả buổi chiều để đo lường sai thứ.