<VirtualHost> ब्लॉक बताता है कि Apache को मेल खाती अनुरोधों को कैसे संभालना चाहिए। लेकिन यह सुनने वाला सॉकेट नहीं बनाता। इसलिए पोर्ट 8080 पर फ़ॉरवर्ड-प्रॉक्सी कॉन्फ़िगरेशन किसी वैध दिखने वाली फ़ाइल में मौजूद हो सकता है, जबकि क्लाइंट को वहाँ कोई श्रोता नहीं मिलता।

Listen निर्देश वह अलग आवश्यकता पूरी करता है। ऐसे प्रॉक्सी के लिए जिस तक केवल स्थानीय क्लाइंट या सुरक्षित टनल से पहुँचा जाता है, इच्छित रूप में यह शामिल हो सकता है:

Listen 127.0.0.1:8080

<VirtualHost 127.0.0.1:8080>
    # Existing restricted forward-proxy configuration
</VirtualHost>

यह संबंध दर्शाता है, पूर्ण प्रॉक्सी परिनियोजन नहीं। मौजूदा क्लाइंट प्राधिकरण और गंतव्य प्रतिबंध बनाए रखें। loopback पता जानबूझकर नया सार्वजनिक प्रॉक्सी श्रोता नहीं देता।

प्रभावी कॉन्फ़िगरेशन में ओवरलैप करती Listen प्रविष्टियाँ भी जाँचें। मौजूदा श्रोता पर ध्यान दिए बिना दूसरा निर्देश जोड़ने से शुरुआत रुक सकती है। किसी विशिष्ट पते से ओवरलैप करने वाले wildcard बाइंडिंग की ओर जाते समय Apache की समर्थित रीस्टार्ट प्रक्रिया भी महत्वपूर्ण है।

जब SSH इस प्रॉक्सी की ओर फ़ॉरवर्ड करता है, तो दूर के छोर को वास्तविक श्रोता तक पहुँचना चाहिए। सफल SSH लॉगिन कॉन्फ़िगर किया गया Apache पोर्ट नहीं बनाता। HTTP क्रेडेंशियल बदलने या किसी एक्सेस नियम को कमज़ोर करने से पहले श्रोता और इच्छित बाइंडिंग ठीक करें। फिर वास्तविक श्रोता पर अनुमत और अस्वीकृत एक्सेस मामलों को सत्यापित करें।

संबंधित लेख