WPAD solviĝas, sed la retumilo ricevas 404
Aŭtomata proksea malkovro povas trovi la ĝustan servilon kaj tamen peti PAC-dosieron de malĝusta virtuala gastiganto aŭ vojo.
La nomo wpad solviĝas al la atendata maŝino. Tio estas kuraĝiga, sed ĝi estas nur la komenco. La retumilo ankoraŭ devas peti dosieron de tiu maŝino kaj ricevi la PAC-skripton.
Utila indiko troviĝas en la alirprotokolo de la retservilo: la kliento petis /wpad.dat kaj ricevis HTTP 404. Mane malfermita PAC-URL povas uzi alian gastigantnomon. Eĉ kiam ambaŭ nomoj atingas la saman servilon, ili povas elekti malsamajn virtualajn gastigantojn.
Sekvu la peton, kiun faris la kliento
Kontrolu la ĝustan URL-on elektitan de la malkovro, la HTTP Host-valoron, la vojon kaj la respondon. Malfermi oportunan PAC-URL-on en ordinara retumila langeto ne pruvas, ke aŭtomata malkovro petis tiun URL-on.
Se atendiĝas kaj mallongaj kaj plene kvalifikitaj nomoj, agordu la celatan retgastiganton por intence pritrakti tiujn nomojn. Konfirmu, ke /wpad.dat mapiĝas al la ĝusta dosiero, ne al defaŭlta dokumentradiko aŭ nerrilata aplikaĵo.
Servu skripton, ne erarpagon
Kontrolu la korpon de la respondo same kiel ĝian statuson. Ensaluta paĝo, markita erardokumento aŭ alidirekto povas aspekti kredinda mane, sed ĝi ne estas la PAC-skripto, kiun la solvilo atendas. Chromium dokumentas striktajn postuloj pri elŝuto de PAC, inkluzive de HTTP 200-respondo.
Nur post kiam la liverado sukcesos, sencas sencimigi FindProxyForURL(). Ŝanĝi ĝiajn gastigantnomajn regulojn ne povas ripari 404-on, kiu malebligis al la retumilo akiri ĝin.
Ankaŭ distingigu PAC-retservilon disde la antaŭa prokseo nomita en ĝia skripto. Ili povas dividi maŝinon, sed alirprotokola rikordo de unu servo ne estas pruvo, ke la alia servo pritraktis la celpeton de la uzanto.