WPAD si risolve, ma il browser riceve un 404
Il rilevamento automatico del proxy può trovare il server giusto e comunque richiedere un file PAC da un host virtuale o un percorso sbagliato.
Il nome wpad si risolve nella macchina attesa. È incoraggiante, ma è solo l'inizio. Il browser deve ancora richiedere un file a quella macchina e ricevere lo script PAC.
Un indizio utile si trova nel log di accesso del server web: il client ha richiesto /wpad.dat e ha ricevuto HTTP 404. Un URL PAC aperto manualmente può usare un altro nome host. Anche quando entrambi i nomi raggiungono lo stesso server, possono selezionare host virtuali diversi.
Segui la richiesta effettuata dal client
Controlla l'URL esatto selezionato dal rilevamento, il valore HTTP Host, il percorso e la risposta. Aprire un comodo URL PAC in una normale scheda del browser non dimostra che il rilevamento automatico abbia richiesto quell'URL.
Se sono attesi sia nomi brevi sia nomi completamente qualificati, configura l'host web previsto per gestire quei nomi deliberatamente. Conferma che /wpad.dat punti al file corretto, non a una radice documenti predefinita o a un'applicazione non correlata.
Servi uno script, non una pagina di errore
Verifica il corpo della risposta oltre allo stato. Una pagina di accesso, un documento di errore brandizzato o un reindirizzamento possono sembrare plausibili se visti manualmente, ma non sono lo script PAC atteso dal resolver. Chromium documenta requisiti di download del PAC rigorosi, inclusa una risposta HTTP 200.
Solo dopo che la consegna riesce ha senso eseguire il debug di FindProxyForURL(). Modificare le sue regole sui nomi host non può riparare un 404 che ha impedito al browser di ottenerlo.
Distingui anche un server web PAC dal proxy forward indicato nel suo script. Possono condividere una macchina, ma una voce nel log di accesso di un servizio non è prova che l'altro servizio abbia gestito la richiesta di destinazione dell'utente.