WPAD wordt opgelost, maar de browser krijgt een 404
Automatische proxy-detectie kan de juiste server vinden en toch een PAC-bestand opvragen bij de verkeerde virtuele host of het verkeerde pad.
De naam wpad wordt naar de verwachte machine opgelost. Dat is bemoedigend, maar het is pas het begin. De browser moet nog steeds een bestand bij die machine opvragen en het PAC-script ontvangen.
Een nuttige aanwijzing staat in het toegangslog van de webserver: de client vroeg /wpad.dat aan en kreeg HTTP 404. Een handmatig geopende PAC-URL kan een andere hostnaam gebruiken. Zelfs wanneer beide namen dezelfde server bereiken, kunnen ze verschillende virtuele hosts selecteren.
Volg het verzoek dat de client deed
Controleer de exacte URL die detectie koos, de HTTP Host-waarde, het pad en de respons. Een handige PAC-URL openen in een gewoon browsertabblad bewijst niet dat automatische detectie die URL heeft opgevraagd.
Als zowel korte als volledig gekwalificeerde namen worden verwacht, configureer dan de bedoelde webhost om die namen bewust te verwerken. Bevestig dat /wpad.dat naar het juiste bestand verwijst, niet naar een standaard documentroot of een niet-gerelateerde toepassing.
Lever een script, geen foutpagina
Controleer de responsbody én de status. Een inlogpagina, een gebrandmerkt foutdocument of een redirect kan er bij handmatige weergave plausibel uitzien, maar is niet het PAC-script dat de resolver verwacht. Chromium documenteert strikte eisen voor het downloaden van PAC, inclusief een HTTP 200-respons.
Pas nadat de levering slaagt is het zinvol om FindProxyForURL() te debuggen. Het wijzigen van de hostnaamregels kan een 404 niet repareren die de browser verhinderde het script te verkrijgen.
Onderscheid ook een PAC-webserver van de forward-proxy die in het script wordt genoemd. Ze kunnen een machine delen, maar een toegangslogregel bij de ene dienst bewijst niet dat de andere dienst het bestemmingsverzoek van de gebruiker heeft afgehandeld.