WPAD-ը լուծվում է, բայց զննարկիչը ստանում է 404

wpad անունը լուծվում է սպասվող մեքենայի։ Դա քաջալերող է, բայց դա միայն սկիզբն է։ Զննարկիչը դեռ պետք է ֆայլ պահանջի այդ մեքենայից և ստանա PAC սկրիպտը։

Օգտակար հուշում կարելի է գտնել վեբ սերվերի մուտքերի մատյանում՝ հաճախորդը պահանջել է /wpad.dat և ստացել HTTP 404։ Ձեռքով բացված PAC URL-ը կարող է օգտագործել այլ հոսթի անուն։ Նույնիսկ երբ երկու անուններն էլ հասնում են նույն սերվերին, նրանք կարող են ընտրել տարբեր վիրտուալ հոսթեր։

Հետևեք այն հարցմանը, որն ուղարկել է հաճախորդը

Ստուգեք հայտնաբերման ընտրած ճշգրիտ URL-ը, HTTP Host արժեքը, ուղին և պատասխանը։ Սովորական դիտարկիչի ներդիրում հարմար PAC URL բացելը չի ապացուցում, որ ավտոմատ հայտնաբերումը պահանջել է հենց այդ URL-ը։

Եթե սպասվում են և՛ կարճ, և՛ ամբողջական որակավորված անուններ, կարգավորեք նախատեսված վեբ հոսթը դիտավորյալ կերպով սպասարկելու այդ անունները։ Հաստատեք, որ /wpad.dat-ը քարտեզագրվում է ճիշտ ֆայլին, ոչ թե լռելյայն փաստաթղթերի արմատին կամ անկապ հավելվածին։

Մատուցեք սկրիպտ, ոչ թե սխալի էջ

Ստուգեք պատասխանի մարմինը և դրա կարգավիճակը։ Մուտքի էջը, ապրանքանիշային սխալի փաստաթուղթը կամ վերահասցեավորումը ձեռքով դիտելիս կարող են հավաստի թվալ, բայց դա այն PAC սկրիպտը չէ, որին սպասում է լուծիչը։ Chromium-ը փաստագրում է խիստ PAC ներբեռնման պահանջներ՝ ներառյալ HTTP 200 պատասխանը։

Միայն առաքումը հաջողվի հետո է իմաստ ունի վրիպազերծել FindProxyForURL()-ը։ Դրա հոսթի անունների կանոնները փոխելը չի կարող ուղղել այն 404-ը, որի պատճառով զննարկիչը չի ստացել սկրիպտը։

Տարբերակեք նաև PAC վեբ սերվերը դրա սկրիպտում նշված առաջընթաց պրոքսիից։ Նրանք կարող են կիսել մեքենան, բայց մի ծառայության մուտքերի մատյանի գրառումը ապացույց չէ, որ մյուս ծառայությունը սպասարկել է օգտատիրոջ նպատակակետ հարցումը։