3proxy ၏ HTTP နှင့် SOCKS ဝန်ဆောင်မှု နှစ်ခုစလုံးတွင် လော့ဂ်အင် တောင်းဆိုပါ

အသုံးပြုသူတစ်ဦး သတ်မှတ်ခြင်းသည် 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 ပြီးနောက် စည်းမျဉ်းများနှင့် အတည်ပြုခြင်း ကက်ရှ်ကို စစ်ဆေးပါ။ စကားဝှက် ပြောင်းခြင်းသည် မှားယွင်းသော မူဝါဒအောက်တွင် စတင်ခဲ့သော ဝန်ဆောင်မှုကို ပြုပြင်၍ မရပါ။ အလားတူပင် daemon ၏ လည်ပတ်မှုစနစ် အကောင့် ပြောင်းခြင်းသည် ပရောက်စီ အသုံးပြုသူကို မဖန်တီးပါ။