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 असफलतामा अगाडि बढ्नुहोस्।