3proxyతో SOCKS క్లయింట్‌లను HTTP CONNECT పేరెంట్‌కు బ్రిడ్జ్ చేయండి

అప్లికేషన్‌కు SOCKS అవసరం. మీ ఆమోదిత అప్‌స్ట్రీమ్ సేవ HTTP CONNECT ను అంగీకరిస్తుంది. అప్లికేషన్ SOCKS ఫీల్డ్‌లో HTTP ఎండ్‌పాయింట్ పెట్టడం ప్రోటోకాల్‌ల మధ్య అనువదించదు.

గేట్‌వే అప్లికేషన్ నుండి SOCKS స్వీకరించి, కోరిన గమ్యాన్ని చదివి, ఆ గమ్యానికి CONNECT సొరంగాన్ని HTTP పేరెంట్‌ను అడగగలదు. తర్వాత అప్లికేషన్ స్ట్రీమ్‌ను సొరంగం ద్వారా పంపుతుంది.

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

ప్రతి ఇంటర్‌ఫేస్‌ను స్పష్టం చేయండి

ఈ అమరికకు మద్దతిచ్చే గేట్‌వేకు దాని పేరెంట్ రకం ముఖ్యం. 3proxy డాక్యుమెంటేషన్ connect పేరెంట్‌ను సాధారణ HTTP ఫార్వార్డింగ్ ప్రాక్సీగా ఉపయోగించే పేరెంట్ నుండి వేరు చేస్తుంది.

ఇప్పటికే ఉన్న 3proxy వినియోగదారు మరియు ప్రామాణీకరణతో, స్థానిక-మాత్రమే రూటింగ్ భాగం ఇలా ఉండవచ్చు:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

ఈ భాగం ఖాతా ఇప్పటికే నిర్వచించబడిందని ఊహిస్తుంది. HTTP పేరెంట్ తనకు అవసరమైన ఏ ఆధారాలను జోడించదు మరియు ఇప్పటికే ఉన్న యాక్సెస్ విధానాన్ని భర్తీ చేయదు. ప్రామాణీకరణ లేని పబ్లిక్ HTTP పేరెంట్‌ను అనుమతించే మార్గంలో పబ్లిక్ గమ్యాల కోసం, HTTP ప్రాక్సీ జాబితా హోస్ట్ మరియు పోర్ట్ అభ్యర్థులను అందిస్తుంది. ఆ శాఖకు పేరెంట్ ఆధారాలను లేకుండా ఉంచి నిజమైన లక్ష్యానికి అనుమతిని నిర్ధారించండి; గేట్‌వే స్వంత ఖాతా స్థానికంగానే ఉంటుంది. parent నియమం 3proxy యొక్క డాక్యుమెంటెడ్ కాన్ఫిగరేషన్ నమూనా ప్రకారం మునుపటి allow నియమంతో అనుసంధానించబడింది.

అప్లికేషన్ స్థానిక SOCKS ఎండ్‌పాయింట్‌ను ఉపయోగిస్తుంది. గేట్‌వే పేరెంట్ వైపు HTTP CONNECT ఉపయోగిస్తుంది. కోరిన గమ్య హోస్ట్ మరియు పోర్ట్ అనుమతించబడ్డాయా అనేది ఇప్పటికీ పేరెంటే నిర్ణయిస్తుంది.

ఇక్కడ ఉపయోగకరమైన పరిధి సాధారణ TCP స్ట్రీమ్ సొరంగం. ముందు వినేవాడు SOCKS5 అంగీకరిస్తున్నందుకే SOCKS5 UDP అనుబంధం మద్దతు పొందదు. HTTP CONNECT పేరెంట్ అవసరమైన UDP రిలేను స్వయంచాలకంగా అందించదు.

HTTPS ఈ మార్గంలో చివరి నుండి చివరి వరకు ఉండగలదు; ప్రాక్సీ ఇంటర్‌ఫేస్‌ల మధ్య అనువాదానికి గమ్య వెబ్‌సైట్‌ను అనుకరించాల్సిన అవసరం లేదు. గేట్‌వే, పేరెంట్ మరియు వెబ్‌సైట్ ప్రామాణీకరణలు వేర్వేరు ఆధారాలు మరియు మార్పిడులుగానే ఉంటాయి.