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 अयशस्वी झाले, तर लक्ष्य-पोर्ट परवानगीने आपला भाग आधीच पूर्ण केलेला आहे. AllowCONNECT सतत रुंदावण्याऐवजी TLS अयशस्वीपणासह पुढे जा.