प्रोक्सी होस्टमा /check.txt नामको फाइल स्वास्थ्यको स्पष्ट लक्ष्य जस्तो सुनिन्छ। पेच यो हो कि Squid को स्पष्ट फर्वार्ड सुन्ने त्यो होस्टको कागजात-मूल दिने साधारण वेबसाइट होइन।

HEAD /check.txt HTTP/1.1 जस्तो मूल-शैलीको अनुरोधले फर्वार्ड प्रोक्सी हुँदै जाने साधारण HTTP अनुरोधका लागि अपेक्षित निरपेक्ष लक्ष्य छोड्छ। कन्फिगरेसनअनुसार यो अस्वीकार हुन सक्छ वा अर्को स्थानीय सेवाले सम्हाल्न सक्छ। दुवै नतिजाले ड्यासबोर्डले संकेत गरेभन्दा कम बता सक्छ।

उपलब्ध राख्नुपर्ने सेवा छान्नुहोस्

जाँचउपयोगी प्रमाण
प्रोक्सी सुन्नेमा TCP जडानपहुँचयोग्य प्रक्रियाले त्यो जडान स्वीकार गर्छ।
नियन्त्रित लक्ष्यमा CONNECTप्रोक्सीले त्यो सुरुङ अनुरोध स्वीकार गर्छ।
प्रोक्सीमार्फत HTTP प्राप्तिछानिएको अनुरोध मार्गले अपेक्षित प्रतिक्रिया फर्काउन सक्छ।

तेस्रो अवस्थामा अनुरोधलाई लक्ष्य चाहिन्छ, उदाहरणका लागि:

HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internal

होस्टनाम केवल उदाहरण हो। प्रोक्सीले समाधान गर्न सक्ने र जहाँ पुग्न जानाजानी अनुमति दिइएको नियन्त्रित अन्त्यबिन्दु प्रयोग गर्नुहोस्। HAProxy को http-check send ले विधि, URI, संस्करण र हेडर छान्न समर्थन गर्छ; मूल-सर्भरको उदाहरण अपरिवर्तित रूपमा नलिई त्यो अनुरोध स्पष्ट रूपमा कन्फिगर गर्नुहोस्।

HEAD ले प्रतिक्रियाको स्थिति र हेडर जाँच्न सक्छ। कहिल्यै नपठाइने प्रतिक्रिया-मुख्य भाग यसले प्रमाणित गर्न सक्दैन। यदि स्वास्थ्य सम्झौताले मुख्य भागमा चिन्ह माग्छ भने उपयुक्त GET जाँच छान्नुहोस् र त्यो चिन्ह प्रमाणित गर्नुहोस्।

प्रोक्सी प्रमाणीकरण संलग्न हुँदा जाँच खाता र स्रोत प्रतिबन्ध साँघुरो राख्नुहोस्। हरियो चिन्ह पाउन सम्पूर्ण सुन्नेलाई प्रमाणीकरणबाट छुट दिनु संरक्षित सेवा नै बदल्नु हो।

अन्तमा, असफल जाँचले के हटाउनुपर्छ भनी निर्णय गर्नुहोस्। नियन्त्रित मूल अवरोधले एकैचोटि हरेक प्रोक्सीको फर्वार्डिङ जाँच असफल बनाउन सक्छ। त्यो ठ्याक्कै तपाईं मापन गर्न चाहनुभएको निर्भरता हुन सक्छ, वा सुन्नेको स्वास्थ्य र अन्त-देखि-अन्त उपलब्धतालाई छुट्टाछुट्टै संकेत राख्ने कारण हुन सक्छ।

सम्बन्धित लेखहरू