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 от прямого прокси, указанного в его скрипте. Они могут делить одну машину, но запись в журнале доступа одной службы не доказывает, что другая служба обработала запрос пользователя к месту назначения.