WPAD løses opp, men nettleseren får en 404
Automatisk proxyoppdagelse kan finne riktig server og likevel be om en PAC-fil fra en feil virtuell vert eller sti.
Navnet wpad løses opp til den forventede maskinen. Det er oppmuntrende, men det er bare begynnelsen. Nettleseren må fortsatt be om en fil fra den maskinen og motta PAC-skriptet.
Et nyttig spor finnes i tilgangsloggen til webserveren: klienten ba om /wpad.dat og fikk HTTP 404. En manuelt åpnet PAC-URL kan bruke et annet vertsnavn. Selv når begge navnene når samme server, kan de velge forskjellige virtuelle verter.
Følg forespørselen klienten sendte
Kontroller den nøyaktige URL-en oppdagelsen valgte, HTTP Host-verdien, stien og svaret. Å åpne en praktisk PAC-URL i en vanlig nettleserfane beviser ikke at automatisk oppdagelse ba om den URL-en.
Hvis både korte og fullt kvalifiserte navn forventes, konfigurer den tiltenkte webverten til å håndtere disse navnene bevisst. Bekreft at /wpad.dat peker til riktig fil, ikke til en standarddokumentrot eller en urelatert applikasjon.
Tjen en skriptfil, ikke en feilside
Kontroller svarets innhold så vel som statusen. En påloggingsside, et merkevaremerket feildokument eller en omdirigering kan virke plausibel ved manuell visning, men er ikke PAC-skriptet resolveren forventer. Chromium dokumenterer strenge krav til PAC-nedlasting, inkludert et HTTP 200-svar.
Først etter at leveringen lykkes er det fornuftig å feilsøke FindProxyForURL(). Å endre vertsnavnreglene kan ikke reparere en 404 som hindret nettleseren i å hente det.
Skill også en PAC-webserver fra videresendingsproxyen som er navngitt i skriptet. De kan dele en maskin, men en tilgangsloggoppføring på én tjeneste er ikke bevis for at den andre tjenesten håndterte brukerens destinasjonsforespørsel.