WPAD se rezolvă, dar browserul primește un 404
Descoperirea automată a proxy-ului poate găsi serverul corect și totuși poate solicita un fișier PAC de la un host virtual sau o cale greșită.
Numele wpad se rezolvă la mașina așteptată. Acest lucru este încurajator, dar este doar începutul. Browserul trebuie încă să solicite un fișier de la acea mașină și să primească scriptul PAC.
Un indiciu util se află în jurnalul de acces al serverului web: clientul a solicitat /wpad.dat și a primit HTTP 404. Un URL PAC deschis manual poate folosi un alt nume de host. Chiar și atunci când ambele nume ajung la același server, ele pot selecta hosturi virtuale diferite.
Urmăriți cererea făcută de client
Verificați URL-ul exact selectat de descoperire, valoarea HTTP Host, calea și răspunsul. Deschiderea unui URL PAC convenabil într-o filă obișnuită de browser nu demonstrează că descoperirea automată a solicitat acel URL.
Dacă se așteaptă atât nume scurte, cât și nume complet calificate, configurați hostul web dorit să gestioneze deliberat aceste nume. Confirmați că /wpad.dat indică fișierul corect, nu o rădăcină de documente implicită sau o aplicație nelegată.
Serviți un script, nu o pagină de eroare
Verificați corpul răspunsului, precum și starea acestuia. O pagină de autentificare, un document de eroare cu marcă sau o redirecționare pot părea plauzibile la vizualizarea manuală, dar nu sunt scriptul PAC așteptat de resolver. Chromium documentează cerințe de descărcare PAC stricte, inclusiv un răspuns HTTP 200.
Abia după ce livrarea reușește are sens să depanați FindProxyForURL(). Modificarea regulilor sale de nume de host nu poate repara un 404 care a împiedicat browserul să îl obțină.
De asemenea, distingeți un server web PAC de proxy-ul de forward numit în scriptul său. Pot împărți o mașină, dar o intrare în jurnalul de acces al unui serviciu nu este dovada că celălalt serviciu a gestionat cererea de destinație a utilizatorului.