WPAD се решава, но прелистувачот добива 404
Автоматското откривање на прокси може да го најде вистинскиот сервер и сепак да побара PAC-датотека од погрешен виртуелен хост или патека.
Името wpad се решава на очекуваната машина. Тоа е охрабрувачко, но е само почеток. Прелистувачот сè уште мора да побара датотека од таа машина и да ја прими PAC-скриптата.
Корисна трага може да се најде во дневникот за пристап на веб-серверот: клиентот побарал /wpad.dat и добил HTTP 404. Рачно отворен PAC-URL може да користи друго име на хост. Дури и кога двете имиња стигнуваат до истиот сервер, тие можат да изберат различни виртуелни хостови.
Следете го барањето што го испратил клиентот
Проверете ја точната URL-адреса избрана од откривањето, вредноста на HTTP Host, патеката и одговорот. Отворањето на погодна PAC-URL во обичен таб на прелистувач не докажува дека автоматското откривање ја побарало таа URL.
Ако се очекуваат и кратки и целосно квалификувани имиња, конфигурирајте го предвидениот веб-хост намерно да ги обработува тие имиња. Потврдете дека /wpad.dat се мапира на точната датотека, а не на стандарден корен на документи или неповрзана апликација.
Служете скрипта, не страница за грешка
Проверете го телото на одговорот, како и неговиот статус. Страница за најава, брендиран документ за грешка или пренасочување може да изгледаат веродостојно при рачно гледање, но не се PAC-скриптата што ја очекува решавачот. Chromium документира строги барања за преземање на PAC, вклучително и одговор HTTP 200.
Само откако доставата успее има смисла да се дебагира FindProxyForURL(). Менувањето на неговите правила за имиња на хостови не може да поправи 404 што го спречил прелистувачот да го добие.
Исто така, разликувајте PAC веб-сервер од напредниот прокси наведен во неговата скрипта. Тие може да делат машина, но запис во дневникот за пристап на една услуга не е доказ дека другата услуга го обработила барањето за дестинација на корисникот.