په 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 او پراکسي ته کوډ کول جلا پرېکړې پاتې کیږي.
Loopback بندښتونه دا بېلګه یوازې سیمهای لاسرسي ته محدودوي. د لرې کلاېنټونو لپاره په څرګند ډول د اورېدونکي او شبکې پالیسي وټاکئ. عامه وائلډکارډ اورېدونکی د ننوتلو چلند د کتلو بدیل نه دی.
که یو خدمت اعتبار معلومات وغواړي او بل نه، د هر خدمت له حکم څخه مخکې تنظیمات، د هر flush وروسته قواعد او د تصدیق کیش وګورئ. د پټنوم بدلول نشي کولی هغه خدمت سم کړي چې د ناسمې پالیسۍ لاندې پیل شوی. همدارنګه، د ډیمون د عملیاتي سیستم حساب بدلول پراکسي کاروونکی نه جوړوي.