3proxy యొక్క HTTP మరియు SOCKS రెండు సేవల్లోనూ లాగిన్ తప్పనిసరి చేయండి
HTTP మరియు SOCKS5 క్లయింట్ల కోసం 3proxy వినియోగదారులు, బలమైన ప్రామాణీకరణ మరియు సేవా ప్రవేశ నియమాలను కాన్ఫిగర్ చేయండి.
వినియోగదారుని నిర్వచించడం 3proxy యొక్క మొత్తం లాగిన్ కాన్ఫిగరేషన్ కాదు. సేవకు ప్రామాణీకరణ పద్ధతి మరియు దాన్ని ఉపయోగించే ప్రవేశ నియమం కూడా అవసరం. కాన్ఫిగరేషన్ ప్రాసెస్ అవుతున్నప్పుడు సేవా సెట్టింగ్‌లు వర్తించడం వల్ల క్రమం ముఖ్యం.
రెండు సేవల కోసం స్థానిక ప్రవేశానికి మాత్రమే ఉదాహరణ:
users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080కాన్ఫిగరేషన్ సూచన users, auth strong మరియు సేవా ఆదేశాలను వివరిస్తుంది. CL ఈ ఉదాహరణ పాస్‌వర్డ్‌ను సాధారణ వచనంగా నిల్వ చేస్తుంది. ఫైల్‌ను రక్షించండి మరియు అమరికకు సరిపోయే మద్దతు ఉన్న ఆధారాలు నిల్వ రూపాన్ని ఎంచుకోండి.
క్లయింట్‌కు సరైన లాగిన్ మార్పిడి అవసరం
HTTP సేవ HTTP ప్రాక్సీ ప్రామాణీకరణను ఆశిస్తుంది. SOCKS సేవకు SOCKS5 వినియోగదారు పేరు మరియు పాస్‌వర్డ్ ప్రామాణీకరణకు మద్దతిచ్చే క్లయింట్ అవసరం. SOCKS4 క్లయింట్ అదే వినిపించే పోర్టును చేరుకోవడం వల్ల మాత్రమే ఆ మార్పిడిని అందించలేదు.
strong అనే పదం ప్రామాణీకరణ మోడ్ పేరు, ఎన్‌క్రిప్ట్ చేసిన రవాణాకు హామీ కాదు. అవసరమైతే క్లయింట్ నుండి ప్రాక్సీ వరకు ఉన్న భాగాన్ని రక్షించండి. గమ్యస్థానానికి HTTPS మరియు ప్రాక్సీకి ఎన్‌క్రిప్షన్ వేర్వేరు నిర్ణయాలుగానే ఉంటాయి.
లూప్‌బ్యాక్ బైండింగ్‌లు ఈ ఉదాహరణను స్థానిక ప్రవేశానికి పరిమితం చేస్తాయి. దూరపు క్లయింట్ల కోసం ఉద్దేశించిన శ్రోత మరియు నెట్‌వర్క్ విధానాన్ని స్పష్టంగా ఎంచుకోండి. పబ్లిక్ వైల్డ్‌కార్డ్ శ్రోత లాగిన్ ప్రవర్తనను తనిఖీ చేయడానికి ప్రత్యామ్నాయం కాదు.
ఒక సేవ ఆధారాలను అడిగి మరొకటి అడగకపోతే, ప్రతి సేవా ఆదేశానికి ముందు సెట్టింగ్‌లు, ఏదైనా flush తర్వాత నియమాలు మరియు ప్రామాణీకరణ కాష్‌ను పరిశీలించండి. పాస్‌వర్డ్ మార్చడం తప్పు విధానం కింద ప్రారంభమైన సేవను సరిచేయలేదు. అలాగే, డీమన్ ఆపరేటింగ్ సిస్టమ్ ఖాతాను మార్చడం ప్రాక్సీ వినియోగదారుని సృష్టించదు.