WPAD vert opp, men nettlesaren får ein 404
Automatisk proxyoppdaging kan finne rett tenar og likevel be om ei PAC-fil frå ein feil virtuell vert eller sti.
Namnet wpad vert løyst opp til den venta maskina. Det er oppmuntrande, men det er berre byrjinga. Nettlesaren må framleis be om ei fil frå den maskina og ta imot PAC-skriptet.
Eit nyttig spor finst i tilgangsloggen til nettenaren: klienten bad om /wpad.dat og fekk HTTP 404. Ein PAC-URL som vert opna manuelt kan bruke eit anna vertsnamn. Sjølv når begge namna når same tenar, kan dei velje ulike virtuelle vertar.
Følg førespurnaden klienten sende
Kontroller den nøyaktige URL-en oppdaginga valde, HTTP Host-verdien, stien og svaret. Å opne ein praktisk PAC-URL i ein vanleg nettlesarfane beviser ikkje at automatisk oppdaging bad om den URL-en.
Viss både korte og fullt kvalifiserte namn er venta, konfigurer den tiltenkte nettverten til å handsame desse namna med vilje. Stadfest at /wpad.dat peikar til rett fil, ikkje til ei standarddokumentrot eller ein urelatert applikasjon.
Ten ei skriptfil, ikkje ei feilside
Kontroller innhaldet i svaret så vel som statusen. Ei påloggingsside, eit merkevaremerkt feildokument eller ei omdirigering kan sjå truverdig ut ved manuell visning, men er ikkje PAC-skriptet resolvaren ventar. Chromium dokumenterer strenge krav til PAC-nedlasting, inkludert eit HTTP 200-svar.
Først etter at leveransen lukkast er det meiningsfullt å feilsøkje FindProxyForURL(). Å endre vertsnamnreglane kan ikkje reparere ein 404 som hindra nettlesaren i å hente det.
Skil også ein PAC-netttenar frå videresendingsproxyen som er namngjeven i skriptet. Dei kan dele ei maskin, men ei tilgangsloggoppføring på éin teneste er ikkje prov på at den andre tenesta handsama mål førespurnaden til brukaren.