WPAD löses upp, men webbläsaren får en 404
Automatisk proxyidentifiering kan hitta rätt server och ändå begära en PAC-fil från en felaktig virtuell värd eller sökväg.
Namnet wpad löses upp till den förväntade maskinen. Det är uppmuntrande, men det är bara början. Webbläsaren måste fortfarande begära en fil från den maskinen och ta emot PAC-skriptet.
En användbar ledtråd finns i webbserverns åtkomstlogg: klienten begärde /wpad.dat och fick HTTP 404. En manuellt öppnad PAC-URL kan använda ett annat värdnamn. Även när båda namnen når samma server kan de välja olika virtuella värdar.
Följ den begäran som klienten gjorde
Kontrollera den exakta URL som identifieringen valde, HTTP Host-värdet, sökvägen och svaret. Att öppna en bekväm PAC-URL i en vanlig webbläsarflik bevisar inte att automatisk identifiering begärde den URL:en.
Om både korta och fullt kvalificerade namn förväntas, konfigurera den avsedda webbvärden att hantera dessa namn medvetet. Bekräfta att /wpad.dat pekar på rätt fil, inte på en standarddokumentrot eller en orelaterad applikation.
Servera ett skript, inte en felsida
Verifiera svarets innehåll såväl som dess status. En inloggningssida, ett varumärkt feldokument eller en omdirigering kan verka trovärdig vid manuell visning, men är inte det PAC-skript som resolvern förväntar sig. Chromium dokumenterar strikta krav för PAC-nedladdning, inklusive ett HTTP 200-svar.
Först efter att leveransen lyckas är det meningsfullt att felsöka FindProxyForURL(). Att ändra dess värdnamnsregler kan inte reparera en 404 som hindrade webbläsaren från att hämta det.
Skilj också en PAC-webbserver från den vidarebefordrande proxy som nämns i dess skript. De kan dela en maskin, men en åtkomstloggpost hos en tjänst är inte bevis för att den andra tjänsten hanterade användarens destinationsbegäran.