Giải thích URL proxy tự động: Thiết lập tệp PAC và WPAD

URL proxy tự động trỏ đến một tệp PAC, một tập lệnh nhỏ thường có tên là proxy.pac, quyết định với mỗi yêu cầu rằng sẽ kết nối trực tiếp hay thông qua proxy. Phương pháp này bắt nguồn từ thiết kế trình duyệt năm 1996 của Netscape, nhằm tự động chọn cách định tuyến.

Có lẽ bạn đã từng gặp tình huống trục trặc này. Một người trong nhóm dán cấu hình vào trình duyệt, kiểm tra trên trang tra cứu IP, thấy quốc gia như mong đợi rồi tuyên bố đã xong. Vài giờ sau, quy trình QA hiển thị giá theo khu vực địa phương, một lượt kiểm tra quảng cáo trả về mẫu quảng cáo không đúng hoặc một lệnh gọi API chạy nền để lộ mạng văn phòng của bạn. Cấu hình có vẻ đúng, nhưng không phải toàn bộ lưu lượng đều đi theo cấu hình đó. Khoảng cách này là nguyên nhân gây ra phần lớn sự nhầm lẫn, bởi URL proxy tự động thực ra không phải là địa chỉ định tuyến lưu lượng. Đó là địa chỉ để đưa ra quyết định.

URL proxy tự động thực sự trỏ đến đâu

Trưởng nhóm xác minh quảng cáo của bạn mở một trình duyệt thử nghiệm ở Lyon và thấy chiến dịch hiển thị đúng như cách người dùng di động tại Pháp sẽ thấy. Một đồng nghiệp kiểm tra tương tự từ máy tính xách tay khác nhưng lại nhận được trang toàn cầu mặc định. Cả hai đều quả quyết rằng mình đã dùng “proxy”. Trên thực tế, một thiết bị đã tải tập lệnh định tuyến và áp dụng tập lệnh đó, còn thiết bị kia vẫn dùng cấu hình thủ công hoặc chưa bao giờ tải tập lệnh.

Đó là điểm khác biệt cốt lõi. Cấu hình proxy thông thường trỏ đến một máy chủ, chẳng hạn như máy chủ và cổng. URL proxy tự động trỏ đến một tệp Cấu hình Tự động Proxy, thường được gọi là proxy.pac, mà trình duyệt hoặc hệ điều hành tải xuống và chạy. Hãy hình dung proxy cố định như một con đường bạn luôn đi qua. Tệp PAC giống ứng dụng chỉ đường hơn, tính lại lộ trình cho mỗi chuyến đi dựa trên điểm đến.

Vì sao cần tập trung hóa quyết định

Hệ thống này dựa trên phương thức Cấu hình Tự động Proxy, ban đầu được Netscape thiết kế năm 1996 cho Netscape Navigator 2.0. Tệp PAC chứa một hàm JavaScript có tên FindProxyForURL(url, host), quyết định mỗi yêu cầu sẽ đi trực tiếp hay qua một hoặc nhiều proxy, như mô tả trong hướng dẫn về tệp PAC của Mozilla. Sau đó, Lực lượng Đặc nhiệm Kỹ thuật Internet đã ghi lại PAC trong RFC 3040 vào tháng 1 năm 2001.

Lịch sử đó không chỉ là chuyện bên lề. RFC 3040 ghi nhận PAC giúp đơn giản hóa việc quản trị bằng cách tập trung chính sách proxy vào một tập lệnh, nhờ đó quản trị viên có thể cập nhật tập lệnh thay vì cấu hình lại thủ công từng tác nhân người dùng. RFC cũng cảnh báo khả năng tương tác chưa hoàn hảo vì các trình duyệt có thể diễn giải cùng một tập lệnh theo những cách khác nhau.

URL proxy tự động hợp lệ chứng minh rằng thiết bị có thể tải hướng dẫn định tuyến. Điều đó không chứng minh mọi ứng dụng trên thiết bị đều tuân theo các hướng dẫn này.

Khi dán URL đó vào màn hình cài đặt, bạn không chọn một máy chủ thoát duy nhất. Bạn đang chọn ai sẽ quyết định điểm thoát cho từng yêu cầu và bạn có thể thay đổi quyết định đó cho mọi người nhanh đến đâu mà không cần tự tay thao tác trên từng máy tính xách tay, điện thoại hay hồ sơ trình duyệt.

Cách tệp PAC quyết định nơi từng yêu cầu được gửi đến

Hãy theo dõi một yêu cầu. Trình duyệt muốn mở một trang sản phẩm. Trước khi mở kết nối, trình duyệt chuyển URL và máy chủ đến FindProxyForURL(url, host). Hàm này đánh giá các quy tắc đơn giản và trả về chỉ thị như DIRECT hoặc một proxy được chỉ định tên, đôi khi kèm theo các proxy dự phòng để trình duyệt thử nếu proxy đầu tiên gặp lỗi.

Một ví dụ đơn giản sẽ giúp bạn dễ hình dung. Các công cụ nội bộ có thể trả về DIRECT vì chúng đã nằm trong mạng của bạn. Các mục tiêu nghiên cứu công khai có thể trả về proxy với vị trí bạn cần. Proxy thứ hai trong danh sách được trả về đóng vai trò dự phòng, chứ không phải là chặng thứ hai cho cùng một yêu cầu.

Giới hạn của bộ nhớ đệm theo tên máy chủ

Đừng cho rằng bạn có thể định tuyến khác nhau cho mọi đường dẫn. Hướng dẫn hiện hành lưu ý rằng kết quả proxy tự động được lưu vào bộ nhớ đệm theo tên máy chủ, điều này hạn chế khả năng chọn proxy dựa trên đường dẫn URL hoặc các thành phần URL khác. Trên thực tế, hai trang trên cùng một máy chủ thường sẽ dùng lại cùng một kết quả định tuyến, ngay cả khi bạn muốn đường dẫn thanh toán hoạt động khác với trang chủ.

Điều gì thay đổi với HTTPS

URL proxy tự động không làm thay đổi ngữ nghĩa đường hầm HTTP. Với các đích đến HTTPS, một ứng dụng tuân thủ tiêu chuẩn sẽ kết nối đến proxy được cấu hình và gửi lệnh CONNECT destination-host:port. Sau khi nhận được phản hồi thành công, proxy chỉ chuyển tiếp các byte đã mã hóa một cách thụ động, trong khi TLS vẫn được mã hóa đầu cuối giữa máy khách và đích đến, theo quy định trong ngữ nghĩa HTTP trong RFC 9110.

Phân biệt được điều này sẽ tiết kiệm thời gian khắc phục sự cố:

• 400 Bad Request: Cổng tường minh trong CONNECT là bắt buộc; yêu cầu có cổng không hợp lệ hoặc để trống cần bị từ chối theo cách này.
• 407 Proxy Authentication Required: Proxy cần thông tin xác thực và trả về một thử thách Proxy-Authenticate.
• CONNECT thành công nhưng TLS thất bại: Đường hầm đã được mở, vì vậy hãy kiểm tra bước bắt tay với đích đến thay vì đổ lỗi cho băng thông proxy.
• CONNECT liên tục thất bại: Trước tiên, hãy kiểm tra thông tin xác thực, danh sách cho phép, cổng hoặc chính sách dành cho đích đến.

Một URL proxy bắt đầu bằng ` vẫn có thể truyền lưu lượng HTTPS thông qua CONNECT. Điều đó không có nghĩa proxy có thể xem nội dung trang đã mã hóa. Hãy đo riêng thời gian phân giải DNS, thời gian kết nối TCP, tỷ lệ CONNECT thành công, độ trễ bắt tay TLS và thông lượng duy trì, nếu không bạn sẽ xử lý nhầm tầng.

Lưu trữ tệp PAC và giúp máy khách tìm thấy tệp

Tập lệnh của bạn có thể hoàn hảo về mặt logic nhưng vẫn vô dụng nếu thiết bị không thể tải được. Lưu trữ là công việc hạ tầng không mấy hấp dẫn, nhưng chính tại đây các nhóm có thể đạt được khả năng cập nhật dễ dàng hoặc tạo ra một điểm lỗi đơn âm thầm.

Đặt proxy.pac trên máy chủ web mà mọi thiết bị mục tiêu đều có thể truy cập mà không cần dùng chính proxy bạn đang cố cấu hình. Đây là cái bẫy thường gặp với nhân viên làm việc từ xa. Nếu máy tính xách tay phải dùng proxy để truy cập tệp PAC, trong khi lại cần tệp PAC để biết proxy cần dùng, thiết bị sẽ không thể khởi động quy trình.

Hai cách để máy khách tìm thấy tập lệnh

Cách khai báo tường minh dễ hiểu nhất. Quản trị viên hoặc người dùng nhập trực tiếp URL proxy tự động vào cài đặt hệ thống hoặc trình duyệt. Bạn biết chính xác thiết bị cần tải tập lệnh nào và có thể kiểm tra cùng URL đó từ một thiết bị sạch trên cùng mạng.

Cách tự động là WPAD, viết tắt của Web Proxy Auto-Discovery (Tự động khám phá Proxy Web). Máy khách tìm vị trí wpad.dat thông qua DNS hoặc DHCP, sau đó tải cấu hình từ đó. WPAD giảm bớt việc thiết lập thủ công cho mạng văn phòng được quản lý, nhưng khiến việc kiểm soát tên máy chủ trở nên quan trọng hơn. Nếu máy chủ không đúng phản hồi tên WPAD, thiết bị có thể được điều hướng đến các hướng dẫn định tuyến mà bạn không công bố.

Quy tắc thực tế: Ưu tiên URL proxy tự động được khai báo tường minh nếu bạn không thể kiểm soát hoàn toàn DNS và DHCP trên mọi mạng mà thiết bị của mình kết nối.

Các thay đổi cũng không được áp dụng ngay lập tức. Máy khách chỉ áp dụng phiên bản mới khi tải lại tệp, điều này có thể phụ thuộc vào bộ nhớ đệm, việc kết nối lại hoặc khởi động lại ứng dụng. Đừng chỉnh sửa quy tắc trên môi trường thực tế vài phút trước khi kiểm tra chiến dịch rồi cho rằng mọi thiết bị đã có hành vi mới.

Danh sách kiểm tra lưu trữ nhanh

• Lưu tệp trong hệ thống quản lý phiên bản: Xem xét các thay đổi định tuyến như xem xét mã, vì chỉ một quy tắc sai cũng có thể khiến lưu lượng cần đi trực tiếp lại qua proxy hoặc ngược lại.
• Giới hạn người có thể đăng tải: Bất kỳ ai có thể thay thế tệp PAC đều có thể tác động đến nơi lưu lượng trình duyệt được gửi đến.
• Dùng URL ổn định: Thay đổi vị trí đồng nghĩa với việc phải cấu hình lại máy khách, làm mất đi lợi ích của các bản cập nhật tập trung.
• Duy trì một URL kiểm tra: Mở URL đó từ một thiết bị sạch bên ngoài mạng quản trị và xác nhận tập lệnh mong đợi được tải.
• Giữ cho quy tắc dễ đọc: Việc khắc phục sự cố trong tương lai sẽ khó hơn nếu không ai biết vì sao một máy chủ lại bị buộc đi trực tiếp từ nhiều tháng trước.

Thiết lập URL proxy tự động trên các nền tảng phổ biến

Hãy bắt đầu bằng một quyết định trước khi mở bất kỳ menu nào. Bạn muốn áp dụng định tuyến này cho toàn bộ thiết bị hay chỉ cho một hồ sơ trình duyệt dùng trong một tác vụ cụ thể? Người quản lý mạng xã hội kiểm tra nội dung theo khu vực có thể cần một hồ sơ riêng biệt. Thiết bị QA kiểm thử toàn bộ hành trình người dùng thường cần hành vi ở cấp hệ thống, với lưu ý rằng không phải ứng dụng nào cũng tuân theo thiết lập này.

Tên menu thay đổi theo từng phiên bản, vì vậy hãy làm theo tài liệu chính thức hiện hành của nền tảng thay vì dựa vào các đường dẫn thao tác đã ghi nhớ. Các khái niệm dưới đây vẫn nhất quán ngay cả khi cách diễn đạt thay đổi.

Máy tính để bàn và trình duyệt

Trên Windows và macOS, hãy tìm phần cài đặt mạng hoặc proxy của hệ thống có tùy chọn tập lệnh cấu hình tự động hoặc cấu hình proxy tự động. Bật tùy chọn đó, dán URL Proxy Tự động, lưu lại, rồi khởi động lại hoàn toàn trình duyệt bạn đang kiểm thử. Một số trình duyệt dùng theo cài đặt của hệ điều hành, trong khi một số khác cho phép chọn riêng, vì vậy hãy xác minh lớp nào đang kiểm soát.

Nếu bạn đang làm việc ở cấp trình duyệt, hãy xem lại các bước thay đổi cài đặt proxy trong Chrome trước khi cho rằng trình duyệt và hệ điều hành có cùng cấu hình. Một proxy thủ công cũ trong một hồ sơ có thể ghi đè tập lệnh mới của bạn. Sự không khớp này giải thích nhiều trường hợp một người thấy ảnh chụp màn hình khác với kết quả của người khác.

Khi triển khai cho nhóm, hãy ghi lại ba điều trong quy trình vận hành:

• Phạm vi: Toàn hệ thống, một trình duyệt hay một hồ sơ được quản lý.
• IP thoát dự kiến: Quốc gia, loại mạng và mọi hành vi phiên mà tác vụ yêu cầu.
• Khôi phục: Cách tắt tập lệnh và quay về DIRECT nếu máy chủ PAC gặp sự cố.

Thiết bị di động

Trên thiết bị di động, hãy cấu hình proxy cho mạng Wi-Fi cụ thể khi có tùy chọn này, chọn thiết lập tự động rồi nhập URL PAC. Hướng dẫn triển khai hiện hành cho biết iOS có thể xử lý PAC ở cấp hệ thống, trong khi các ứng dụng khách tùy chỉnh trên Android như OkHttp có thể cần phân tích PAC và thực thi JavaScript rõ ràng, một điểm khác biệt được giải thích trong hướng dẫn tích hợp proxy doanh nghiệp trên thiết bị di động này.

Điều đó sẽ làm thay đổi cách bạn xác minh. Kiểm tra thành công bằng trình duyệt trên điện thoại không chứng minh rằng ứng dụng, WebView nhúng hoặc SDK phân tích của ứng dụng cũng dùng cùng tuyến.

Hãy chạy quy trình xác minh ngắn trên từng nền tảng. Tải một trang kiểm thử đã biết, xác nhận IP được định tuyến qua một trang kiểm tra đáng tin cậy, rồi lặp lại đúng quy trình đó trên thiết bị thứ hai. Hãy kiểm thử trên mạng mà mọi người thực sự sẽ dùng, không chỉ trên Wi-Fi văn phòng cạnh người viết tập lệnh.

Loại proxy, phiên cố định và IP di động

Tệp PAC chọn tuyến, nhưng đặc tính của tuyến đó phụ thuộc vào proxy ở điểm cuối. Trước tiên cần hiểu ba thuật ngữ. Luân chuyển IP thay đổi địa chỉ thoát theo thời gian hoặc theo yêu cầu. Phiên cố định giữ nguyên một địa chỉ trong khoảng thời gian nhất định để quy trình đăng nhập hoặc thanh toán được nhất quán. ASN, hay số hệ thống tự trị, xác định nhà khai thác mạng quảng bá một khối địa chỉ; còn nhắm mục tiêu theo vị trí địa lý cho phép chọn quốc gia hoặc khu vực.

Địa chỉ trung tâm dữ liệu thường dễ bị đích đến nhận diện là lưu lượng không phải từ hộ gia đình nhất vì ASN của chúng thuộc mạng lưu trữ. Địa chỉ dân cư trông giống kết nối gia đình thông thường hơn. Địa chỉ di động đến từ mạng nhà mạng, và ở đây việc dùng chung địa chỉ làm thay đổi cách tính toán chặn.

Vì sao NAT cấp nhà mạng quan trọng

NAT cấp nhà mạng, hay CGNAT, cho phép nhà mạng chuyển đổi lưu lượng từ nhiều thiết bị thuê bao qua một nhóm nhỏ địa chỉ IPv4 công khai. RFC 6598 dành riêng khối 100.64.0.0/10, gồm 1,048,576 địa chỉ, cho không gian địa chỉ dùng chung được các thiết bị CGN của nhà cung cấp dịch vụ sử dụng; khối này không thể định tuyến toàn cục, theo định nghĩa trong RFC 6598 về không gian địa chỉ dùng chung.

Vì nhiều khách hàng thực có thể dùng chung một IP di động công khai, đích đến chặn gắt địa chỉ đó có thể ảnh hưởng đến nhiều người không liên quan. Đó là lý do IP di động khó bị nhận diện là của một tác nhân duy nhất hơn và cũng rủi ro hơn nếu chặn hoàn toàn. Đây cũng là lý do chỉ riêng IP không phải là tín hiệu nhận dạng hoàn hảo.

Khi thiết kế phiên, hãy đọc cách duy trì phiên giúp địa chỉ proxy ổn định và quyết định những trường hợp nào cần tính nhất quán. Dùng hành vi phiên cố định cho việc quản lý tài khoản hợp lệ, QA nhiều bước và hành trình quảng cáo sẽ bị gián đoạn nếu IP thoát thay đổi giữa chừng. Dùng luân chuyển cho hoạt động nghiên cứu công khai trên diện rộng, không lưu trạng thái. Dù theo cách nào, hãy ghi lại dấu thời gian, đích đến, trạng thái phản hồi và ngữ cảnh phiên, vì IP thoát dùng chung của nhà mạng không tương ứng một-một với từng người dùng.

Proxy HTTP xử lý yêu cầu web và đường hầm CONNECT, trong khi SOCKS5 là giao thức proxy tổng quát hơn, có thể truyền nhiều loại lưu lượng TCP hơn. Giá trị trả về của PAC, khả năng hỗ trợ của ứng dụng khách và tác vụ của bạn đều cần thống nhất với lựa chọn đó.

Kiểm thử phạm vi bao phủ và bảo mật trước khi đưa vào sử dụng thực tế

Kết quả xanh trên trang kiểm tra IP là phép thử yếu nhất bạn có thể thực hiện. Nó chỉ chứng minh rằng một yêu cầu của trình duyệt đã dùng IP thoát dự kiến vào một thời điểm nhất định. Nó không cho biết gì về chuyển hướng, tải lên, lời gọi chạy nền hay liệu proxy đã chọn có còn đáng tin vào ngày mai hay không.

PAC là cơ chế định tuyến của trình duyệt hoặc hệ điều hành. Ứng dụng di động tùy chỉnh và ứng dụng khách HTTP có thể không tự động thực thi logic PAC. Kiểm thử bằng trình duyệt có thể dùng proxy dự kiến, trong khi WebView nhúng, SDK, yêu cầu chạy nền hoặc ứng dụng khách API lại kết nối trực tiếp. Với QA phụ thuộc vị trí địa lý, điểm mù đó có thể khiến toàn bộ kết quả mất hiệu lực.

Hãy xây dựng các bước kiểm tra xoay quanh quy trình thực tế, sử dụng môi trường kiểm thử proxy có cấu trúc thay vì kiểm tra ngẫu hứng:

• Phân giải DNS: Xác nhận các truy vấn không làm lộ vị trí ngoài dự kiến hoặc thất bại khi tuyến proxy đang hoạt động.
• Chuyển hướng và HTTPS: Theo dõi toàn bộ chuỗi chuyển hướng và xác minh CONNECT thành công với mọi máy chủ đích.
• WebSocket và tải lên: Kiểm tra các kết nối kéo dài và thao tác gửi tệp, không chỉ việc xem trang.
• Lời gọi chạy nền: Kích hoạt các yêu cầu phân tích, API và SDK rồi kiểm tra nơi chúng thoát ra.
• Hành vi dự phòng: Tắt proxy đầu tiên trong một bản sao thử nghiệm của tập lệnh và xác nhận ứng dụng khách dùng proxy dự phòng như dự kiến hoặc báo lỗi rõ ràng.

Vì sao cần xem xét kỹ nguồn cung proxy

Tự động hóa không khiến một điểm cuối trở nên an toàn. Trong một nghiên cứu về hơn 107,000 proxy mở được liệt kê công khai, khoảng 92% không khả dụng hoặc không cho phép lưu lượng proxy, theo các phép đo quy mô lớn về proxy mở được liệt kê công khai. Cùng tập hợp kết quả đã được xác minh này cho biết năm quốc gia chiếm gần 60% số proxy mở hoạt động được và 41% được lưu trữ chỉ trên 10 hệ thống tự trị.

Một phân tích riêng kéo dài chín tháng trong các kết quả đó xác định được hơn 436,000 proxy và 104,000 proxy phản hồi, trong đó 7.17% số proxy phản hồi đã sửa đổi nội dung trang web và 76.42% trong số các proxy sửa đổi này thực hiện hành vi độc hại. Bạn không cần phải ghi nhớ những con số đó. Nhưng bạn cần ghi nhớ bài học từ chúng.

Đừng định tuyến hoạt động nghiên cứu thực tế, bảo vệ thương hiệu hoặc công việc liên quan đến tài khoản qua các điểm cuối được tự động chọn mà bạn chưa kiểm tra tình trạng hoạt động và kiểm soát quyền truy cập.

Trước khi đưa vào sản xuất, hãy chạy kiểm tra tính khả dụng liên tục, duy trì logic dự phòng trong tệp PAC, theo dõi tính toàn vẹn của nội dung trên các trang kiểm thử đã biết và yêu cầu xác thực nếu thiết lập của bạn hỗ trợ. Ghi lại proxy nào đã xử lý tác vụ, thời điểm xử lý và trạng thái phản hồi. Khi kết quả có vẻ không chính xác, những bản ghi đó giúp bạn phân biệt lỗi định tuyến với endpoint gặp sự cố.

Chọn thiết lập phù hợp cho nhóm của bạn

Hãy chọn theo quy trình làm việc, đừng chọn theo thói quen. Kết nối trực tiếp phù hợp với các hệ thống nội bộ và những lần kiểm tra công khai mà vị trí thực của bạn chính là điều cần kiểm thử. Proxy được thiết lập thủ công phù hợp với một người thực hiện tác vụ ngắn, ổn định, nhưng sẽ trở nên mong manh khi mười người cần dùng chung các quy tắc và những quy tắc đó thay đổi hằng tuần.

Thiết lập dựa trên PAC xứng đáng với độ phức tạp khi việc định tuyến khác nhau tùy theo đích đến. Ví dụ: các công cụ nội bộ có thể kết nối trực tiếp, hoạt động theo dõi giá công khai có thể dùng điểm thoát dân cư tại thị trường mục tiêu, còn proxy dự phòng có thể xử lý khi xảy ra sự cố. Chỉ cần cập nhật một tập lệnh là có thể thay đổi chính sách mà không cần lần lượt kiểm tra từng máy trạm.

Nguồn 4G di động phù hợp khi trải nghiệm tại đích đến phụ thuộc vào mạng của nhà mạng. Chuyên gia xác minh quảng cáo có thể cần xem chiến dịch như một thuê bao di động nhìn thấy. Các nhóm QA có thể cần đường ra của nhà mạng Pháp cho quy trình đăng ký đã bản địa hóa. Những người quản lý mạng xã hội xử lý tài khoản khách hàng hợp pháp có thể cần các phiên cố định, nhất quán về vị trí, không chuyển mạng giữa chừng khi đang thực hiện tác vụ. Các nhóm bảo vệ thương hiệu và theo dõi SEO có thể cần cùng khả năng nhắm mục tiêu theo vị trí địa lý mà không phải gắn mọi lần kiểm tra với kết nối của một văn phòng.

Hãy đối chiếu các tiêu chí sau trước khi quyết định:

• Phạm vi cần hỗ trợ: Chỉ trình duyệt, toàn bộ thiết bị hay ứng dụng có HTTP client riêng.
• Hành vi phiên: Xoay vòng cho nghiên cứu không trạng thái, cố định cho quy trình nhiều bước hợp pháp.
• Danh tính mạng: Tốc độ trung tâm dữ liệu, ngữ cảnh dân cư hay đường ra của nhà mạng thông qua IP di động.
• Kiểm soát vận hành: Truy cập có xác thực, kiểm tra tình trạng, quy tắc dự phòng và nhật ký hữu ích.
• Giới hạn tuân thủ: Quy tắc nền tảng, luật hiện hành, sự ủy quyền của khách hàng và mục đích kinh doanh được ghi chép.

Trong mô hình đó, Evoproxy là nhà cung cấp proxy di động có trụ sở tại miền nam nước Pháp, với quyền truy cập vào hơn 1,500,000 địa chỉ IP di động. Các gói cá nhân chạy trên phần cứng di động chuyên dụng, có 250 GB lưu lượng hằng tháng và thời gian xoay vòng từ một đến năm phút, trong khi các cổng dùng chung cung cấp 50 GB cùng lịch xoay vòng định sẵn cho những lần kiểm thử ngắn.

Đừng chỉ mua dựa trên quy mô nhóm IP. Hãy chạy một quy trình thực tế qua thiết lập, áp dụng các bước kiểm tra phạm vi hỗ trợ và bảo mật ở trên, rồi xác minh mọi thành phần đều tuân theo tuyến đường. Giữ cho các quy tắc PAC dễ đọc, ghi chép đầy đủ các phiên và đảm bảo mọi hoạt động đều tuân thủ quy tắc nền tảng cũng như luật hiện hành. Đó là cách biến URL Proxy Tự động thành một chính sách định tuyến đáng tin cậy, thay vì một chuỗi bí ẩn ai đó đã dán vào phần cài đặt từ nhiều tháng trước.

Nếu lần kiểm thử tiếp theo cần đường ra thực sự của nhà mạng thay vì cách mô phỏng chỉ trong trình duyệt, hãy thử thiết lập 4G di động từ Evoproxy với một quy trình xác minh quảng cáo, QA hoặc nghiên cứu thị trường thực tế. Cấu hình hành vi phiên bạn cần, xác minh phạm vi hỗ trợ vượt ra ngoài việc kiểm tra IP hiển thị và chỉ mở rộng quy mô sau khi nhật ký của chính bạn cho thấy định tuyến hoạt động xuyên suốt từ đầu đến cuối.