WPAD się rozwiązuje, ale przeglądarka otrzymuje 404
Automatyczne wykrywanie serwera proxy może znaleźć właściwy serwer i mimo to zażądać pliku PAC z niewłaściwego hosta wirtualnego lub ścieżki.
Nazwa wpad rozwiązuje się na oczekiwaną maszynę. To zachęcające, ale to dopiero początek. Przeglądarka nadal musi zażądać pliku z tej maszyny i otrzymać skrypt PAC.
Przydatną wskazówkę można znaleźć w dzienniku dostępu serwera WWW: klient zażądał /wpad.dat i otrzymał HTTP 404. Ręcznie otwarty adres PAC może używać innej nazwy hosta. Nawet gdy obie nazwy trafiają do tego samego serwera, mogą wybrać różne hosty wirtualne.
Prześledź żądanie wysłane przez klienta
Sprawdź dokładny adres URL wybrany przez wykrywanie, wartość HTTP Host, ścieżkę i odpowiedź. Otwarcie wygodnego adresu PAC w zwykłej karcie przeglądarki nie dowodzi, że automatyczne wykrywanie zażądało tego adresu.
Jeśli oczekiwane są zarówno nazwy krótkie, jak i w pełni kwalifikowane, skonfiguruj docelowy host WWW tak, aby świadomie obsługiwał te nazwy. Potwierdź, że /wpad.dat prowadzi do właściwego pliku, a nie do domyślnego katalogu głównego dokumentów lub niezwiązanej aplikacji.
Serwuj skrypt, a nie stronę błędu
Zweryfikuj treść odpowiedzi oraz jej status. Strona logowania, oznaczony dokument błędu lub przekierowanie mogą wyglądać wiarygodnie przy ręcznym podglądzie, ale nie są skryptem PAC, którego oczekuje resolver. Chromium dokumentuje rygorystyczne wymagania dotyczące pobierania PAC, w tym odpowiedź HTTP 200.
Dopiero po tym, jak dostarczenie się powiedzie, ma sens debugowanie FindProxyForURL(). Zmiana reguł nazw hostów nie naprawi 404, który uniemożliwił przeglądarce jego pobranie.
Odróżniaj też serwer WWW PAC od serwera proxy przekazującego wymienionego w jego skrypcie. Mogą dzielić maszynę, ale wpis w dzienniku dostępu jednej usługi nie jest dowodem, że druga usługa obsłużyła żądanie docelowe użytkownika.