Apache AllowCONNECT మరియు HTTPS గమ్య పోర్టులు
క్లయింట్లు Apache ప్రాక్సీని చేరుకోవడానికి ఉపయోగించే పోర్టును, mod_proxy_connect టన్నెళ్లలోపల అనుమతించే గమ్య పోర్టుల నుండి వేరు చేయండి.
మీ 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ను పదేపదే విస్తరించడం బదులు.