WPAD slår op, men browseren får en 404
Automatisk proxy-opdagelse kan finde den rigtige server og alligevel anmode om en PAC-fil fra en forkert virtuel host eller sti.
Navnet wpad slår op på den forventede maskine. Det er opmuntrende, men det er kun begyndelsen. Browseren skal stadig anmode om en fil fra den maskine og modtage PAC-scriptet.
Et nyttigt spor findes i webserverens adgangslog: klienten anmodede om /wpad.dat og modtog HTTP 404. En manuelt åbnet PAC-URL kan bruge et andet værtsnavn. Selv når begge navne når samme server, kan de vælge forskellige virtuelle værter.
Følg den anmodning, klienten sendte
Kontroller den nøjagtige URL, som opdagelsen valgte, HTTP Host-værdien, stien og svaret. At åbne en bekvem PAC-URL i en almindelig browserfane beviser ikke, at automatisk opdagelse anmodede om den URL.
Hvis både korte og fuldt kvalificerede navne forventes, skal den tilsigtede webhost konfigureres til bevidst at håndtere disse navne. Bekræft, at /wpad.dat peger på den rigtige fil og ikke på en standarddokumentrod eller en urelateret applikation.
Server et script, ikke en fejlside
Kontroller svarets krop såvel som dets status. En login-side, et brandet fejldokument eller en omdirigering kan se plausibel ud ved manuel visning, men er ikke det PAC-script, som resolveren forventer. Chromium dokumenterer strenge krav til PAC-download, inklusive et HTTP 200-svar.
Først efter at leveringen lykkes, giver det mening at fejlsøge FindProxyForURL(). Ændring af dets værtsnavneregler kan ikke reparere en 404, der forhindrede browseren i at hente det.
Skeln også mellem en PAC-webserver og den forward proxy, der nævnes i dens script. De kan dele en maskine, men en adgangslogpost på én tjeneste er ikke bevis for, at den anden tjeneste håndterede brugerens destinationsanmodning.