WPAD розв'язується, але браузер отримує 404
Автоматичне виявлення проксі може знайти потрібний сервер і все одно запросити PAC-файл з неправильного віртуального хоста або шляху.
Ім'я wpad розв'язується в очікувану машину. Це підбадьорює, але це лише початок. Браузер усе ще має запитати файл із цієї машини й отримати PAC-скрипт.
Корисну підказку можна знайти в журналі доступу веб-сервера: клієнт запитав /wpad.dat і отримав HTTP 404. Відкрита вручну адреса PAC може використовувати інше ім'я хоста. Навіть коли обидва імені ведуть на один сервер, вони можуть вибрати різні віртуальні хости.
Простежте запит, який зробив клієнт
Перевірте точний URL, обраний виявленням, значення HTTP Host, шлях і відповідь. Відкриття зручної адреси PAC у звичайній вкладці браузера не доводить, що автоматичне виявлення запитало саме цей URL.
Якщо очікуються і короткі, і повні імена, налаштуйте потрібний веб-хост свідомо обслуговувати ці імена. Переконайтеся, що /wpad.dat вказує на правильний файл, а не на корінь документів за замовчуванням чи не пов'язаний застосунок.
Віддавайте скрипт, а не сторінку помилки
Перевірте не лише статус, а й тіло відповіді. Сторінка входу, брендований документ помилки або перенаправлення можуть виглядати правдоподібно під час ручного перегляду, але це не той PAC-скрипт, якого очікує розв'язувач. Chromium документує суворі вимоги до завантаження PAC, зокрема відповідь HTTP 200.
Лише після того, як доставка буде успішною, має сенс налагоджувати FindProxyForURL(). Зміна його правил імен хостів не виправить 404, який завадив браузеру отримати скрипт.
Також відрізняйте веб-сервер PAC від прямого проксі, названого в його скрипті. Вони можуть ділити одну машину, але запис у журналі доступу однієї служби не є доказом того, що інша служба обробила запит користувача до призначення.