PAC फाइलमध्ये क्रमबद्ध प्रॉक्सी फेलओव्हर
अर्धविरामाने विभक्त PAC निकाल पर्यायी मार्ग देते. तो विनंती क्रमाने दोन्ही प्रॉक्सी सर्व्हरमधून पाठवत नाही.
अर्धविरामाने विभक्त PAC निकाल क्रमाने पर्यायी मार्ग देते:
return "PROXY proxy-a.example:8080; PROXY proxy-b.example:8080";
धोरणाने आवश्यक असलेले प्रत्यक्ष HTTP एंडपॉइंट वापरा. सार्वजनिक प्रॉक्सी परवानगी असलेल्या सार्वजनिक गंतव्यांच्या चाचण्यांसाठी, HTTP प्रॉक्सी यादी उमेदवार पुरवते. A अयशस्वी झाल्यानंतर योग्य वेळी ब्राउझर B वापरून पाहू शकतो. रहदारी A मधून आणि नंतर B मधून जात नाही. साखळीसाठी क्लायंट किंवा प्रॉक्सी सर्व्हरवर स्वतंत्र आधार आवश्यक आहे; curl ची SOCKS-ते-HTTP साखळी ही एक समर्थित व्यवस्था आहे.
स्क्रिप्टची उपलब्धता आणि प्रॉक्सीची उपलब्धता
क्लायंटने प्रथम वापरण्यायोग्य PAC स्क्रिप्ट मिळवणे आवश्यक आहे. त्याच्या रिटर्न मूल्यातील दुसरा प्रॉक्सी अशा ब्राउझरला मदत करू शकत नाही जो स्क्रिप्ट डाउनलोड करू शकला नाही आणि ज्याच्याकडे वापरण्यायोग्य कॅशे प्रत नाही.
मूल्यांकनानंतर ब्राउझर परत दिलेल्या मार्गांमधून निवडतो. PAC संदर्भ क्रमबद्ध स्वरूप निश्चित करतो; कोणते अपयश फेलओव्हर सुरू करतात आणि अयशस्वी उमेदवार किती काळ लक्षात ठेवतो हे ब्राउझर ठरवतो. कार्यरत प्रॉक्सीद्वारे मिळालेली HTTP त्रुटी स्वयंचलितपणे दुसरा मार्ग सुरू करत नाही.
थेट पर्याय
जोडल्यास ; DIRECT दोन्हीपैकी कोणत्याही प्रॉक्सीशिवाय मार्गास परवानगी मिळते. हे रोमिंग धोरणासाठी योग्य ठरू शकते, परंतु प्रभावित रहदारीने नेहमी मंजूर एग्झिट वापरणे आवश्यक असा नियम याच्याशी विसंगत आहे.
आउटेज अहवालासाठी, स्क्रिप्ट मिळाली का, प्रभावित URL साठी तिचा निकाल, आणि ब्राउझरने वापरून पाहिलेला पर्याय नोंदवा. ती निरीक्षणे स्क्रिप्ट वितरण, मूल्यांकन आणि प्रॉक्सी कनेक्शन यांमध्ये अपयशाचे स्थान ठरवतात.