WPAD सोडवले जाते, पण ब्राउझरला 404 मिळते
स्वयंचलित प्रॉक्सी शोध योग्य सर्व्हर शोधू शकते आणि तरीही चुकीच्या व्हर्च्युअल होस्ट किंवा मार्गातून PAC फाइल मागू शकते.
wpad हे नाव अपेक्षित मशीनवर सोडवले जाते. हे उत्साहवर्धक आहे, पण ही फक्त सुरुवात आहे. ब्राउझरला अजूनही त्या मशीनकडून फाइल मागून PAC स्क्रिप्ट मिळवायची आहे.
वेब सर्व्हरच्या प्रवेश लॉगमध्ये उपयुक्त सूत्र सापडते: क्लायंटने /wpad.dat मागितले आणि HTTP 404 मिळाले. हाताने उघडलेला PAC URL दुसरे होस्टनाव वापरू शकतो. दोन्ही नावे एकाच सर्व्हरवर पोहोचली तरी ती वेगवेगळे व्हर्च्युअल होस्ट निवडू शकतात.
क्लायंटने केलेल्या विनंतीचा मागोवा घ्या
शोधाने निवडलेला नेमका URL, HTTP Host मूल्य, मार्ग आणि प्रतिसाद तपासा. सामान्य ब्राउझर टॅबमध्ये सोयीस्कर PAC URL उघडणे म्हणजे स्वयंचलित शोधाने तो URL मागितला हे सिद्ध होत नाही.
लहान आणि पूर्णपणे पात्र अशी दोन्ही नावे अपेक्षित असल्यास, इच्छित वेब होस्टला ती नावे जाणीवपूर्वक हाताळण्यासाठी संरचित करा. /wpad.dat योग्य फाइलशी जुळतो याची खात्री करा, डीफॉल्ट दस्तऐवज रूट किंवा असंबंधित अनुप्रयोगाशी नाही.
त्रुटी पृष्ठ नाही, स्क्रिप्ट द्या
प्रतिसादाची स्थिती आणि मुख्य भाग दोन्ही तपासा. साइन-इन पृष्ठ, ब्रँडेड त्रुटी दस्तऐवज किंवा पुनर्निर्देशन हाताने पाहताना विश्वासार्ह वाटू शकते, पण ती रिझोल्व्हरला अपेक्षित असलेली PAC स्क्रिप्ट नाही. Chromium कठोर PAC डाउनलोड आवश्यकता चे दस्तऐवजीकरण करते, ज्यात HTTP 200 प्रतिसादाचाही समावेश आहे.
वितरण यशस्वी झाल्यानंतर नंतरच FindProxyForURL() डीबग करणे अर्थपूर्ण आहे. त्याचे होस्टनाव नियम बदलून ब्राउझरला ते मिळण्यापासून रोखणारी 404 दुरुस्त होऊ शकत नाही.
PAC वेब सर्व्हर आणि त्याच्या स्क्रिप्टमध्ये नामनिर्देशित फॉरवर्ड प्रॉक्सी यांतही फरक करा. ते एक मशीन सामायिक करू शकतात, पण एका सेवेच्या प्रवेश लॉगमधील नोंद हा पुरावा नाही की दुसऱ्या सेवेने वापरकर्त्याची गंतव्य विनंती हाताळली.