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