Đ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. Bây giờ đó là một trang bạn quản lý: mời đồng nghiệp, phân quyền cho họ, để họ tạo key do công ty thanh toán. Proxy Finder cũng không còn trả lời "out of tries" chung chung mà bắt đầu chỉ rõ chướng ngại vật gặp phải, và Browser đã hoàn thiện để đảm bảo gửi cùng một thông tin nhất quán đến trang web hai lần liên tiếp.
Có gì mới
Quản lý tổ chức thực sự hiệu quả
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 phải mua hai gói thuê bao riêng biệt.
Giờ đây, tổ chức của bạn có trang riêng trong Dashboard với ba vai trò phân quyền. Owner nắm giữ gói thuê bao dùng để tính phí cho các key, vì vậy chỉ có đúng một Owner và quyền sở hữu được chuyển giao trực tiếp. Admin quản lý lưu lượng sử dụng, thanh toán và thành viên. Member trực tiếp sử dụng hệ thống. 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 key thuộc tổ chức và chuyển key cá nhân vào đó, nhờ vậy lập trình viên không cần dùng key cá nhân tự trả tiền cho công việc của công ty. Lưu lượng sử dụng trên 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 ghi rõ gói của ai đang thanh toán. Mọi Member đều có thể đổi tên 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ẽ chặn ngay lập tức mọi đồng nghiệp đang sử dụng key đó.
Bộ lọc Owner duy nhất hoạt động xuyên suốt Overview, Detailed Metrics, Recent Activity và danh sách key của bạn. Mục Usage & Limits cùng với Billing vẫn ở chế độ cá nhân, vì Member không có quyền xem hạn mức của Owner.
Proxy Finder không còn phỏng đoán
Thông báo "Download maxTry limit reached" trước đây hiển thị giống nhau cho dù mọi exit node bị chặn, mọi exit node đều chết, hay chúng tôi đã tải đúng trang thực tế nhưng quy tắc của bạn lại loại bỏ nó. Ba trường hợp này cần các cách xử lý hoàn toàn trái ngược nhau.
Một task thất bại hiện sẽ mang theo attemptReport: bao nhiêu exit node không bao giờ 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 có dấu hiệu phòng thủ nhưng chỉ thất bại ở validate.data của bạn. Một câu tóm tắt rõ ràng cũng được đính kèm.
Tuy nhiên, chỉ số cuối cùng mới là điều đáng giá. Một quy tắc nội dung không khớp nhìn từ mọi góc độ chúng tôi từng đo lường đều giống hệt như bị chặn, và không một lần retry nào có thể khắc phục được. (Xem thêm về cách quy tắc validate xác định thành công.)
Phần còn lại nằm ở profile. Trước đây Proxy Finder chỉ luân chuyển exit node chứ không đổi chữ ký client, vì vậy một trang web từ chối một profile trình duyệt sẽ từ chối nó ở mọi exit node trong pool. Hiện tại, khi bị từ chối, profile sẽ được chuyển đổi trong lượt retry vốn có, do đó số request và credit trên mỗi task không thay đổi. Nếu bạn tự ghim profile, mọi thứ vẫn giữ nguyên. Lưu ý rằng trên những mục tiêu khó nhất, exit node bạn kết nối đến vẫn quan trọng hơn profile bạn gửi đi.
Browser chấm dứt tình trạng mâu thuẫn dữ liệu
Yêu cầu Browser cung cấp User-Agent trước đây còn tệ hơn là không yêu cầu. Ba lớp khác nhau đều có định danh riêng về request, khiến một request có thể vừa nhận là Windows, vừa là Mac, lại vừa mang phiên bản mà hệ thống hoàn toàn không chạy, tất cả cùng một lúc. Giờ đây chỉ còn một giá trị duy nhất, được xác định một lần và áp dụng xuyên suốt: lúc khởi chạy, trên trang và trong các worker do trang tạo ra.
Client hints được tạo từ chuỗi đó, giúp sec-ch-ua, platform và navigator.platform hoàn toàn khớp với nhau. Response trả về chính xác chuỗi đã gửi, điều này rất quan trọng vì các clearance cookie được liên kết đồng thời với exit node và User-Agent. Cơ chế renderer hiện cũng phản hồi nhất quán giữa document và worker, xử lý thêm một trong những tín hiệu nhỏ tích tụ lại.
Ba cập nhật khác đi kèm:
- Đồng hồ đồng bộ theo exit. Browser chạy theo múi giờ của quốc gia chứa exit node của bạn, nhờ đó trang hiển thị thời gian cục bộ đúng như khách truy cập tại đó nhìn thấy. Khi không xác định được quốc gia, đồng hồ giữ nguyên mặc định.
- WebRTC đi cùng tuyến với mọi lưu lượng khác. Cấu hình proxy áp dụng cho dữ liệu trình duyệt gửi qua TCP. WebRTC không nằm trên tuyến đó, nên trang yêu cầu ICE candidate sẽ nhận phản hồi riêng biệt. Browser sẽ tắt tính năng này mỗi khi request có chỉ định exit.
- URL chứa anchor xử lý đúng thời gian chuẩn. URL kết thúc bằng
#reviewstrước đây luôn làm cạn kiệt thời gian chờ. Hiện tại tốc độ đã trở lại bình thường.
Định tuyến tiết kiệm hơn, Dashboard thống kê chuẩn xác
Imperva chèn script vào cả các trang bình thường chứ không chỉ trang chặn, và Auto trước đây không phân biệt được hai loại này, khiến các trang bình thường bị chuyển hướng vô ích lên trình duyệt đầy đủ. Trên một trang thuê xe, thao tác đó từng tốn 75 credit và 27,5 giây qua sáu lần thử; hiện tại chỉ cần một lần thử, 10 credit, mất khoảng sáu giây rưỡi. Một số trang trả về session ngay trong thông báo từ chối của request chưa có session, và cả bốn engine hiện đều gửi lại session đó trực tiếp trước khi nâng cấp giải pháp.
Thẻ credit trên Overview trước đây hiển thị toàn bộ chi phí sử dụng và gắn nhãn đã tính phí. Với cơ chế chỉ trả phí khi thành công, hai con số này khác nhau và chênh lệch đó là chi phí thực tế, vì vậy cả hai hiện đều hiển thị trên thẻ: số tiền đã tính phí ở mục chính, chi phí thực tế bên dưới, theo từng sản phẩm và theo tổng số. Thẻ Requests cũng được phân tách tương tự. Khoảng thời gian và mức độ chi tiết giờ là hai bộ điều khiển riêng biệt, từ 30 phút đến một năm cùng tùy chọn tùy chỉnh, thay thế nút chọn hiển thị "1D" nhưng lại mở ra ba mươi ngày.
Trong Playground, nút carry hiện cho phép chọn profile từ response gần nhất, giúp request gửi đi bằng profile bạn không tự nhập có thể phát lại đúng phiên bản đã chạy thành công. Mọi tham số đều có trong API reference.
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 thực tế, kết quả ngang bằ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 latency trên toàn bộ fleet không đổi. Một mục tiêu có diễn biến ngược lại và chúng tôi vẫn chưa rõ lý do, nên nó được đo lường riêng.
Một task sắp thất bại thì đằng nào cũng sẽ thất bại. Khác biệt là bạn đóng ticket trong một phút hay mất cả buổi chiều để đo lường sai thứ.