Від результату тесту PAC до реального маршруту браузера
Відокремте маршрут, який повертає функція PAC, від доставки файлу, застосування браузером, доступності проксі та кінцевого шляху запиту.
Тестер PAC повертає PROXY proxy.example:8080. Корисний результат. Однак перш ніж назвати конфігурацію браузера перевіреною, лишається відповісти ще на кілька питань.
| Питання | Що перевіряти |
|---|---|
| Що повертає цей скрипт для цього вводу? | Оцінювач, URL вводу й результати допоміжних функцій |
| Чи отримав браузер цю копію? | Налаштований URL PAC і докази доставки або кешування |
| Чи використав браузер повернутий маршрут? | Діагностику браузера щодо вибору проксі та з’єднання |
| Чи міг цей маршрут провести запит? | З’єднання обраної кінцевої точки й обмін із проксі |
Інструмент на кшталт pacparser оцінює логіку PAC власними підтримуваними допоміжними функціями. Він не запускає повністю механізми виявлення конфігурації, політик, кешування та з’єднання цільового браузера.
Тримайте вхідні дані порівнюваними. Інша схема URL, інше написання імені хоста, інша відповідь DNS або передана адреса клієнта можуть змінити слушний результат. Тест в іншій мережі може задіяти іншу гілку без будь-якої помилки в скрипті.
Політика браузера також може вибрати інший URL PAC або фіксований проксі. Редагування файлу на диску не доводить, що браузер завантажив його знову. У Chrome оновлення PAC відрізняється від очищення запам’ятованих поганих проксі. Записуйте точну версію файлу та відповідні налаштування споживача разом із результатом.
Використовуйте офлайн-оцінку, щоб звузити проблему логіки. Використовуйте діагностику реального клієнта, щоб встановити застосування й маршрутизацію. Якщо результат скрипта правильний, але проксі не бачить транзакції, дослідіть цей розрив, перш ніж переписувати робоче правило.