Apache AllowCONNECT और HTTPS गंतव्य पोर्ट

आपकी Apache प्रॉक्सी पोर्ट 3128 पर सुनती है। कोई क्लाइंट उस तक सफलतापूर्वक पहुँचता है, परंतु पोर्ट 8443 पर HTTPS सेवा विफल रहती है। प्रॉक्सी का सुनने वाला पोर्ट बदलने से उस विशिष्ट अंतर का समाधान होने की संभावना नहीं है।

क्लाइंट पहले प्रॉक्सी श्रोता से जुड़ता है। उसका CONNECT अनुरोध फिर एक अलग गंतव्य होस्ट और पोर्ट का नाम देता है। Apache पहले कनेक्शन को स्वीकार कर सकता है और दूसरे ऑपरेशन को अस्वीकार कर सकता है।

AllowCONNECT को गंतव्य नीति के रूप में पढ़ें

Apache 2.4 के लिए, mod_proxy_connect आने वाले CONNECT अनुरोधों को संभालता है। इसका AllowCONNECT निर्देश उन अनुरोधों के लिए उपलब्ध गंतव्य पोर्ट नियंत्रित करता है। प्रलेखित डिफ़ॉल्ट 443 और 563 है।

AllowCONNECT 443 8443

यह उदाहरण उन दो गंतव्य पोर्टों का चयन करता है। यह डिफ़ॉल्ट चयन को प्रतिस्थापित करता है; यह 8443 नहीं जोड़ता और साथ ही हर डिफ़ॉल्ट पोर्ट को चुपचाप बनाए नहीं रखता। निर्देश का उपयोग लागू सर्वर या वर्चुअल-होस्ट कॉन्फ़िगरेशन में करें।

रखें प्रॉक्सी के क्लाइंट प्राधिकरण नियम यथावत। अनुमत गंतव्य पोर्ट इस बारे में कुछ नहीं कहता कि कौन-सा क्लाइंट सेवा का उपयोग कर सकता है, और जब गंतव्य-होस्ट प्रतिबंध आवश्यक हो तो यह उसका विकल्प नहीं है।

रिवर्स-प्रॉक्सी का उदाहरण किसी दूसरे प्रश्न का उत्तर देता है

Apache और HTTPS के खोज परिणाम अक्सर एक सार्वजनिक वेबसाइट दिखाते हैं जो किसी निश्चित बैकएंड की ओर अग्रेषित करती है। वह कॉन्फ़िगरेशन वह तरीका नहीं है जिससे कोई ब्राउज़र फ़ॉरवर्ड प्रॉक्सी से चयनित वेबसाइट तक CONNECT टनल खोलने को कहता है। उसके रूटिंग निर्देशों की नकल करने से मूल प्रॉक्सी समस्या अछूती रह सकती है।

विफलता का निदान करते समय, वह श्रोता दर्ज करें जहाँ क्लाइंट पहुँचा, अनुरोधित CONNECT प्राधिकार और प्रॉक्सी का उत्तर। यदि CONNECT सफल होता है और उसके बाद TLS विफल होता है, तो गंतव्य-पोर्ट अनुमति अपना काम कर चुकी है। आगे बढ़ें TLS विफलता के साथ, AllowCONNECT को बार-बार चौड़ा करने के बजाय।